Just a short update: I managed to get my machine image to (kind of) boot in systemd-nspawn this weekend. Kind-of as it tries to mount some drives that are obviously not there in the container. But apart from that it seems to boot fine:-)
On real hardware I am not so lucky: Once I get to system-switch-root.service I get lots of output about missing nodes in dev (/dev/ttyX mostly). This might be due to me messing up the configuration, arch's mkinitcpio being unprepared to handle a stateless system or some problem in systemd. At this time I am not sure which. I am rather positive that this will be really straight forward to figure out once I can actually get a shell in the initrd, which unfortunately seems harder than expected on Arch Linux (provided you use systemd HOOK in /etc/mkinitcpio.conf, which is not the recommended way of doing things):-/ Best Regards, Tobias PS: Any hints on systemd-in-initrd debugging in arch linux would be appreciated at this point:-) On Fri, Mar 13, 2015 at 2:20 PM, Tobias Hunger <tobias.hun...@gmail.com> wrote: > Hi Zbyszek, > > I would expect the machine-id to be written before mount units are > processed, so for that to work I would need to mount /var in the > initrd, wouldn't I? > > Currently I am trying to just write the machine-id to /etc in the > initrd. This makes systemd loose the understanding that /etc is empty > though, which might have some side-effects that I am not yet > anticipating. > > Isn't systemd started from inside the initrd once the new root has > been set up? Maybe I could set $container_uuid and feed the machine-id > to systemd that way? I am afraid that this will lead to some other > side-effects, because systemd might assume to be running inside a > container. Looks like I will have to do some testing over the > weekend:-) > > Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. > > Best Regards, > Tobias > > On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: >> On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: >>> On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger <tobias.hun...@gmail.com> >>> wrote: >>> >> presets and machined ID are applied by PID 1, before it begins with >>> >> starting any units, hence *really* early on. Note though that actually >>> >> /etc/machine-id is used as flag for "is /etc empty". If the file >>> >> exists it is assumed that /etc is provisioned properly. If it is >>> >> missing PID 1 will generate the machiend id and apply presets. >>> > >>> > An OS installer could put the machine-id into /usr just fine (and so >>> > can I) and systemd could just get it from there if available before >>> > generating a new one. >>> > >>> > It would be nice if the machine-id did not change during to a factory >>> > reset: It is used in the logs and changing it will basically make >>> > historical log data much harder to analyze. IIRC networkd also uses it >>> > to generate persistent MAC addresses for containers and such. >>> > >>> > So far this seems to be the only critical piece of information that >>> > can not get restored via tmpfiles.d. >>> >>> Thinking about this a bit longer: /usr does not seem like a good idea. >>> The machine-id is supposed to be unique and usr-images are meant to be >>> reused. >>> >>> Maybe provide a kernel command line option to force the machine-id if >>> none is set yet? >> I think this could be an option. We currently check >> /var/lib/dbus/machine-id, $container_uuid, and >> /sys/class/dmi/id/product_uuid. >> I think that the first should work for your use case, since you keep /var. >> But we also check some commandline option, this seems useful for some >> use cases. >> >> Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel