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

[Lennart Poettering]

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).

> >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.

Lennart

-- 
Lennart Poettering, Red Hat