[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem: NFSROOT with netboot and 2.2.x



In article <[🔎] 14083.31883.602317.599114@bastard.informatik.unibw-muenchen.de> you write:
>whenever i try to boot a 2.2.x kernel with netboot
>everything goes all-right until it starts to mount nfs. 

2.2.1 and 2.2.3 both work OK for me...

>At this point I get on my client:
>
>Looking up port of RPC 100003/2 on 192.168.1.1
>portmap: server 192.168.1.1 not responding timed 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
>portmap: server 192.168.1.1 not responding timed out
>Root-NFS: Unable to get mountd port number from server, using default
>mount: server 192.168.1.1 not responding, timed out
>ROOT-NFS: Server returned error -5 while mounting xxxxx
>VFS: Unable to mount root fs via NFS ....

I have never seen any errors prefixed with "Root-NFS", so I don't
know for certain what the problem is. I presume BOOTP and TFTP
were previously used to get this far, meaning it is not a general
network failure. I also assume that all IP addresses that the
kernel gets and displays are correct and hasn't been currupted.

Suggestions:
1. Try mounting the NFS partition on the server (ie localhost). Does
   that work?
2. Can you manually mount a NFS partition on another computer? 
3. Is anything logged at the server?

>BUT, from time to time it works (maybe once in 10 times)
>Very strange .... 
>No problems at all with 2.0.x kernels. 

Do you mean the client or the server needs 2.0.x in order to run?
(I think you mean the client, just checking though).

I haven't tried 2.2.5, but I would hope that the problem is elsewhere
;-) I would be interested to know if you have tried 2.2.1 or 2.2.3.

>On my Debian system I use:
>
>Client:
>- Debian slink with Kernel 2.2.5
>- netboot 0.8.1
>
>Server:
>- Debian slink with Kernel 2.2.5
>- nfsd (2.2beta37) or knfsd (1.2) , which makes no difference ....

I sounds like the server is probably OK, in which case, none of this
will help. In this case, the best I can suggest is to trace the packets
with tcpdump, and see if you notice anything unusual (eg packets only
being sent in one direction). In particular check that the client is
sending the request to the server, the server is replying back to the
client, and everything else looks OK (eg IP address of source and
destination).


Reply to: