On Mon, 09.03.15 12:02, Tobias Hunger (tobias.hun...@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 host OS. 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 cmdline option. 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 > get? 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 -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
