[systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?

Peeters Simon peeters.simon at gmail.com
Mon Jan 7 05:54:49 PST 2013


> I was thinking, is it a general stated aim that we should be able to
> boot with an empty /etc? I know this isn't true today, but with
> appropriate effort is that where we should be aiming?

I have been thinking about this too, and I am even planning on doing
some experiments with this.
Currently there are a couple of issues:
 - Some software just fails if they can't read there config file
 - Most software does not allow for a separate "distribution" and
"local" configuration like systemd does
 - A lot of software does not have any sensible default behavior when
there config file is missing.
 - Some files are needed quiet hard (passwd, group, shadow ,...)
The first three should be fixed upstream.
The last point is something i would fix with a systemd generator
overriding default.target with setup.target if one of these files are
missing.

> I guess the same should be true of /var too probably (i.e. packages
> should be able to cope with initing themselves on first use and not rely
> on doing it at package install).

I personally think /var is easier than /etc, since most programs
already do there initing partially, the only problem is that they
don't create there own directories so they fail with an empty /var.
But this can easily be fixed using systemd-tmpfiles.
There is on my system only one problem in /var: rpm (which if it
depended on me belongs in /usr somewhere)

Once both /etc and /var can be empty, the only things needed to boot a
new machine are a kernel, /bin, /lib and /usr.
This would also mean that (together with /bin, /sbin and /lib being
symlinks) all packages except those involving /boot should be
contained within /usr (which can be ro during normal operation)


Simon

PS: nice to know other people are thinking in the same direction


More information about the systemd-devel mailing list