[systemd-devel] How to factory reset?
lennart at poettering.net
Tue Mar 10 09:01:15 PDT 2015
On Mon, 09.03.15 12:02, Tobias Hunger (tobias.hunger at gmail.com) wrote:
> Hi everybody,
> I am running a kiosk-like box here and have a read-only copy of /etc
> hidden away in /usr/ somewhere. /etc is a symlink to that directory
> and that works fine.
> Recently I thought I'd experiment with factory reset. My idea was to
> use a tmpfs mounted on /etc instead of that symlink and populate that
> from the directory in /usr on boots. That way I can still experiment
> with changes to the configuration, but on all reboots I get the
> trusted state back.
> So how is factory reset supposed to work is systemd?
So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?
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
There's currently no explicit support for this to make this easy from the
initrd. (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
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.
> Unfortunately the dbus.service will not come up, claiming that there
> is no /etc/dbus-1/system.conf. This file is in the tarball, and the
> output during boot-up suggests that dbus.service is started only after
> the /etc-tarball is extracted, so that file should be there. There
> seems to be a dbus.socket involved in the start of dbus.service and
> that is started before the tarball is extracted.
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...
> Should I take a different approach entirely and e.g. populate /etc in
> the initrd? I'd like to keep the initrd generic if I can, so I am not
> happy with that idea.
> I am using systemd-nspawn for my experiments. This seems to add some
> files to /etc, which is not ideal, but does not seem to hurt too much
> either. Is there a better way to test setups like the one I intend to
nspawn's --volatile= switch is how i did most of my own testing...
> Does systemd-nspawn indeed add/change files in /etc of the directory
> it is running from?
Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
create a machine ID, and apply presets and stuff...
Lennart Poettering, Red Hat
More information about the systemd-devel