Shared-root diskless netboot, critical local/remote mounts, and rc.conf

[Chris Hanson <cmhanson%eschatologist.net@localhost>]

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