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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel