[systemd-devel] systemd-fsck-root semantics
Chris Murphy
lists at colorremedies.com
Wed Jul 2 11:33:01 PDT 2014
On Jul 2, 2014, at 5:39 AM, Daniel Drake <drake at endlessm.com> wrote:
> Hi,
>
> I'm trying to understand dracut/systemd fsck behaviour, in the context
> of an ext4 filesystem root mounted read-only from dracut, remaining
> read-only even when the system is fully booted (kiosk-style).
>
> I see that systemd's fstab-generator rightly creates a mount unit for
> /sysroot from the initramfs, and causes e2fsck to be run on it from
> inside the dracut initramfs, before it is mounted. So far so good.
It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only?
> Then the system continues booting, switches root, and then
> system-fsck-root.service starts from the root fs, and runs fsck on /
> again. This is the bit I don't understand - we already checked from
> the initramfs, why check again now?
I'd say we're in a transitional state between whether initramfs and systemd should do fsck.
And also whether fsck is the rule or exception. The three main Linux file systems used today: ext3/4, XFS, and Btrfs, two of three don't need and can't do fsck at boot. So the concept is obsolete for the majority (of file systems, not installations), with ext3/4 being the exception.
At the moment throwing me for a loop is what to do about the EFI System partition on UEFI computers, which is FAT16/32. So it's back to 1985 and dealing with a non-journaled file system. Very often unclean shutdowns are causing FAT inconsistencies, I'd say more than half the time. Sometimes a boot time automatic fsck fixes these, other times they aren't and a manual fsck is needed. But this message is really easy to miss because the file system still gets mounted and it's just a matter of time before such a file system is beyond repair. So I'm not a fan of always mounting the ESP rw at /boot/efi as most (all?) Linux distros currently do (Window and OS X do not persistently mount the ESP, they're only mounted on demand for bootloader or firmware updates) as it seems too fragile.
Chris Murphy
More information about the systemd-devel
mailing list