Date: Sat, 30 Apr 2011 08:18:31 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one Message-ID: <410050117.807767.1304165911685.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <86r58kfndu.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
> Rick Macklem <rmacklem@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410050117.807767.1304165911685.JavaMail.root>