[systemd-devel] How to factory reset?

[Tobias Hunger]

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