From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 03:24:17 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A86106566C for ; Sat, 30 Apr 2011 03:24:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A8B248FC14 for ; Sat, 30 Apr 2011 03:24:17 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 380421FFC35; Sat, 30 Apr 2011 03:07:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B1DFC84530; Sat, 30 Apr 2011 05:07:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Rick Macklem References: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 30 Apr 2011 05:07:09 +0200 In-Reply-To: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> (Rick Macklem's message of "Fri, 15 Apr 2011 20:57:00 -0400 (EDT)") Message-ID: <86r58kfndu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 03:24:18 -0000 Rick Macklem 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) 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 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 So there are (at least) two kernel issues: 1) the "error 19" that occurs with both the old and the new stack 2) the fallback that always uses "nfs" instead of using the correct fstype for whichever NFS stack is loaded. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no