Bug#788050: systemd-fsck : Check disks at each reboot

[Aubrey Stark-Toller]

I think I just ran into this problem.

systemd-fsck seemed to be choking on a ~1.8T LVM volume with an ext3
filesytem - the volume's group is on an encrypted primary partion on a
HDD. I'm running stretch.

Before attempting to remedy the problem:
* systemd-fsck tried to run on the volume ever boot,
* "systemd-analyze blame" told me systemd-fsck runs for ~4 min on the
  volume, which is not long enough to complete a check (I know from past
  checks),
* "journalctl -u" systemd-fsckd.service told me nothing interesting,
* tune2fs said the volume has not been checked since 15 Mar 2016, which
  supports the theory systemd-fsck is not completing.
* systemd-fsck completes for all other volumes and disks (which are
  considerably smaller), so I'd guess it's a timeout issue.

Before the 15 Mar 2016 everything worked fine, so this must have been
caused by an update since then. Unfortunately I can't pin down a more
precise start date, but I do have dpkg logs going back to the 15th so
might be able to glean something from that.

Setting TimeoutStartSec in /etc/systemd/system/systemd-fsckd.service to
0
and 480min did nothing.

fsck ran fine while booting after running
"systemctl mask > systemd-fsckd.service systemd-fsckd.socket"; tune2fs
reported the volume had been checked and "systemd-analyze blame" gave a 
sane run time for systemd-fsck.


- Aubrey Stark-Toller