From owner-freebsd-current@FreeBSD.ORG Wed Jan 30 15:35:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16E9EACE for ; Wed, 30 Jan 2013 15:35:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CC50B131 for ; Wed, 30 Jan 2013 15:35:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEs9CVGDaFvO/2dsb2JhbABFhki4WnOCHgEBAQMBAQEBICsgCxsSBgICDRkCKQEJGA4GCAcEARwEh2oGDK8jkmCBI4t+gliBEwOIYYp+gi6BHI8vgxWBUTU X-IronPort-AV: E=Sophos;i="4.84,569,1355115600"; d="scan'208";a="11566987" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 30 Jan 2013 10:34:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B544DB3F19; Wed, 30 Jan 2013 10:34:44 -0500 (EST) Date: Wed, 30 Jan 2013 10:34:44 -0500 (EST) From: Rick Macklem To: Lars Eggert Message-ID: <1676091515.2505116.1359560084705.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: mounting root from NFS via ROOTDEVNAME MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Craig Rodrigues , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Jan 2013 15:35:08 -0000 Lars Eggert wrote: > Hi, > > On Jan 29, 2013, at 20:22, Craig Rodrigues > wrote: > > What kind of architecture are you trying to do this on? Is this > > i386/amd64 or something else? > > amd64 > > > I am not familiar with netboot compared to > > PXE. Is TFTP involved at all with netboot? > > TFTP is not involved. The kernel gets booted by our custom loader > (over HTTP) and the root FS is supposed to be mounted over NFS. > > > What does your dhcpd configuration file look like? > > Completely standard, with the addition of a "root-path" option. (Which > I would like to get rid of by setting ROOTDEVNAME in the kernel.) > > > Also, are you using the FreeBSD loader, or something else? What > > kinds of > > customizations have you done on the loader? > > Custom loader. > > > If through your setup you have already managed to load the kernel > > over > > the network, then a lot of the hard work has been done. Telling the > > kernel > > where the root file system is located becomes the next tricky part. > > Right, that's the step I am struggeling with. > If you have "options BOOTP" and "options BOOTP_NFSROOT", the VFS_MOUNT()/nfs_mount() call early in vfs_mountroot() calls bootpc_init(). This function and related code is in sys/nfs/bootp_subr.c. At a glance, the code in sys/nfs/bootp_subr.c tries very hard to get "root-path" in several places, so it will take some fiddling to get it to work without the dhcpd returning a root-path option. (I think Ian Lepore has started to work on this.) I don't have any way of testing this until at least April, so I can't really help. It should be possible to modify bootp_subr.c, so that it uses ROOTDEVNAME instead of trying to get "root-path" from the dhcp server when it is specified, but the change will take some work. If you want bootpc_init() to be called when "options BOOTP_NFSROOT" isn't specified, that is a one line change in sys/fs/nfsclient/nfs_clvfsops.c. (Just look for the bootpc_init() call, but I don't see that as being useful? I think changing bootpc_init() and friends to avoid getting root-path when it has already been specified (by ROOTDEVNAME and/or vfs.root.mountfrom) is the best approach, but will require a significant patch to bootp_subr.c. I can see two other approaches to doing this: 1 - Supply a root-path via the dhcpd, but override what it says later in the kernel boot, to use what is specified by ROOTDEVNAME or vfs.root.mountfrom. I haven't looked at what this would take, but I didn't see how it could be done with the current code, because the NFS client code expects a structure called nfsv3_diskless to be filled in by bootpc_init() OR 2 - nfs_diskless(). The call to nfs_diskless() is done when "options NFS_ROOT" is specified, but "options BOOTP" + "options BOOTP_NFSROOT" is not. (Just look at the calls in sys/fs/nfs/nfs_clvfsops.c or sys/nfsclient/nfs_vfsops.c.) It fills the structure in from a bunch of environment variables. These are normally filled in by pxeboot, but you could modify your custom loader to fill them in, which would be this approach. Once eithe nfs_diskless() or bootpc_init() has filled in nfsv3_diskless and set nfs_diskless_valid, then the rest of the code uses what is in that structure, so one of these 2 functions needs to be called, unless you do a major re-write of the diskless NFS booting stuff. Good luck with it, rick > > In src/sys/boot/common/boot.c which is part of the loader (not the > > kernel), > > if you look in the getrootmount() function, > > you will see that the loader will try to figure out where the root > > file > > system > > is by parsing /etc/fstab, and looking for the "/" mount. > > > > So, if your kernel is located in: > > > > /usr/home/elars/dst/boot/kernel/kernel > > > > Then create a file /usr/home/elars/dst/etc/fstab file with something > > like: > > > > # Device Mountpoint FSType > > Options Dump Pass > > 10.11.12.13:/usr/home/elars/dst/ / nfs ro 0 0 > > Thanks, will try that! > > > Alternatively, if you don't want to create an /etc/fstab file, then > > you could put something like this in your loader.conf file: > > > > vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst > > Will try that too, but not sure if this works with our custom loader. > > Lars > > > > > If you can get this to work without introducing new kernel options, > > that would be ideal, because the kernel options you are > > enabling are triggering behaviors. > > > > -- > > Craig Rodrigues > > rodrigc@crodrigues.org > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"