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

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

On Oct 6, 2025, at 9:32 PM, Greg A. Woods <woods%planix.ca@localhost> wrote:
> 
> At Mon, 6 Oct 2025 20:12:10 -0700, Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:
> Subject: Re: Shared-root diskless netboot, critical local/remote mounts, and rc.conf
>> 
>> It’s certainly simpler to change bootparams to add an additional
>> mount or to change imit to invoke an /etc/rc.boot first, but I
>> want to do something that I might have a chance of
>> contributing. :)
> 
> It's not only simpler to fix the NFS boot code to optionally ask for an
> /etc mount, it's the only way to avoid going down a rabbit hole.  I went
> down that rabbit hole once before -- it's a long climb back out and
> nobody really wanted to hear all my trials and tribulations, so I looked
> for an easier solution, and of course mounting /etc before starting init
> was the answer.

Reading code tonight, I’ve found that at least the stock rc.d scripts should be pretty robust against /etc changing out from under them since they use the functions load_rc_config/load_rc_config_var from /etc/rc_subrs -- as long as there’s a way to convey back to /etc/rc that _rc_conf_loaded needs to be set back to false. Unfortunately the use of subshells gets in the way of that. Maybe mountcritremote could be mountcritremote.sh (so it’s sourced rather than run in a subshell) and reset _rc_conf_loaded as well? Not sure yet.

I do agree that the best approach probably is to adjust bootparams to support a NetBSD.etc-path or NetBSD.private-path or something path (or an open-ended set of paths) but then it only works on NetBSD. On the other hand, maybe we don’t really have to care too much about that.

  -- Chris