Problem about NFS mount

Additional info:

When I succeeded with SEED evm the server was able to receive mount request, the /var/log showed:

Jun 28 20:44:31 Fandw kernel: [ 1111.557061] tg3 0000:02:00.0: eth0: Link is down
Jun 28 20:44:32 Fandw kernel: [ 1112.560949] tg3 0000:02:00.0: eth0: Link is up at 100 Mbps, full duplex
Jun 28 20:44:32 Fandw kernel: [ 1112.560955] tg3 0000:02:00.0: eth0: Flow control is off for TX and off for RX
Jun 28 20:44:35 Fandw rpc.mountd[2256]: authenticated mount request from 192.168.1.100:704 for /opt/montavista/pro/devkit/arm/v5t_le/target (/opt/montavista/pro/devkit/arm/v5t_le/target)

However today, there was no request(I tried many times while ):

Oct 17 18:27:09 Fandw kernel: [28804.397065] tg3 0000:02:00.0: eth0: Link is down
Oct 17 18:27:10 Fandw kernel: [28805.400933] tg3 0000:02:00.0: eth0: Link is up at 100 Mbps, full duplex
Oct 17 18:27:10 Fandw kernel: [28805.400940] tg3 0000:02:00.0: eth0: Flow control is off for TX and off for RX

Hi David,

You could try a couple of things:

1.  Is the ethernet port on your board working (ie. can you ping to/from the board) ?

2.  I think that error-5 is a portmap error.  Is your board setup in the nfs server config files (ie. /etc/exports, /etc/hosts/allow) ?

3.  Do you have both NFS clients v4 and v5 turned on in your kernel config ?

BR

-Kevin

Correction:

3.  Do you have both NFS clients v3 and v4 turned on in your kernel config (not v4 and v5) ?

Also, I'm not sure if it would matter or not, but Denx recommends the following format for the bootargs:

setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off

Thanks Kevin,your answer helps.

It is strange that when I ping PC from board it succeeds but when I ping board from PC it fails.

(board: 192.168.1.100,  PC: 192,168.1.99)

The board shows: 

U-Boot > ping 192.168.1.99
host 192.168.1.99 is alive

When ping from PC :

ping 192.168.1.100

Destination Host Unreachable.

Why the link between PC and board through ethernet is kind of unidirectional？Does it mean there is anything wrong with my ethernet chip? 

To the second and third point, my NFS related configuration is:

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y

Is there anyting wrong with it?

David,

Ping from PC to board will fail as there is no ICMP echo server running in u-boot to respond to your ping request. 

David,

Also, could you try mounting the NFS directory from another PC and see whether mount works fine? Have you made sure that nfs path is exported properly and restarted the nfs server?

Thanks Renjith,

1,check of nfs path:

Uboot: printenv: nfsroot=192.168.1.99:/opt/montavista/pro/devkit/arm/v5t_le/target

PC /etc/exports:  /opt/montavista/pro/devkit/arm/v5t_le/target  *(rw, sync, no_root_squash)

So the path is correct.

2, Should I disable the SELinux and close firewall?

David,

You might want to also turn on NFS v4 client, by changing this:

# CONFIG_NFS_V4 is not set

To this:

CONFIG_NFS_V4=y

But you should do it thru the kernel make menuconfig to make sure you pick up any further dependencies.

Also, as Renjith mentioned above, you might want to check to make sure that the path is exported correctly from your linux box.  Your /etc/exports file should have an entry that looks something like this:

/opt/montavista/pro/devkit/arm/v5t_le/target    192.168.1.100(rw,no_root_squash,async,no_subtree_check)

HTH,

-Kevin

Thanks Kevin, but I have to say after enabling NFS_v4 the error still exits.

I've tried to close or open the firewall, permit or disable SELinux there were still no changes.

Best regards!

Is there a portmap entry in your /etc/hosts.allow file ?

Also, as Renjith mentioned - can you mount this directory from another pc ?

Some more things to try. Here's what I did to restart the NFS server after changes to the various config files:

su
service nfs stop
service rpcbind stop
service rpcbind start
service nfs start
server iptables stop

The last command disables the firewall. I found NFS works with SELinux enabled. The firewall does block NFS unless it is properly configured to let it pass. Never quite got the permission just right. I usually just disable it in the development environment. Probably not a good idea in a production environment.

