[systemd-devel] systemd-fsck-root semantics

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 02, 2014 at 12:39:54PM +0100, Daniel Drake 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.
> 
> 
> 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?
> 
> There used to be a marker file in /run to let systemd know that the
> initramfs already checked it, but that was removed in commit
> 956eaf2b8d6c9999024705ddadc7393bc707de02.

Thinking about it, I'm not sure how the new systemd would know that
systemd-fsck at dev-something.service from the initramfs is the same
thing as systemd-fsck-root.service. Maybe that's the problem?

Currently systemd-fsck-root.service does nothing if / is mounted rw,
which of course is used by almost everybody, so I think you might
be using codepaths that are rarely tested.

> Also, systemd-fsck-root.service in itself seems a little questionable,
> is it really safe in any context to run fsck on a mounted partition?
> That could modify data structures which have already been cached in
> memory in the kernel fs driver. In fact, e2fsck refuses to run on
> partitions that are mounted, even ones that are ro.
Isn't it how it always has been, until initramfs became common?

Zbyszek