[systemd-devel] no fsck at boot

[Lennart Poettering]

On Tue, 10.06.14 12:41, Chris Murphy (lists at colorremedies.com) wrote:

> 
> 
> On Jun 9, 2014, at 5:24 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 
> > 'Twas brillig, and Reindl Harald at 09/06/14 19:57 did gyre and gimble:
> >> what disturbs me is they warning about "touch /forcefsck" while
> >> it's currently the *only* option to trigger a recommended fsck
> >> at boot on a remote-server (and no add kernel params for that
> >> in the grub-config and remove them after is not a sane way for
> >> sysadmins maintaining 10,20,30 remote servers)
> > 
> > As has been mentioned numerous times, these warnings are there because
> > if you need to use something to force an fsck (this current problem not
> > withstanding) then modifying the suspect filesystem in question is a
> > really bad idea! The warnings are in place to cover this use case and to
> > discourage it as a first port of call without giving it proper thought.
> 
> On a Rawhide, systemd 212-4 system, using ext4, I get this at boot time when max-mount-counts as set with tune2fs -c is reached:
> 
> systemd-fsck[241]: /dev/sda3 has been mounted 3 times without being checked, check forced.
> 
> I can't actually tell if e2fsck -f was used, but that's what I'd expect, whereas the usual fsck used every boot with fs_passno 1 or 2 is e2fsck -p.
> 
> If I'm reading the thread correctly, a distinction by systemd is being
> made between max-mount-counts and interval-between-checks. It does the
> forced fsck for max-mount-counts, but not for interval-between-checks
> resulting in the need for /forcefsck being used. Regardless of whether
> systemd should just do the forced fsck or not, the behavior should be
> the same for both max-mount-counts and interval-between-checks.

systemd does not interpet any of these values. We just invoke fsck, and
fsck then dispatches to the right binary for the specific fs, and that
then interprets everything and does its fs-specific fsck magic.

> Also on Rawhide, I'm finding that even if fs_passno is set to 0 ,
> systemd is still doing fsck for root. Maybe it's arguably correct to
> ignore fs_passno 0 for root on ext234, but it's incorrect behavior for
> XFS and Btrfs and a bad hack for systemd to depend on a faux fsck.<fs>
> to ensure nothing is done even when nothing was asked to be done.

> https://bugzilla.redhat.com/show_bug.cgi?id=1098799

Yes this is a known problem. We should fix it, but it's not obvious to
fix, since this fsck is actually run by the initrd, not the host
system. There's currently no nice way to pass information about whether
fsck for the rootfs is requested to the initrd via kernel cmdline params
(there's only the global fsck.mode=, but that applies to all mounts, not
just the root fs). And I do wonder if it really is desirable even hav
this, after all we want to stay generic, and carry as little information
possible into the initrd. I mean, I can totally see why fsck is
something one might want to disable for debug reasons, but otherwise?

Anyway, that's the background story why we haven't done much about this
bug so far...

Lennart

-- 
Lennart Poettering, Red Hat