Hi Lennart, thanks for taking the time to answer! It is highly appreciated.
On Tue, Mar 10, 2015 at 5:01 PM, Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel