I’ve been looking off and on at what it would take to set up NetBSD for
"NeXT-like” netboot, where every network-booted system shares the same
read-only NFS-mounted root filesystem and per-system content is provided via a
separate NFS mount at /private. This makes keeping multiple netbooted systems
up-to-date easy, because only system-specific information changes.
For background, the way NeXT achieved this was to have the following symlinks
in place (giving their modern names):
/etc → /private/etc
/tmp → /private/tmp
/var → /private/var
The “trick” here is that NeXT also provides a “real” /private/etc in the root
filesystem, so init can run a minimal /etc/rc.boot which triggers the mount of
the system-specific /private *over* the root /private. Then init runs /etc/rc
from this new mount, which uses the information in /etc/hostconfig similarly to
how NetBSD uses /etc/rc.conf.
It seems like this could *almost* be achieved today—and without modifying
init—based on how NetBSD’s /etc/rc has concepts of “critical" local and remote
mounts. The "critical local mounts” dependency seems to be about ensuring /var
is present before starting services that may need it, and “critical remote
mounts” seems to be about ensuring /usr is present. I suspect many things that
depend on the former could depend on the latter safely, or the two could be
consolidated to a single “critical mounts” dependency, but that’s just a gut
feeling based on skimming things, not something I’ve worked through. (It's
pretty nice to be able to generate a .dot file and then examine it in
OmniGraffle on my Mac, thanks to Joerg Sonnenberger for rcorder-visualize.sh!)
The bigger issue I see with achieving this today is that it’s somewhat at odds
with how NetBSD uses /etc/rc.conf: /etc/rc reads /etc/rc.conf almost
immediately, and it’s used even to find things like what the critical local and
remote mounts may be. That said, perhaps there would just need to be an
additional flag, like “reconfaftercriticalmounts=YES” that could cause
/etc/rc.conf to be re-read after critical mounts. This seems like it *might* be
safe since it’s basically how bootconf works, though bootconf also seems to
make the hidden assumption that the contents of /etc/rc.d (and therefore the
output of rcorder) won’t change…
Anyway, has anyone else experimented with this sort of thing or have any
further suggestions? I’m planning to just see how far I can get with it and how
much work it is to tweak the dependencies while not completely screwing things
up…
-- Chris
