systemd-fsck@dev-mapper-home.service takes 30s to complete during boot whereas fs are clean. this also seems to happen for other fs, but randomly (?) Using systemd 219 on Ubuntu 15.04 (beta 2), I noticed an abnormally long boot sequence (given the use of a SSD) with wait on "Checking filesystem on disk ..." This happens on every boot. The same setup with upstart/systemd and ubuntu 14.10 showed no such problem. It appears that: $ systemd-analyze blame|head -3 32.241s systemd-fsck@dev-mapper-home.service 8.137s plymouth-quit-wait.service 7.691s NetworkManager-wait-online.service $ systemctl status systemd-fsck@dev-mapper-home.service ● systemd-fsck@dev-mapper-home.service - File System Check on /dev/mapper/home Loaded: loaded (/lib/systemd/system/systemd-fsck@.service; static; vendor preset: enabled) Active: active (exited) since mer. 2015-04-01 22:45:58 CEST; 2h 45min ago Docs: man:systemd-fsck@.service(8) Main PID: 821 (code=exited, status=0/SUCCESS) avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: Cannot communicate fsck progress to fsckd: Broken pipe avril 01 22:45:58 callisto systemd-fsck[821]: /dev/mapper/home : 169002/13148160 fichiers (0.8% non contigus), 36631520/52566272 blocs avril 01 22:45:58 callisto systemd[1]: Started File System Check on /dev/mapper/home. I can check from ext4 metadata header that no fsck is actually run. fsck returns immediatly. the fs has already been check and is clean. The setup is as follow on an Inspiron 15 3525. /dev/sda is a SSD with root on /dev/sda4 and /dev/sda5 being a bcache caching device for /dev/sdb5 bcache backing LUKS home partition. sdb is a hdd in an hdd caddy in dvd drive bay. home == LUKS: bcache0: sda5+sdb5 using fsck.mode=skip avoids that 30s wait, but that is not really wanted. /etc/crypttab: home /dev/bcache0 /root/.xxxxxxxxx-6xxx-4xxx-axxx-xxxxxxxxxx.bin luks cryptswap /dev/disk/by-partuuid/xxxxxxxx-0xxx-4xxx-bxxx-xxxxxxxxx /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
I have found that the timeclock was not set correctly during boot. the RTC clock was set in UTC but was read in locale given a 2h time in the past. This seems to cause problem with fsck possibly finding a superblock date in the future. Once I fixed that (changing UTC to yes in /etc/default/rcS), the abnormal delay was gone
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.