[systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount

Colin Guthrie gmane at colin.guthr.ie
Thu Aug 1 00:48:10 PDT 2013


'Twas brillig, and WANG Chao at 01/08/13 06:36 did gyre and gimble:
> On 07/30/13 at 04:40pm, Tom Gundersen wrote:
>> On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer <harald at redhat.com> wrote:
>>> On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>>> Maybe rootfsflags=nofail could do be used as this flag?
>>>
>>> rootfsflags=nofail sounds ok, if it is not used for booting the initial system.
>>
>> Yeah, you are right, this looks like it should just work.
>>
>> Though the behavior of initrd-parse-etc.service and
>> initrd-switch-root.service will be non-deterministic if this flag is
>> specified (unless I'm missing something). Maybe they should be
>> explicitly ordered After/Wants=sysroot.mount ? That may cause a long
>> timeout, but at least there will be no emergency mode.
> 
> No, guys, nofail mount option will *only* work when device (or should I
> say filesystem) doesn't exist.
> 
> From mount(8):
> [..]
>        _nofail_ Do not report errors for this device if it does not exist.

I'm not sure that description is 100% true under systemd. Looking at the
code, it seems to control the dependencies of the mount units (namely
changing a "Requires=" to the softer "Wants=")

> So if filesystem is corrupted or something else fails the sysroot.mount,
> initrd-root-fs.target will never be reached.

Is this actually true? Given the above comment? But that said, it could
easily be that the / mountpoint is handled specially in systemd (I've
not looked at the code that closely) which may explain why nofail
doesn't work for it like it would for other mounts...

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/



More information about the systemd-devel mailing list