NFS and diskless: some questions re nfs_diskless.c

Rick Macklem rmacklem at uoguelph.ca
Mon Feb 16 00:56:40 UTC 2015


Beeblebrox wrote:
> I have several questions on implementing the features in
> nfs_diskless.c. Understanding these parameters are necessary to get
> a decent menu-driven (grub2) boot process working for clients.
> 
> 1. <root> for diskless clients get mounted as V2 instead of V3. I
> have defined { boot.nfsroot.options="nfsv3" }, but has no effect.
> Does the kernel need (options BOOTP_NFSV3)? Considering that
> nfs_diskless.c routine checks "get handle size. If this succeeds,
> it's an NFSv3 setup" and {nd3->root_fhsize = len; is_nfsv3 = 1;}
> might there be easier solution?
> 
Well, after r212125 (about 4.5yrs ago) in head/lib/libstand/nfs.c, this
code knows how to do NFSv3. If you are using a pxeboot built with this
code, I don't know why you would still get NFSv2 instead of NFSv3.
(Check the line for "/" in the diskless root's /etc/fstab to see if
 a version of NFS is specified there. If not, you could try adding the
 "nfsv3" option to that line.)
However, from what you say below, it doesn't sound like you are using
the info that pxeboot sets up.

> 2. My DHCP server has {option root-path} defined and correctly mounts
> the NFS root. However, I would like to offer amd64/i386 choice from
> menu, which requires different root-path. I therefore plan to remove
> {option root-path} from dhcp.conf and pass nfsroot parameter in the
> boot menu using params ( boot.nfsroot.server="192.168.2.1"  \
>  boot.nfsroot.path="/data/amd64" )
> Yet when I do that, the kernel is booted, NIC goes up but:
>   re0 link state changed to UP
>   Received DHCP Ack packet on re0 from 192.168.2.1 (accepted)
>   DHCP/BOOTP timeout for server 255.255.255.255
> The client is on 192.168.2.0/26 (broadcast is 192.168.2.63), Kernel
> has (options BOOTP/ options BOOTP_NFSROOT). Is there a solution to
> this?
> 
There are 2 different ways the kernel can be built for a diskless NFS root.
1 - options NFS_ROOT (but not BOOTP + BOOTP_NFSROOT)
    For this case, the kernel expects a bunch of boot environment variables
    to be set and a function (called nfs_diskless(), I think?) fills in a
    structure called nfs_diskless or nfsv3_diskless from these environment
    variables.
    Although it could be done other ways, normally these environment variables
    are filled in by pxeboot from the DHCP server's info plus what the files
    in the diskless root fs say. (It uses lib/libstand/nfs.c to talk to the
    diskless root fs on the NFS server.)
2 - options BOOTP + BOOTP_NFSROOT
    For this case, code in the kernel sys/nfs/bootp_subr.c talks to the DHCP
    server and the diskless root fs to find out what it needs to fill in
    the structure (nfs_diskless or nfsv3_diskless).
1 and 2 are independent. Depending on the kernel config options, the code does
one or the other. (Take a look at the beginning of nfs_mountroot() in
sys/fs/nfsclient/nfs_clvfsops.c.)

Although this stuff is confusing and convoluted, I think if you build a kernel
with "options NFS_ROOT" (but bot the others), a boot loader can fill in the
environment variables and have them used, just like pxeboot does.
Look in sys/nfs/nfs_diskless.c for the comment at the beginning of
nfs_setup_diskless() to see what these environment variables are.
(Remember this won't be called if BOOTP + BOOTP_NFSROOT
kernel options are specified.)

Good luck with it. You will probably want to add a bunch of printf()s to the
above mentioned functions to try and figure out what gets executed and what
gets set.

rick

> Regards.
> --
> FreeBSD_amd64_11-Current_RadeonKMS
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to
> "freebsd-net-unsubscribe at freebsd.org"
> 


More information about the freebsd-net mailing list