[I'm not sure if -stable is the best list for this but anyway...] I'm trying to convert an old laptop running FreeBSD 8.0 into a diskless client (since its internal HDD is growing bad spots faster than I can repair them). I have it pxebooting nicely and running with an NFS root but it then reports locking problems: devd, syslogd, moused (and maybe others) lock their PID file to protect against multiple instances. Unfortunately, these daemons all start before statd/lockd and so the locking fails and reports "operation not supported". It's not practical to reorder the startup sequence to make lockd start early enough (I've tried). Since the filesystem is reserved for this client, there's no real need to forward lock requests across the wire and so specifying "nolockd" would be another solution. Looking through sys/nfsclient/bootp_subr.c, DHCP option 130 should allow NFS mount options to be specified (though it's not clear that the relevant code path is actually followed because I don't see the associated printf()s anywhere on the console. After getting isc-dhcpd to forward this option (made more difficult because its documentation is incorrect), it still doesn't work. Understanding all this isn't helped by kenv(8) reporting three different sets of root filesystem options: boot.nfsroot.path="/tank/m3" boot.nfsroot.server="192.168.123.200" dhcp.option-130="nolockd" dhcp.root-path="192.168.123.200:/tank/m3" vfs.root.mountfrom="nfs:server:/tank/m3" vfs.root.mountfrom.options="rw,tcp,nolockd" And the console also reports conflicting root definitions: Trying to mount root from nfs:server:/tank/m3 NFS ROOT: 192.168.123.200:/tank/m3 Working through all these: boot.nfsroot.* appears to be initialised by sys/boot/i386/libi386/pxe.c but, whilst nfsclient/nfs_diskless.c can parse boot.nfsroot.options, there's no code to initialise that kenv name in pxe.c dhcp.* appears to be initialised by lib/libstand/bootp.c - which does include code to populate boot.nfsroot.options (using vendor specific DHCP option 20) but this code is not compiled in. Further studying of bootp.c shows that it's possible to initialise arbitrary kenv's using DHCP options 246-254 - but the DHCPDISCOVER packets do not request these options so they don't work without special DHCP server configuration (to forward options that aren't requested). vfs.root.* is parsed out of /etc/fstab but, other than being reported in the console message above, it doesn't appear to be used in this environment (it looks like the root entry can be commented out of /etc/fstab without problem). My final solution was to specify 'boot.nfsroot.options="nolockd"' in loader.conf - and this seems to actually work. It seems rather unfortunate that FreeBSD has code to allow NFS root mount options to be specified via DHCP (admittedly in several incompatible ways) but none actually work. A quick look at -current suggests that the situation there remains equally broken. Has anyone else tried to use any of this? And would anyone be interested in trying to make it actually work? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110101/b3520ba1/attachment.pgp
> > --2iBwrppp/7QCDedR > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > [I'm not sure if -stable is the best list for this but anyway...] > > I'm trying to convert an old laptop running FreeBSD 8.0 into a diskless > client (since its internal HDD is growing bad spots faster than I can > repair them). I have it pxebooting nicely and running with an NFS root > but it then reports locking problems: devd, syslogd, moused (and maybe > others) lock their PID file to protect against multiple instances. > Unfortunately, these daemons all start before statd/lockd and so the > locking fails and reports "operation not supported". > > It's not practical to reorder the startup sequence to make lockd start > early enough (I've tried). > > Since the filesystem is reserved for this client, there's no real need > to forward lock requests across the wire and so specifying "nolockd" > would be another solution. Looking through sys/nfsclient/bootp_subr.c, > DHCP option 130 should allow NFS mount options to be specified (though > it's not clear that the relevant code path is actually followed because > I don't see the associated printf()s anywhere on the console. After > getting isc-dhcpd to forward this option (made more difficult because > its documentation is incorrect), it still doesn't work. > > Understanding all this isn't helped by kenv(8) reporting three different > sets of root filesystem options: > boot.nfsroot.path=3D"/tank/m3" > boot.nfsroot.server=3D"192.168.123.200" > dhcp.option-130=3D"nolockd" > dhcp.root-path=3D"192.168.123.200:/tank/m3" > vfs.root.mountfrom=3D"nfs:server:/tank/m3" > vfs.root.mountfrom.options=3D"rw,tcp,nolockd" > > And the console also reports conflicting root definitions: > Trying to mount root from nfs:server:/tank/m3 > NFS ROOT: 192.168.123.200:/tank/m3 > > Working through all these: > boot.nfsroot.* appears to be initialised by sys/boot/i386/libi386/pxe.c > but, whilst nfsclient/nfs_diskless.c can parse boot.nfsroot.options, > there's no code to initialise that kenv name in pxe.c > > dhcp.* appears to be initialised by lib/libstand/bootp.c - which does > include code to populate boot.nfsroot.options (using vendor specific > DHCP option 20) but this code is not compiled in. Further studying > of bootp.c shows that it's possible to initialise arbitrary kenv's > using DHCP options 246-254 - but the DHCPDISCOVER packets do not > request these options so they don't work without special DHCP server > configuration (to forward options that aren't requested). > > vfs.root.* is parsed out of /etc/fstab but, other than being > reported in the console message above, it doesn't appear to be > used in this environment (it looks like the root entry can be > commented out of /etc/fstab without problem). > > My final solution was to specify 'boot.nfsroot.options=3D"nolockd"' in > loader.conf - and this seems to actually work. > > It seems rather unfortunate that FreeBSD has code to allow NFS root > mount options to be specified via DHCP (admittedly in several > incompatible ways) but none actually work. A quick look at -current > suggests that the situation there remains equally broken. > > Has anyone else tried to use any of this? And would anyone be interested > in trying to make it actually work?Hi Peter, i have beed doing diskless booting for a long time, and am very pleased (though 8.2-prerelease is causing some problems :-). In my case /var is mfs, or ufs/zfs, and have no lockd problems. here is what you need to do: either change in libstand/bootp.c: #define DHCP_ENV DHCP_ENV_NO_VENDOR to #define DHCP_ENV DHCP_ENV_FREEBSD or pick my version from: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ and compile a new pxeboot. this new pxeboot will allow you to pass via dhcp some key options. next, take a look at ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/rc.initdiskless make sure that your exported root has /.etc If you'r /var is also nfs mounted, maybe unionfs might help too. just writing quickly so you won't feel discouraged, and that diskless actually works. danny
Daniel Braniss writes...> I have it pxebooting nicely and running with an NFS root > but it then reports locking problems: devd, syslogd, moused (and maybe > others) lock their PID file to protect against multiple instances. > Unfortunately, these daemons all start before statd/lockd and so the > locking fails and reports "operation not supported".Are you mounting /var via nfs? We have been running FreeBSD diskless for several years, and have never run into this problem - but we use a memory filesystem. The memory filesystem can be quite small. Our methods are documented at http://www.nber.org/sys-admin/FreeBSD-diskless.html If that isn't the problem, can you guess what we are doing differently to avoid it? I note that the response to your message from "danny" offers the ability to pass arguments to the nfs mount command, but also seems to offer a fix for the fact that "classes" are not supported under PXE: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/90368 I hope "danny" will offer a patch to mainline code - it would be an important improvement (and already promised in the documentation). (I am sorry if this doesn't thread properly - I just joined the list after seeing the message). The thread is available at: http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060854.html Daniel Feenberg