[systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!

Mantas Mikulėnas grawity at gmail.com
Fri Dec 27 04:04:03 PST 2013


On Fri, Dec 27, 2013 at 12:35 PM, Holger Schurig
<holgerschurig at gmail.com> wrote:
> Hi all,
>
> I'm using systemd for embedded devices. The kernel is compiled for the
> target and I don't need / use an initrd, as all device drivers are
> known beforehand and I like the faster boot speed. That means that /
> is mounted read-only when systemd starts.
>
> However, systemd (and also journald, as it uses machine_id_setup) has
> a handling of /etc/machine-id that doesn't fit here. In effect,
> systemd+journald won't run in a system where root is readonly at boot
> time and where no /run exists because no initrd did run.
>
>
> What happens currently?
>
> 1. It tries to open /etc/machine-id and fails, because at that point
> in time /etc isn't writable.
>
> 2. Then it tries to open /etc/machine-id readonly, but again fails, no
> machine-id there

The file can remain *empty*, but it should *exist*, because systemd
will want to bind-mount /run/machine-id.

>
> 3. Now it tries to generate a machine ID and tries to write it into
> /run/machine-id. Again this fails, because /run is still on the same
> partition as /, and it is still not writable. FAIL !

No, the "FAIL" here – as you say – is that /run is not writable in the
first place.

The whole purpose of /run, AFAIK, is to be writable anytime even
before root becomes writable, so a 'tmpfs' should be mounted there
during early boot.

If the initramfs doesn't do this, systemd itself will (as /run is
listed in src/core/mount-setup.c).

-- 
Mantas Mikulėnas <grawity at gmail.com>


More information about the systemd-devel mailing list