Re: classes and kernel_cookie was Re: Specifying root mount options on diskless boot.
On 2011-Jan-09 10:32:48 -0500, Daniel Feenberg feenb...@nber.org wrote:
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
Actually, that was me, not Daniel.
Are you mounting /var via nfs?
Yes. I'm using diskless in the traditional Sun workstation style -
the system itself is running with a normal filesystem which is all NFS
mounted from another (FreeBSD) server. I'm aware of the MFS-based
read-only approach but didn't want to use that approach.
I note that the response to your message from danny offers the ability
to pass arguments to the nfs mount command,
Actually, my original mail indicates that that I'm aware you can pass
options to the NFS mount command (passing nolockd will solve my
problem). My issue is that there are several incompatible approaches
and none of them work by default.
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 wasn't previously aware of that PR but it is consistent with my
findings.
On 2011-Jan-10 10:52:34 +0200, Daniel Braniss da...@cs.huji.ac.il wrote:
I'm willing to try and add the missing pieces, but I need some better
explanantion as to what they are, for example, I have no clue what the
kernel_cookie is used for, nor what the ${class} is all about.
I'm also happy to patch the code but feel that both PXE and BOOTP should
be consistent and I'm not sure which is the correct approach.
BTW, it would be kind if the line in the pxeboot(8):
As PXE is still in its infancy ...
can be changed :-)
Well, there are still some issues with PXE booting FreeBSD - eg as
discussed here. But, I agree, that comment can probably go.
--
Peter Jeremy
pgp1ovrNzYvjf.pgp
Description: PGP signature
classes and kernel_cookie was Re: Specifying root mount options on diskless boot.
...
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'm willing to try and add the missing pieces, but I need some better
explanantion as to what they are, for example, I have no clue what the
kernel_cookie is used for, nor what the ${class} is all about.
BTW, it would be kind if the line in the pxeboot(8):
As PXE is still in its infancy ...
can be changed :-)
danny
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Specifying root mount options on diskless boot.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Specifying root mount options on diskless boot.
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? You can use the nolockd mount option to make locking happen locally in the client. (Only a problem if the file(s) being locked are concurrently shared with other clients.) I don't know if this would fix your diskless problem. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Specifying root mount options on diskless boot.
--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=3D192.168.123.200 dhcp.option-130=3Dnolockd dhcp.root-path=3D192.168.123.200:/tank/m3 vfs.root.mountfrom=3Dnfs:server:/tank/m3 vfs.root.mountfrom.options=3Drw,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=3Dnolockd' 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_ENVDHCP_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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Specifying root mount options on diskless boot.
[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 pgpVVITD1dFyb.pgp Description: PGP signature
