Bug#408954: checkroot.sh: should not skip running fsck with JFS root

[Pierre Ynard]

Hello,

I invite you guys to look inside /etc/init.d/checkroot.sh to see that
the check for AC power or battery is actually completely commented
out. So as far as battery is concerned, the question is moot, and the
filesystem is always checked.

The battery check was introduced in #326647 in 2005:

> While reviewing the patches from Ubuntu, I came across a nice
> improvement.  Make sure to not run fsck if the machine is running on
> battery.  This would make the boot process a lot better for laptops.

I haven't researched the original Ubuntu patch to check what the
rationale was when it was introduced there.

Then in 2009, it was pointed out in #526398 that this "can cause serious
data corruption if booting on battery power" and that skipping fsck
wasn't necessarily a nice idea. Some discussion already ensued about the
necessity and conditionality of running fsck at boot, similar to this
thread. The battery check was commented out, and #326647 was reopened.

So I would believe that this 2007 bug was already fixed at the same time
as #526398, when the battery check was reverted. Now there could be
other mishaps causing the reporter's JFS filesystem to be skipped, but I
don't see any and running on batteries was specifically mentioned. So as
for this bug report proper, I suspect it could be closed.

Now as for the discussion: /etc/init.d/checkroot.sh contains a check to
skip btrfs. /lib/init/mount-functions.sh contains checks specific to
the root fs to skip nfs and nfs4; and also /etc/fstab configurations
with the pass field set to 0 - which by the way was reported in #571241
to fail to skip trying to check an ubifs root (for which there is no
fsck utility). /etc/init.d/checkfs.sh contains checks to limit fsck
operations to the undocumented FSCKTYPES variable (which is ignored by
/etc/init.d/checkroot.sh) and calls fsck with -A to let it handle itself
the pass column of /etc/fstab. And finally, initscripts ships a dummy
fsck.nfs to cope with attempts that should already be prevented by the
above check for it.

So the current handling of this matter is not very rationalized.

Ted says that checking filesystems at boot is very much not a dead
concept. Yet there are some filesystems where it's undesirable or
impossible.

Do we want a blacklist, or a whitelist?

Do we want to delegate conditionality to particular implementations? If
so, which factors? Running on battery was suggested. Shipping a dummy
fsck.$type is a way to delegate the possibility or impossibility to fsck
to the implementation - but that doesn't seem like the best or most
flexible technical solution to me.

What is the difference between checking the root filesystem, and
checking other filesystems? Why would the logic to skip brtfs and nfs
apply only to checkroot.sh, why would checkroot.sh ignore FSCKTYPES?

Does the installer set up /etc/fstab configurations requesting to fsck
wrong filesystems to begin with, that we need checks to disable later
on? Shall we ask installer maintainers, open a bug if there isn't one?

Can we have a switch in fsck similar to -A to let it parse the pass
field of /etc/fstab for us, except when checking only one device
passed in argument, or only the root fs? That way we wouldn't have
to parse it ourselves too just for the root fs and pass it from
/lib/init/mount-functions.sh back to /etc/init.d/checkroot.sh.

Can we gather the filesystem blacklist/whitelist, FSCKTYPES handling,
is_fastboot_active check, and possibly battery check, all together and
factorized in a single place in /lib/init/mount-functions.sh?

That's what I would suggest.

Regards,

-- 
Pierre Ynard