Re: FreeBSD nfsroot - will it work with NFSv4.2?

On Sun, Apr 12, 2026 at 4:01 PM Dan Shelton <[email protected]> wrote:
>
> On Mon, 13 Apr 2026 at 00:56, Rick Macklem <[email protected]> wrote:
> >
> > On Sun, Apr 12, 2026 at 3:49 PM Dan Shelton <[email protected]> wrote:
> > >
> > > On Tue, 7 Apr 2026 at 22:27, Rick Macklem <[email protected]> wrote:
> > > >
> > > > On Sun, Apr 5, 2026 at 9:16 AM Rick Macklem <[email protected]> wrote:
> > > > >
> > > > > On Thu, Feb 19, 2026 at 2:23 PM Dan Shelton <[email protected]> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Will a FreeBSD 15.0 diskless setup with nfsroot work with NFSv4.2?
> > > > > I just committed a patch to main that does this, with some limitations.
> > > > > It will be in 15.1.
> > > > >
> > > > > The limitations are:
> > > > > - The server must be configured to handle both NFSv3 and NFSv4
> > > > >   because the bootstrap code still uses NFSv3.
> > > > > - The root directory specified in the "V4:" line in /etc/exports must
> > > > >   be "/" so that the root-path is the same for an NFSv3 and NFSv4 mount.
> > > > > - The NFSv4 server must be configured to use id-numbers in strings and
> > > > >   not be running the nfsused(8) daemon. (This limitation might be lifted
> > > > >   in a future commit which hard-wires enough mapping info to make
> > > > >   things work until the nfsuserd(8) daemon is running.)
> > > > I just did a commit to main that allows the nfsuserd(8) daemon to run
> > > > on the NFSv4 root fs.
> > > >
> > > > I'm not 100% sure if it will work for a read/write root fs mount.
> > > > (I tested a read-only one, as suggested by Section 34.10 of the
> > > > FreeBSD Handbook.
> > > >
> > > > For the nfsuserd(8) daemon setup (ie. name@domain strings for
> > > > uid/gid's), you need..
> > > >
> > > > In /boot/loader.conf
> > > > boot.nfsroot.user_domain="<user-domain>"
> > > > along with the two lines
> > > > nfsuserd_enable="YES"
> > > > nfsuserd_flags="-domain <user-domain>"
> > > > in /etc/sysctl.conf.
> > >
> > > Thank you!
> > >
> > > What about a static mapping until nfsuserd is running?
> > The static mapping is in an array called nfs_prime_userd[].
> > It is filled in statically via initialization in sys/fs/nfs/nfs_commonsubs.c.
> > (It only has root/wheel/bin/operator at this time, which appears
> > sufficient to get booted to where nfsuser(8) starts up.)
>
> Maybe make this two boot parameter strings, one for users and one for groups?
> Like "root@CLIENTDOMAIN(id=0)=root@SERVERDOMAIN(id=0),myuser1@CLIENTDOMAIN(id=345)=eviluser2@SERVERDOMAIN(id=74)"?

I don't think allowing sysadmins to add entries would be a good idea.
Basically, all that is needed is root/wheel so that the read/write /etc
and /var will be set up by /etc/rc.initdiskless.

Then those entries need to be wired into the kernel's cache even
after the nfsuserd(8) is started up, to avoid a hang like...
- Mapping misses for "/etc" while doing stat(2)/getattr.
- Kernel does upccall to nfsuserd(8) to get a mapping.
- nfsuserd(8) tries to access /etc/passwd and hangs
  because "/etc" is already vnode locked by #1.
--> To avoid this, the entries are "hard wired" into the
      cache.
--> I don't think sysadmins should be adding hard wired
      entries.

Also, note that all that happens when most mappings
are missing before the "/etc" and "/var" file systems
are set up is stat(2)/getattr returning nobody/nogroup
for the file. (The root is read-only, so no creation/setattrs
can happen.)
Unless some local change breaks when stat(2)/getattr
returns nobody/nogroup early in going multiuser before
nfsused(8) is running, it should be fine.

rick

>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd
>