RFC: make the experimental NFS subsystem the default one

[Rick Macklem]

> Rick Macklem <rmacklem at uoguelph.ca> writes:
> > Well, I've PXE booted from it using the old pxeboot code that used
> > NFSv2
> > and the recent code that I modified to use NFSv3. I don't see why
> > there
> > would be a problem, but obviously I can't guarantee that.
> 
> I've seen some pxeboot-related weirdness with the new code...
> 
> Server: ds4.des.no, amd64, FreeBSD 9.0 r221100
> Client: via.des.no, i386, FreeBSD 9.0 r221205
> 
> (both with mods, but none that would affect NFS)
> 
> Note that they conveniently bracket the switch - the server runs the
> old
> NFS code while the client runs the new.
> 
> Booting a customized kernel with the new NFS stack results in a weird
> error message from mountroot:
> 
> Trying to mount root from nfs:ds4:/jail/via [rw]...
> mountroot: waiting for device ds4:/jail/via ...
> Mounting from nfs:ds4:/jail/via failed with error 19.
> Trying to mount root from nfs: []...
> NFS ROOT: 10.0.0.4:/jail/via
> 
> (error 19 is ENODEV)
> 
I always get this error and got it even before I did the switch, I think?
It's caused by vfs_mountroot_parse() finding an entry in the fstab, which
then calls parse_mount(). Basically anything that specifies a non-NULL
"dev" argument is going to fail for NFS. (See the "waiting for device
ds4:/jail/via" which indicates "dev" is set to that. The failure and
error message is because parse_mount_dev_present() can't find a device
file called "ds4:/jail/via", which it shouldn't be able to. I can't see
anything that would have skipped doing this before the switchover?

I don't think my changes made this any different. So, you didn't get this
before you switched over?

> Booting a customized kernel with the old NFS stack (and with
> /etc/fstab
> altered to list / as oldnfs instead of nfs) produces a slightly
> different result:
> 
> Trying to mount root from oldnfs:ds4:/jail/via [rw]...
> mountroot: waiting for device ds4:/jail/via ...
> Mounting from oldnfs:ds4:/jail/via failed with error 19.
> Trying to mount root from nfs: []...
> Mounting from nfs failed with error 2: unknown file system.
> 
> Note that after the first attempt fails, it tries again with "nfs"
> instead of "oldnfs". If I type "oldnfs:" at the mountroot prompt, I
> get:
> 
> Trying to mount root from oldnfs: []...
> NFS ROOT: 10.0.0.4:/jail/via
> 
You can get around this by putting a line like:
vfs.root.mountfrom="oldnfs:"
- in the boot/loader.conf on the root fs in the server.

It will then use "oldnfs:" instead of the default "nfs:" (which is
hardwired by setting rootdevnames[0] to it).

> The rc scripts also get confused because they think the NFS client
> code
> is not loaded, and try to load it again, leading to the following
> kernel
> error message:
> 
> interface oldnfs.1 already present in the KLD 'kernel'!
> 
> accompanied by a message from the script itself:
> 
> /etc/rc: WARNING: Unable to load kernel module nfsclient
> 
Ok, I'll need to look at this. At a glance, I see a load_kld,
but that won't get upset if it's already loaded. (It does need
to be fixed, though, since it refers to nfsclient as the module
for "nfs" instead of nfscl.)

> So there are (at least) two kernel issues:
> 
> 1) the "error 19" that occurs with both the old and the new stack
> 
I don't know if this is considered a bug or a feature, but I think it
has been there for a while and happened before the switchover.

If you could test a pre-switchover (but recent) client and see if the
message shows up, that would be appreciated.

> 2) the fallback that always uses "nfs" instead of using the correct
> fstype for whichever NFS stack is loaded.
> 
The default is changed via the vfs.root.mountfrom="oldnfs:" line
added to boot/loader.conf on the root fs on the server. That
is mentioned in UPDATING.

Thanks for pointing these out, rick