PXE boot NFS root problem
I am doing a PXE boot via NFS root. while booting, following messages shows and stays there:
VFS: Cannot open root device "nfs" or unknown-block(0-255) Please append a correct "root=" root option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0-255) Here are my configuration files: PXE server IP: 192.168.1.1 client: 192.168.1.200 I have started NFS server using yast. /pxelinux.cfg/default ============================== default NFSROOT timeout 1000 # NFSROOT label NFSROOT kernel bzImage append console=ttyS0,9600,8n1 init=/sbin/init root=/dev/nfs rw nfsroot=192.168.1.1:/nfsroot ip=192.168.1.200:192.168.1.1:255.255.255.0::off noapic acpi=off /etc/exports =============================== /nfsroot *(rw,no_all_squash,no_root_squash) /etc/dhcp.conf =============================== option routers 192.168.1.1; allow booting; allow bootp; ddns-update-style ad-hoc; default-lease-time 2592000; subnet 192.168.1.0 netmask 255.255.255.0 { filename "pxelinux.0"; range 192.168.1.100 192.168.1.200; default-lease-time 1209600; max-lease-time 31557600; next-server 192.168.1.1; } Kernel version is 2.6.24.4 and it is compiled with the following configuration options: CONFIG_NFS_FS (NFS filesystem spport) CONFIG_ROOT_NFS (root file system on NFS) CONFIG_NET_ETHERNET (10 OR 100Mbit) CONFIG_IP_PNP (kernel level autoconfiguration) CONFIG_IP_PNP_BOOTP (BOOTP support) any help is much appreciated. regards -Fardad |
I think you need this "IP: RARP support" built in as well
Code:
CONFIG_IP_PNP_RARP=y |
Now I am getting following message:
--------------------------------------------------------------------- Looking up port of RPC 100003/2 ON 192.168.1.1 rpcbind: server 192.168.1.1 not responding, time out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/1 ON 192.168.1.1 rpcbind: server 192.168.1.1 not responding, time out Root-NFS: Unable to get nfsd port number from server, using default mount:server 192.168.1.1 not responding, time out Root-NFS: Server returned -5 while mounting /nfsroot VFS: Unable to mount root fs via NFS, trying floppy. VFS: Insert root floppy and press Enter. ---------------------------------------------------------------- Note: PXE:/tftpboot # rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100024 1 udp 39508 status 100021 1 udp 39508 nlockmgr 100021 3 udp 39508 nlockmgr 100021 4 udp 39508 nlockmgr 100024 1 tcp 40179 status 100021 1 tcp 40179 nlockmgr 100021 3 tcp 40179 nlockmgr 100021 4 tcp 40179 nlockmgr 100005 1 udp 731 mountd 100005 1 tcp 732 mountd 100005 2 udp 731 mountd 100005 2 tcp 732 mountd 100005 3 udp 731 mountd 100005 3 tcp 732 mountd PXE:/tftpboot # ps -A | grep nfs 12843 ? 00:00:00 nfsd4 12844 ? 00:00:00 nfsd 12845 ? 00:00:00 nfsd 12846 ? 00:00:00 nfsd 12847 ? 00:00:00 nfsd PXE:/tftpboot # ps -A | grep dhcp 2870 ? 00:00:00 dhcpd 8444 ? 00:00:00 dhcpcd |
The problem now is your NFS server the kernel is now working, you need to double check your NFS server it seems like a firewall is blocking connections from the NFS client.
|
I've been beating my head against getting this to work as well today.
In my case when I had a similar problem to yours it was because somewhere in repeated kernel builds trying to get udev to work I failed to make the ethernet driver 'built in' as opposed to a module. The 10 lines or so above "VFS: Unable to mount" line should be your ether card configuring. If you're using the new IP-Config you should see: IP-Config: Complete: device=eth0, addr=w.z.y.z etc host=w.x.y.z etc bootserver=w.x.y.z etc It threw me off at first since historically if PXE got an IP you were golden, it now does it twice, once via PXE then in the kernel ... it has to have a built-in driver to work. My problem is udev (and init)... with devfs it was a snap ... I'm completely hung on init not starting ... I get VFS: Mounted root (nfs filesystem) readonly Free unused kernel memory: 224k freed then nada. I can see the benefit of udev over devfs and the potential benefit of IP-Config in the kernel but it seems there's more nfsroot booting type changes from 2.6.22 to 2.6.24 than my experience from say 2.0.x to 2.6. James |
guys,
at this time I have done everything that I could do, still no success. datopdog, what do you mean by firewall? How should I find out if there is any firewall involved? If you mean NFS firewall, I have used yast to start the server with "no firewall" . jrobnett, Any success on your side so far? thanks |
Yes and no. As I alluded in my first post the problem I had
that was similar to yours was simply failing to statically compile in the ethernet driver (it got switched to module accidentally). Do you see the IP-Config messages I mentioned above your mount failure ? Can you ping your client system after the mount fails. If not my guess is you have your ethernet device compiled as a module. I'm still having other issues that I can't seem to wrap my head around. We're using a stock RHEL4-4 image as the base OS and 2.6.24.4 and/or 2.6.25 kernel. Historically I never had an issue building a kernel that didn't need an initrd image to boot nfsroot via PXE(1). For some reason I now have to make one. Sadly RHEL4 uses 'nash' as it's command interpreter and the 'init' script inside the initrd image calls a version of 'mount' that simply doesn't support NFS. I'm debating 1) Punting on RHEL-4 (there are external reasons for using it) 2) Figuring out why initrd is needed in the first place. It seems to be related to UDEV but I can't for the life of me figure out why. Examining the initrd image itself isn't enlightening, there's no modules in it. It seems to do nothing more than mount /proc, /sys, start up udev, and then call 'nash's mount (which then fails due to not groking NFS) to set up the eventual pivot-root(switchroot). 3) Creating my own initrd image and init that doesn't use nash. This is looking more and more like the simplest route (as 1 and 2 fail). It's pretty ($#( in-elegant in my mind. I'd only be creating an initrd image because I can't figure out why it's needed, as opposed to creating one because I have to have one. James 1) I can throw this kernel at an old slackware distribution and it boots just fine without initrd. ps: I didn't mean to hijack your thread with my issue ... If you reply back on the IP-Config output issue I'll try and help track down your problem. |
All times are GMT -5. The time now is 09:26 AM. |