[systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Fri, Jan 9, 2015 at 3:27 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:

> I might be missing something, but what's wrong with the existing "root=...
> rootfstype=... rootflags=... rw" options? Why is the remount even necessary?

Seems to be distro specific. I see rw for opensuse or Ubuntu, and ro for Fedora.

The ro seems antiquated to me, meant for interactive fsck on an ro
mounted filesystem when booting single user. 'btrfs check' refuses to
run on mounted file systems, even if ro. And xfs_repair requires the
use of -d "repair dangerously" to do so.

Both XFS and Btrfs have placeholder fsck's, if you man fsck.xfs or
fsck.btrfs you'll see. These filesystems are designed to fix most
problems with a normal mount and if that doesn't work then separate
'xfs_repair' and 'btrfs check' are used booting from separate system
such as a rescue USB with current upstream tools.

ext34 also uses a journal to fix most problems at initial mount time.
But it also has max-mount-counts and interval-between-checks, by
default the latter is 180 days set at mkfs time. When those reach
their set value, it causes e2fsck to do a full fsck rather than just a
quick check. For e2fsck to pick up either max-mount-counts or
interval-between-checks, it has to be run at each boot.

Sadly, linux distros all appear to persistently mount the FAT32 EFI
System partition at /boot/efi, which is a bad idea. Instead they
should include mount option 'x-systemd.automount,noauto' in fstab
along with fspassno of 2. That way a.) it doesn't always get mounted,
just when something looks at /boot/efi, b.) if it has problems it
won't cause boot hang or failure, c.) the fsck is done upon accessing
the mount point. It's all quite fast and far less risky that current
practice on every distro I'm familiar with.

-- 
Chris Murphy