I powered on my Sheevaplug, after being unplugged for several days vacation.

It didn't become available on the network after waiting over 60s, which is the length of time I remember it taking before. The disk was whirring and it turns out it took several extra minutes running fsck.

Why the fsck? Were my filesystems not cleanly unmounted for some reason?

It runs Debian Jessie.

$ systemd-analyze blame
    2min 26.613s systemd-fsck@dev-mapper-vg_brick\x2dlv_backup.service
    2min 13.294s systemd-fsck@dev-mapper-vg_brick\x2dlv_attic.service
    1min 55.661s systemd-fsck@dev-mapper-vg_brick\x2dlv_home.service
         35.407s systemd-fsck@dev-mapper-vg_brick\x2dlv_aptcache.service

$ journalctl -b

Jan 01 02:17:57 brick systemd[1]: Found device /dev/mapper/vg_brick-lv_aptcache.
Jan 01 02:17:57 brick systemd[1]: Starting File System Check on /dev/mapper/vg_brick-lv_aptcache...
Jan 01 02:17:57 brick systemd-fsck[429]: aptcache: Superblock last write time (Sun Apr  2 20:58:31 2017,
Jan 01 02:17:57 brick systemd-fsck[429]: now = Tue Jan  1 02:17:57 2013) is in the future.
Jan 01 02:17:57 brick systemd-fsck[429]: FIXED.

1 Answer 1


A forced fsck is expected when the clock goes backwards. Source code. This is what happens on systems without battery-backed clocks, when they are unplugged for a period of time.

(The code also suggests there's an option to affect this behaviour. It might be argued that the forced check is a legacy of the old default to force check every 180 days, which no longer applies).

Additionally, if you reboot this system within 11 minutes, the fsck will be forced again. However if you allow 11 minutes after the ntpd daemon is started, the hardware clock will be updated from internet ntp servers. On a reboot, the kernel will set an accurate system time from the hardware clock. Then you won't see this forced check happen.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .