[systemd-devel] systemd-fsck-root semantics

[Colin Guthrie]

'Twas brillig, and Daniel Drake at 02/07/14 13:43 did gyre and gimble:
> On Wed, Jul 2, 2014 at 1:36 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
>>> 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 think the idea is that the unit is still around, hence won't get
>> started a second time.
> 
> dracut doesn't include systemd-fsck-root in the initramfs. I think
> there is good reason for that - systemd-fsck-root causes fsck to run
> on /, but at this point in the initramfs, / is a ramdisk and the thing
> that needs checking is at /sysroot.

Does it really use the mountpoint? I thought the mountpoint was pretty
much irrelevant. It should be all about the device-node.

>>> 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.
>>
>> Well this is how things were traditionally done on initrd-less
>> systems. It's really a horrible thing to do, and people really shouldn't
>> do it. I certainly wouldn't run my systems like that.
> 
> I agree, but am a little worried that systemd might do this kind-of by
> default. I now realise that this is a distro choice, they should
> probably set passno=0 in fstab, I wonder if they actually do...

Whatever the outcome, systemd upstream should certainly do only safe
things by default. The fact the unit is triggered automatically by the
generator is IMO "not by default", but your concern re the pass number
is certainly justifiable.

I guess that as most people use initramfs', an extra
ConditionPathExists!=/run/initfamfs/skip-root-fsck wouldn't go astray,
and dracut+co could learn to touch that file if they've properly
analysed and taken care of root fsck'ing for you.

There may of course be much nicer ways!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/