Simon McVittie <[email protected]> writes: > 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.)
Sorry for not being clear. What I wanted to say was that the first open() call with O_CREAT flag obviously fails, because the root filesystem is by default mounted read-only first and remounted read-write later. I'm testing on Fedora rawhide, which I forgot to mention too. If, for some reason, /etc/machine-id is missing, the logic simply doesn't work. I believe systemd shouldn't fail to boot just because it couldn't write or open the id file. I'm not sure how to solve this problem, though. >> 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? It doesn't help my situation, because I simply remove the file by hand and then try to boot the system. However, it brings a question if "missing /etc/machine-id *and* the machine is still booting" should even be a valid use case. I still believe it should be and it should be handled by systemd, not by external scripts/processes. > S > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745840 -- Jan Synacek Software Engineer, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
