[systemd-devel] Hosts without /etc/machine-id on boot

[Didier Roche]

Le 21/11/2014 00:41, Lennart Poettering a écrit :
> On Thu, 20.11.14 17:23, Didier Roche (didrocks at ubuntu.com) wrote:
>
>>> a) make /etc writable before systemd is invoked. If you use an initrd
>>>     this is without risk, given that the initrd should really invoke
>>>     fsck on the root disk anyway, and there's hence little reason to
>>>     transition to a read-only root, rather than just doing rw
>>>     right-away.
>> Interesting, I run that through our kernel team. However, we run fsck a
>> little bit later on in the boot process to be able to pipe the output to
>> plymouth.
> At least on Fedora plymouth already runs on the initrd. If Ubuntu does
> the same, then there shouldn't be a difference regarding where fsck is
> run...
>
> Note that running fsck in the initrd for the root fs is really the
> right thing to do: running fsck from the file system you are about to
> check, which you hence cannot trust, is really wrong.
>
>> I'm not sure we should then have two code paths:
>> - one fscking from the initrd if /etc/machine-id is empty (like after a
>> factory reset), showing the results and eventual failures to the user in
>> some way
>> - and then, the general use case: fscking through the systemd service via
>> systemd-fsck-root.service before local-fs.target and piping the result in
>> plymouth
> The latter is useful only really on non-initrd boots where there isn't
> any initrd where the fsck could run. General purpose distributions
> should really run fsck in the initrd.
>
> Note that systemd-fsck-root.service skips itself when it notices that
> the fs was already checked (via a flag file in /run).

Indeed, that makes sense and we should investigate that with our kernel 
team in the near future. I'm going to open a thread on it.
>
>>> The guarantee with /etc/machine-id is really that it is valid at *any*
>>> time, in early boot and late boot and all the time in between.
>> I think I will go that path which is an interesting one and mapping some of
>> my thoughts. Thanks for the guidance and documentation on what's the right
>> approach to achieve this race-free! I'll work on something around that and
>> propose a patch.
> Looking forword to it.

Here we go :)
I did some factorization to reuse some functions on the first path and 
added the binary helper, unit and man page.

It should follow your advice and be race-free. Tested various cases locally.

Cheers,
Didier