[systemd-devel] Incorrect logic when /etc/machine-id is missing

[Simon McVittie]

On 22/09/14 10:27, Jan Synacek wrote:
> If /etc/machine-id is missing on the system, the first open() call
> should probably handle that case. That's actually not true (at least on
> my system), because the underlying filesystem is read-only at that
> time.

*What* is not true on your system?

Are you saying that it is not true that /etc/machine-id is missing?
(From context, probably not.)

Are you saying that the first open() call doesn't handle ENOENT? (It
"handles" it by trying the second open() call, in the hope that that
might work better, because maybe the first one failed with EPERM; trying
the second one on ENOENT is useless, but harmless.)

> Now I was determined to fix this bug, however I'm left clueless as to
> how this is actually supposed to work. Is the entire logic in this piece
> of code wrong, or am I missing something? How is the
> (re)generating/mounting of machine-id supposed to work?

Installation of systemd is meant to create and populate /etc/machine-id
(in the dpkg postinst, RPM %post, or whatever is the equivalent on your
distribution).

If that doesn't happen, systemd does the best it can to rectify the
situation. Re-creating it would work, if your initramfs happened to have
mounted the root filesystem read/write.

If you're deleting /etc/machine-id in order to wipe a machine's identity
when cloning the filesystem, then, yes, the "generate a temporary
machine ID and mount it over the top" logic is not going to work. In
Debian's live-build tool, I contributed a patch[1] to change the logic
from "delete /etc/machine-id" to "truncate /etc/machine-id to 0 bytes",
which works better. That might help your situation?

    S

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745840