[systemd-devel] How to factory reset?

[Tobias Hunger]

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.hunger at 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
> <zbyszek at 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.hunger at 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