Package:linux-image
Version:3.2.0-3-486_3.2.21-3_i386
This is my first attempt ever, to set up a diskless client using nfs on
the client, but the nfs will not mount. Both the server and client use
the same linux-image. I'm using dnsmasq to provide servers for dhcp and
tftp, with pxe managing all this. The linux-image kernel and initrd get
sent to the client and the client starts booting the OS. All OK so far.
But at the point where the booting client tries to mount the nfs file
system from the server, it fails. At this point I see on the screen of
the client a whole series of the same message "Retrying nfs mount
mount: Device or resource busy" Then after many such error messages, it
gives up and spawns an (initramfs) shell.
A clue to why this happens is found in /var/log/syslog. It shows that
there initially were 2 mount requests sent from the client. The first
request apparently succeeds in mounting the nfs but the second request fails
(coincides with the "busy" error message in syslog) since the nfs is
already mounted on the client. So then the server sends a unmount
request to the client. If the normal boot process continued from here,
it would likely be OK. But what happens instead is that another mount
request is sent to the server and the sequence of: mount request, busy
error, unmount request continues. This (mount retry's) repeats many
time until it gives up.
So the problem is that instead of just sending one mount request to the
server, the client sends a second mount request about a second later and
then continues to retry mounting when the nfsroot is already mounted.
The result is a failure to boot.
Here's an excerpt from syslog on the server: (..21 is the client.
daveslinux is the server)
May 29 21:27:36 daveslinux dnsmasq-tftp[1484]: sent
/var/lib/tftpboot/pxelinux.cfg/default to 192.168.0.21
May 29 21:27:40 daveslinux dnsmasq-tftp[1484]: sent
/var/lib/tftpboot/boot/vmlinuz to 192.168.0.21
May 29 21:27:51 daveslinux dnsmasq-tftp[1484]: sent
/var/lib/tftpboot/boot/initrd to 192.168.0.21
May 29 21:28:00 daveslinux dnsmasq-dhcp[1484]: DHCPDISCOVER(eth0)
00:0b:db:1a:6a:95
May 29 21:28:00 daveslinux dnsmasq-dhcp[1484]: DHCPOFFER(eth0) 192.168.0.21
00:0b:db:1a:6a:95
May 29 21:28:00 daveslinux dnsmasq-dhcp[1484]: DHCPREQUEST(eth0) 192.168.0.21
00:0b:db:1a:6a:95
May 29 21:28:00 daveslinux dnsmasq-dhcp[1484]: DHCPACK(eth0) 192.168.0.21
00:0b:db:1a:6a:95
May 29 21:28:01 daveslinux rpc.mountd[2014]: authenticated mount request from
192.168.0.21:922 for /nfsroot (/nfsroot)
May 29 21:28:02 daveslinux rpc.mountd[2014]: authenticated mount request from
192.168.0.21:924 for /nfsroot (/nfsroot)
May 29 21:28:02 daveslinux rpc.mountd[2014]: authenticated unmount request from
192.168.0.21:924 for /nfsroot (/nfsroot)
May 29 21:28:03 daveslinux rpc.mountd[2014]: authenticated mount request from
192.168.0.21:926 for /nfsroot (/nfsroot)
May 29 21:28:03 daveslinux rpc.mountd[2014]: authenticated unmount request from
192.168.0.21:926 for /nfsroot (/nfsroot)
(These mount-unmount sequences repeat many more times. Note the +2
increment of the 922 number (What is this? A sequence number?)
The reason I think that the first mount request succeeds is that the
nfsroot file system is found in /root of the client after it spawns the
(initramfs) shell.
-------------------------------------------------------------------------------
Here's a copy of the default file in .../pxelinux.cfg
DEFAULT daveslinux-kern
LABEL daveslinux-kern
kernel boot/vmlinuz
append "ip=dhcp boot=/dev/nfs nfsroot=192.168.0.42:/nfsroot
initrd=boot/initrd nfsrootdebug rw"
LABEL bak
kernel boot/vmlinuz
append "ip=dhcp boot=/dev/nfs nfsroot=192.168.0.42:/nfsroot
initrd=boot/initrd nfsrootdebug rw"
-------------------------------------------------------------------------------
There is also an ethernet problem with eth0 but I don't think it should
cause the above problem, but it might. I've had to set my server nic to half
duplex since the kernel ADDCONF(NETDEV_CHANGE) can't set full duplex
(set via ethtool) in the client. The nic card on the server is old and
doesn't support autoconfig, but it does support full duplex which I use
for other purposes. So what seems to happen is that the client kernel
tries autonegotiation with the server nic and there is no response from
the server nic. Then by default it sets half duplex. This situation is
a "duplex mismatch" as described in Wikipedia. So I avoid this mismatch
by setting half duplex for the server. Now could collisions and
retransmission possibly result in the initial mount request getting thru
twice? I also saw a message from the client during booting something to
the effect of IP-Config: no response after 2 sec., giving up but the
messages flash by so fast I can't read them well.
The server is i586 and the client is i686 both running the same OS which
should work on both.
David Lawyer
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
