From owner-freebsd-current@FreeBSD.ORG Wed Oct 14 20:24:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05247106568F for ; Wed, 14 Oct 2009 20:24:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id AE1A68FC26 for ; Wed, 14 Oct 2009 20:24:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAPQ1UqDaFvI/2dsb2JhbADacoQuBIFbiRI X-IronPort-AV: E=Sophos;i="4.44,561,1249272000"; d="scan'208";a="51625694" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 14 Oct 2009 16:24:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id EF58F9400D4; Wed, 14 Oct 2009 16:24:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwckiPZG9CgI; Wed, 14 Oct 2009 16:24:14 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id ACCE79400A6; Wed, 14 Oct 2009 16:24:14 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9EKUmx02790; Wed, 14 Oct 2009 16:30:48 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 14 Oct 2009 16:30:48 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Daniel Braniss In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC1 and BOOTP_NFSV3 regression? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:24:18 -0000 On Sun, 4 Oct 2009, Daniel Braniss wrote: > I'm not sure when this happened, but a kernel compiled with > BOOTP_NFSV3 fails when the server is not FreeBSD (ie NetAPP). > > before, with the option set, only when kernel_options="nfsv3" was set > it would fail/panic, this way, I could control which diskless, shearing the > same kernel, would boot with nfsv3 and which not, dependig on the server. > > there is hope! before it would panic when receiving a v3 file handle, now > it fails, but panics later when no init is found :-) > > is anyone with enough nfs v2/v3 knowledge willing to fix this? > Just fyi, the change of using NFSv3 by default resulted in this. The poster has confirmed that using "nfsv2" as an explicit option, allows the boot to work against a non-FreeBSD server. The problem is that nfs_setup_diskless() in sys/nfsclient/nfs_diskless.c assumed an NFSv2 type file handle, and then sys/nfsclient/nfs_vfsops.c sets the file handle size to NFSX_V3FH (which is the size of a FreeBSD server's NFSv3 file handle). At a glance, changing nfs_setup_diskless() to set the file handle size based on the length of boot.nfsroot.nfshandle is easy, but then it gets interesting... - In lib/libstand/nfs.c, there is NFSv2 code that fills in boot.nfsroot.nfshandle and adding/converting this to use NFSv3 wouldn't be too hard (more work than the above, but..). --> But I can't see how it can be told to use NFSv2 vs NFSv3? (Does anyone know of a way or would trying NFSv3 and then falling back to NFSv2 make sense?) I don't have a diskless NFS setup, so I'm going to have to depend upon others to do testing. (The poster is willing to do some testing in about 2 weeks.) I don't think this can be done for 8.0. If the change is considered a regression that needs to be fixed for 8.0, taking NFSMNT_NFSV3 out of the default flags in nfs_setup_diskless() would but it back the way FreeBSD7 behaves. I'll let others decide if this should be done. rick