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:ff 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

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.