Description of problem: After configuring nfs server on the machine with new kernel, client machine couldn't mount the nfs fs exported from the server. Version-Release number of selected component (if applicable): I tested 2.6.18-1.2768 and 2798. Both failed on IA64. I didn't try it on other platform, but it looks like the problem is arch-independent. How reproducible: Always on ia64 machine. Steps to Reproduce: 1. Install the latest kernel/distribution; 2. On server machine: start nfs and exportfs /mnt/tmp; 3. On client, try to mount the nfs. Failed; 4. I tried kernel 2.6.18-rc7. It works well. Actual results: Expected results: Additional info:
whats in the log files from the server ? anything ? This report is a little sparse on details.
*** Bug 211817 has been marked as a duplicate of this bug. ***
Below is the log on client machine. [root@tigerF mnt]# mount tigerG:/mnt/tmp2 nfs2 mount: mount to NFS server 'tigerG' failed: System Error: No route to host.
This appears to be a networking or routing issue... does 'ping tigerG' work? Meaning are the ICMP packages able to reach the tigerG server?
I could use scp to copy files from tigerG (NFS server) to the client. Ping and ssh are also ok. traceroute showed they are in the same subnetwork as their IP configuration. I try telnet and got the same failure messages. If I just use kernel 2.6.18-rc7 on NFS server and keep other configurations, it does work.
So both NFS mounts and telnets are failing with "No route to host", but scp and pings work find... Thats a bit bizarre... and because the -rc7 kernel works, your pretty sure is not firewall issue somewhere along the way.... beause that's what is seems like... but it does not make any sense that changing kernels would make the networking problem go away...