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

[Kay Sievers]

On Fri, Dec 27, 2013 at 1:44 PM, Holger Schurig <holgerschurig at gmail.com> wrote:
> If I place an empty /etc/machine-id into the image, then
> /run/machine-id will be bind-mounted over it.
>
> But that file will be different whenever I boot. So obviously I want
> to save it, once my filesystem is fsck'd and mounted read-write. But
> if I do it like that ...

Yes, it's a privacy feature, it should do that: empty file --> random id.

> umount /etc/machine-id
> cp /run/machine-id /etc/machine-id
>
> ... then and between step 1 and 2 some other process might fall on
> it's nose. I noticed that several systemd binaries directly access
> /etc/machine-id via sd_id128_get_machine(). That would mean a race
> condition, or?

Yes, you can mount the root block device to a different place a second
time, and should be able to unlink the file and replace it, then
umount the file on the real /, and all should be atomic.

>> You should always mount a tmpfs as /run, it is not supposed to be the
>> same as /. Omitting the /run tmpfs mount is not supported.
>
> Kay, you're replaying to my point 3. that I already have "taken back"
> :-)   And no, I should *NOT* mount it --- how could I, without an
> initrd?  I don't need to mount it, because systemd mounts it for me
> with one of the functions in src/core/mount-setup.c before calling
> machine_id_setup().

Yeah, I was replying to your "/run is still on the same partition as
/" which sounded like you did something, what systemd itself makes
sure would not happen.

Kay