[systemd-devel] How to factory reset?
tobias.hunger at gmail.com
Tue Mar 10 10:13:08 PDT 2015
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
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
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
> 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:-)
More information about the systemd-devel