[systemd-devel] How to factory reset?

[Tobias Hunger]

Hi Lennart,

thanks for taking the time to answer! It is highly appreciated.

On Tue, Mar 10, 2015 at 5:01 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> So you want not just factory reset, but actually a stateless system,
> where every single boot is basically a factory reset?

Yes, but I do have a state that I want to be applied by default at all times.

> My recommendation would be to set this up within the initrd: mount a
> tmpfs as /, then mount the physical /usr into it and transition to the
> host OS.

That is a great idea! I was so focused on having a tmpfs on /etc that
I did not even think about that:-/

I would like to keep e.g. logs between reboots, so maybe I can just
have /var mounted from somewhere else.

> There's currently no explicit support for this to make this easy from the
> initrd.

There are flags to set the root filesystem and equivalent flags for
the usr one, so that should not be too hard to do.

> (It is available in nspawn though with the --volatile=)
> switch. But it's on the todo list to add that, so that what I describe
> above is easily available. We also should provide a scheme that one
> can flush /etc explicitly ones for a factory reset, via a kernel
> cmdline option.

Please do not do that.

Even if all filesystems are encrypted you could factory-reset random
computers you have access to, simply by editing the bootloader
configuration file usually found in the poorly protected EFI
partition!

Better have a unit that deletes /etc before the system is shut down.
That way you at least need to have root access to the running machine
to trigger a factory reset. That keeps at least people with encrypted
drives save:-)

> That said, I figure it should suffice to add entries for / and /usr to
> the fstab and get the initrd to make use of it.

I do not have no stinking fstab:-)

My boxes are built up from bits and pieces of configuration. The mount
units make are just so much nicer to handle than having several pieces
edit the same file:-)

> Yes, dbus is currently not compatible with stateless bootups. PAM is
> neither. For PAM we ship a tmpfiles snippet to work around this, for
> dbus we don't though, since kdbus kinda makes the problem go away...

I do have state for PAM, dbus and everything else, I was just not able
to get it into place in time for those services to start properly.

There are quite a few services with a condition of "writable /etc",
and with the setup I attempted /etc was writable, even before I
managed to put my tmpfs into place and extract my configuration there.

> nspawn's --volatile= switch is how i did most of my own testing...

I did not use --volatile since I need to boot from an image that is
considerably different from the one on my development machine. So I
will have to set up a tmpfs manually and mount a usr there and then
just use "normal" nspawn with --directory.

Having --volatile=/path/to/usr/directory would be nice to have for the
experiments I do right now. I guess that is not so very common that it
makes sense to consider sending in a patch for that.

> Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
> create a machine ID, and apply presets and stuff...

I *have* a machine ID and everything. Can I get that information into
place somehow *before* systemd creates all of that?


Thanks again for your reply. You did provide some food for further experiments:

1) Extract my etc-tarball to /usr/share/factory/etc and remove /etc
from the root-image. Keep the etc.mount unit.

2) Try a empty root image with my etc-tarball extracted to
/usr/share/factory/etc and no etc.mount.

3) Add var.mount to the setup of 2) to keep the logs.

With a bit of luck that should stop all the units that have a
condition on a writable /etc from getting started.

I'll get back with results:-)

Best Regards,
Tobias