Re: Previously working PXE setup now fails
Hi and thanks for your input. If I may, I have several more Q's regarding this issue: As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Q1: I did not realise that. I took out the V4: in exports. However, is it possible to have a mixed-mode, something like /data/amd64 as V3 but /home as V4? Q2: I now get to the BTX loader, wireshark shows correct mount call 192.168.2.3, 192.168.2.1, MOUNT, V3 MNT Call (Reply In 14072) /data/amd64. Unfortunately, I get a complete black screen when I hit enter from BTX (it looks like a lock-up) and wireshark shows no traffic for the problem. To get to this point, I re-anabled some of what I had taken out before, and I now forget which config options are necessary at this point. What I have: (always had this) fstab: 192.168.2.1:/data/amd64 / nfs ro 0 0 boot/loader.conf: boot.nfsroot.server=192.168.2.1 boot.nfsroot.path=/data/amd64 ##_re-enabled_## vfs.root.mountfrom=nfs:192.168.2.1:/data/amd64 vfs.root.mountfrom=nfs boot.nfsroot.options=nolockd vfs.root.mountfrom.options=ro re-enabled in dhcpd.conf option root-path 192.168.2.1:/data/amd64; I can't figure out what needs to be modified and what options can be removed? Thanks for your help. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Previously-working-PXE-setup-now-fails-tp5919662p5923355.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
Beeblebrox wrote: Hi and thanks for your input. If I may, I have several more Q's regarding this issue: As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Q1: I did not realise that. I took out the V4: in exports. However, is it possible to have a mixed-mode, something like /data/amd64 as V3 but /home as V4? Yes, that should be fine. It is only the root fs that won`t work. There are 2 problems: 1 - nfsuserd can`t be running when the root fs is first accessed, so uid vs username mappings aren`t available. (A recent change in the spec that allows a username that is a string of uid digits works around this. It was driven by Linux folks that wanted NFSv4 root file systems to work. This spec is still an IETF draft, so it is hard to say if it supported yet.) 2 - The client mount needs a unique identifier for the client machine. The host uuid used for this is set during booting. To make an NFSv4 root fs to work, there needs to be some way to generate a unique identifier for the machine before it accesses the root fs. So, someday NFSv4 root file systems may work, but not right now. I need to check to make sure this is in the mount_nfs and nfsv4 man pages. Q2: I now get to the BTX loader, wireshark shows correct mount call 192.168.2.3, 192.168.2.1, MOUNT, V3 MNT Call (Reply In 14072) /data/amd64. Unfortunately, I get a complete black screen when I hit enter from BTX (it looks like a lock-up) and wireshark shows no traffic for the problem. To get to this point, I re-anabled some of what I had taken out before, and I now forget which config options are necessary at this point. What I have: (always had this) fstab: 192.168.2.1:/data/amd64 / nfs ro 0 0 boot/loader.conf: boot.nfsroot.server=192.168.2.1 boot.nfsroot.path=/data/amd64 ##_re-enabled_## vfs.root.mountfrom=nfs:192.168.2.1:/data/amd64 vfs.root.mountfrom=nfs boot.nfsroot.options=nolockd vfs.root.mountfrom.options=ro When I`ve done it (not recently), I don`t think I set any of the above in loader.conf. However I also didn`t use a read-only root fs. Hopefully someone who uses NFS root file systems can suggest help. All I did was follow some web page instructions exactly. rick re-enabled in dhcpd.conf option root-path 192.168.2.1:/data/amd64; I can't figure out what needs to be modified and what options can be removed? Thanks for your help. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Previously-working-PXE-setup-now-fails-tp5919662p5923355.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. It took a while to get around to this, but the problem looks like NFS v3 - v4 conflict. Wireshark shows these errors: Program Version: 3 \ V3 Procedure: MNT (1) \Status: ERR_ACCESS (13) But NFS is started as v4. /etc/exports (not sure if correct syntax): V4: / -network 192.168.2.0/26 /data/amd64 -ro -network 192.168.2.0/26 # NFS root /usr/local -ro -maproot=0 -network 192.168.2.0/26 /home -network 192.168.2.0/26 The PXE structure (dhcp tftp) are started as a jail with the jail root folder as the NFS export root (/data/amd64). The jail and NFS services are not started with boot but with separate script. /etc/rc.conf has: rpcbind_flags=-h 192.168.2.1 mountd_flags=-r -n -l -h 192.168.2.1 nfsd_flags=-u -t -n 4 -h 192.168.2.1 nfsv4_only=YES nfsv4_server_enable=YES pxe_start_script.sh: jail -c pxe service rpcbind onestart service mountd onestart service nfsd onestart service nfsuserd onestart # disabled_not_needed? rpc_lockd_enable=YES rpc_statd_enable= I should probablymove the rc.conf flags into my pxe_start_script.sh, but not sure how to pass service start flags in an sh script. Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
Beeblebrox wrote: see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. It took a while to get around to this, but the problem looks like NFS v3 - v4 conflict. Wireshark shows these errors: Program Version: 3 \ V3 Procedure: MNT (1) \Status: ERR_ACCESS (13) But NFS is started as v4. /etc/exports (not sure if correct syntax): V4: / -network 192.168.2.0/26 /data/amd64 -ro -network 192.168.2.0/26 # NFS root /usr/local -ro -maproot=0 -network 192.168.2.0/26 /home -network 192.168.2.0/26 The PXE structure (dhcp tftp) are started as a jail with the jail root folder as the NFS export root (/data/amd64). The jail and NFS services are not started with boot but with separate script. The Mount protocol request in your packet trace specifies a path of /. For the above exports to work, the MNT path must be /data/amd64. (I think this is the root-path option specified in your entry for the client on your dhcp server.) Look at the MNT Call lines in the wireshark trace and get the path to be /data/amd64 and not /. It isn't using NFSv4, so the the V4: / ... line is not relevent to this. As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Good luck with it, rick /etc/rc.conf has: rpcbind_flags=-h 192.168.2.1 mountd_flags=-r -n -l -h 192.168.2.1 nfsd_flags=-u -t -n 4 -h 192.168.2.1 nfsv4_only=YES nfsv4_server_enable=YES pxe_start_script.sh: jail -c pxe service rpcbind onestart service mountd onestart service nfsd onestart service nfsuserd onestart # disabled_not_needed? rpc_lockd_enable=YES rpc_statd_enable= I should probablymove the rc.conf flags into my pxe_start_script.sh, but not sure how to pass service start flags in an sh script. Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
Craig Rodrigues wrote: On Tue, Jun 10, 2014 at 7:31 AM, Beeblebrox zap...@berentweb.com wrote: Then BTX starts to boot the kernel but fails with: pxe_open: server addr: 192.168.2.1 pxe_open: server path: / pxe_open: gateway ip: 192.168.2.1 NFS MOUNT RPC error: 72 In /usr/include/errno.h, error 72 is: #define EBADRPC 72 /* RPC struct is bad */ Take a look at http://www.freebsd.org/doc/handbook/network-pxe-nfs.html and see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. Btw, if it more convenient, you can capture the packets with tcpdump (use -s 0 -w file.pcap ...) and then look at file.pcap via wireshark on any machine it's convenient to install it on. Although wireshark is pretty good at NFS messages, you can email me file.pcap and I'll take a look at it. I am not aware of any bugs in current that cause the RPC messages to be corrupted. Good luck with it, rick -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Previously working PXE setup now fails
I had a perfectly working PXE-booting environment, but now it fails at kernel
boot stage.
Client starts to boot, and var/log/xfer shows the pxeboot file being
transferred from server:
in.tftpd[34792]: RRQ from 192.168.2.3 filename pxeboot
tftpd[5013]: Filename: 'pxeboot'
tftpd[5015]: Mode: 'octet'
tftpd[5015]: 192.168.2.3: read request for //pxeboot: success
Then BTX starts to boot the kernel but fails with:
pxe_open: server addr: 192.168.2.1
pxe_open: server path: /
pxe_open: gateway ip: 192.168.2.1
NFS MOUNT RPC error: 72
/
can't load 'kernel'
Then drops to BTX's rescue command prompt.
* NFS path is visible in showmount -e and I have disabled NFS_V4 to debug
the problem.
* The BTX cli gives failed RPC struct is bad message to ls command.
* rpcbind complains cannot get information for tcp6 udp6. My kernel has
IPV6 disabled and etc/rc.conf has {ipv6_activate_all_interfaces=NO \
ip6addrctl_enable=NO}
* etc/rc.conf has these as well and I tried the problem with NFS_V3 (disable
V4) but got same result:
rpcbind_flags=-h 192.168.2.1
mountd_flags=-r -n -o -l -h 192.168.2.1
nfsd_flags=-u -t -n 4 -h 192.168.2.1
#nfsv4_only=YES
#nfsv4_server_enable=YES
* The only other log entry I can find is:
inetd[4949]: madvise() failed: Operation not permitted
inetd[5012]: setpriority 'root' (daemon): Permission denied
inetd[5014]: setpriority 'root' (daemon): Permission denied
Any suggestions on what else I can try to debug this thing?
-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Previously-working-PXE-setup-now-fails-tp5919662.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
On Tue, Jun 10, 2014 at 7:31 AM, Beeblebrox zap...@berentweb.com wrote: Then BTX starts to boot the kernel but fails with: pxe_open: server addr: 192.168.2.1 pxe_open: server path: / pxe_open: gateway ip: 192.168.2.1 NFS MOUNT RPC error: 72 In /usr/include/errno.h, error 72 is: #define EBADRPC 72 /* RPC struct is bad */ Take a look at http://www.freebsd.org/doc/handbook/network-pxe-nfs.html and see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