Use this command to see what bits of NFS are running:

rpcinfo -p

You should see enties like this:

100000 portmapper
100003 nfs
100005 mountd
100021 nlogmgr

Your NFS directory needed to be owned by root.

Hi, Norman

I've tried what you said,while I had to say the situation didn't change:

[root@Fandw ~]# service nfs stop
Shutting down NFS mountd: [FAILED]
Shutting down NFS daemon: [FAILED]
Shutting down NFS quotas: [FAILED]
Shutting down NFS services: [FAILED]
[root@Fandw ~]# service rpcbind stop
Stopping rpcbind: [ OK ]
[root@Fandw ~]# service rpcbind start
Starting rpcbind: [ OK ]
[root@Fandw ~]# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
[root@Fandw ~]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
[root@Fandw ~]# rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100021 1 udp 33722 nlockmgr
100021 3 udp 33722 nlockmgr
100021 4 udp 33722 nlockmgr
100021 1 tcp 50004 nlockmgr
100021 3 tcp 50004 nlockmgr
100021 4 tcp 50004 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
100005 1 udp 33465 mountd
100005 1 tcp 58052 mountd
100005 2 udp 37813 mountd
100005 2 tcp 49297 mountd
100005 3 udp 43908 mountd
100005 3 tcp 55451 mountd

Kevin Moran said:

Is there a portmap entry in your /etc/hosts.allow file ?

Also, as Renjith mentioned - can you mount this directory from another pc ?

This is my /etc/hosts.allow:

#
# hosts.allow This file contains access rules which are used to
# allow or deny connections to network services that
# either use the tcp_wrappers library or that have been
# started through a tcp_wrappers-enabled xinetd.
#
# See 'man 5 hosts_options' and 'man 5 hosts_access'
# for information on rule syntax.
# See 'man tcpd' for information on tcp_wrappers
#

I don't know how to mount my notebook(windows) to the Linux PC and I'm trying.

The "rpcinfo -p" looks good. I vaguely remember Linux NFS V3 looks for 100003 nfs and 100005 mountd.

Next up is the hosts files that Kevin mentioned. I have it my notes that I allowed the specific IP is my /etc/hosts.allow file. Something like this:

/etc/hosts.allow
portmap: 192.168.1.100
lockd: 192.168.1.100
rquotad: 192.168.1.100
mountd: 192.168.1.100
statd: 192.168.1.100

In hindsight, I guess i could have used something like "ALL: ALL" for a totally open system. Not quite sure which daemon uses host.allow and hosts.deny. I thought those files did not matter if iptables was shut down. Apparently not.

Are you using Fedora on a virtual machine? It's been noted on this forum that NFS might not work with all virtual machines.

Norman Wong said:

The "rpcinfo -p" looks good. I vaguely remember Linux NFS V3 looks for 100003 nfs and 100005 mountd.

Next up is the hosts files that Kevin mentioned. I have it my notes that I allowed the specific IP is my /etc/hosts.allow file. Something like this:

/etc/hosts.allow
portmap: 192.168.1.100
lockd: 192.168.1.100
rquotad: 192.168.1.100
mountd: 192.168.1.100
statd: 192.168.1.100

In hindsight, I guess i could have used something like "ALL: ALL" for a totally open system. Not quite sure which daemon uses host.allow and hosts.deny. I thought those files did not matter if iptables was shut down. Apparently not.

Are you using Fedora on a virtual machine? It's been noted on this forum that NFS might not work with all virtual machines.

Thanks, Norman

1, I changed the /etc/hosts.allow as follows( though I think it is unnecessary)

portmap: 192.168.1.
lockd: 192.168.1.
rquotad: 192.168.1.
mountd: 192.168.1.
statd: 192.168.1.

There is no change.

2, The Fedora 14 is not on a vertual machine

Regards.

That's all I can think of. Everything is much the same as my Fedora 12 NFS setup.

Looking more closely at your original posts. Your SEED EVM worked with NFS but your custom board does not? Implies that the NFS server was fine in the first place. Does the SEED EVM and custom board use the same IP? If they are different,  try the SEED EVM with the custom board IP. If they are the same, be sure that they are not both on at the same time.