NFS "no such device"... is NFS even in the kernel?

Has anyone got an ideas about this problem, please?

I've configured NFS on my dev machine (Fedora 16) and I can see the
exported filesystems from another PC.  However, when I try to mount one to
the mini6410, I get the following:

root@FriendlyARM /etc]# mount -t nfs4 ermintrude:/home/jeff/ARM /mnt
mount: mounting ermintrude:/home/jeff/ARM on /mnt failed: No such device

Googling that mount error, and checking lsmod, it looks as if the
FriendlyARM kernel doesn't have NFS enabled.  Could that be the case?  The
manual implies that it's there by default.

Thanks!

Take a look at run-time into the file "/proc/filesystems". When your kernel
supports NFS, it should contain something like "nodev   nfs".

Ah, my bad!

Seems it's not -t nfs4, it's just -t nfs.

So, now we get this:
[root@FriendlyARM /]# mount -t nfs 192.168.1.202:/home/jeff/ARM /mnt
mount: mounting 192.168.1.202:/home/jeff/ARM on /mnt failed: Connection
refused

Thought that might be SELinux raising its ugly head, but moving it to
Permissive mode gives no change.  All the ports listed by "rpcinfo -p" are
open in the firewall, and even disabling the firewall temporarily has no
effect.  Odd.

Juergen, /proc/filesystems on the mini6410 is empty... problem?

Is the whole 'proc/' empty? If yes, you forget to mount the procfs. If only
the '/proc/filesystems' is empty, hmmm, no idea what wrong in this case.

Mounting an NFS share can fail due to the 'mount' commend itself and its
capabilities. The Busybox's 'mount' can handle NFS filesystem when enabled
in its configuration. The regular 'mount' command needs the NFS helpers to
be able to mount an NFS share.

Hmm indeed.  proc looks ok.  Might be something about how the latest Fedora
builds use it - quite a few things aren't "standard" in the old way any
longer.

The 6410 doesn't seem to get it right with any remote filesystems.  CIFS
(Samba) mounts to my Windows server come back with "no such device" even
with anonymous access enabled and NFS to the Windows server gives
"connection refused"  or "bad file descriptor" depending on its mood!

When you say "when enabled in its configuration", where is that config on
the ARM board?

And this is odder still... I just increased the logging level on the
Windows server's NFS service.

ARM:
> busybox mount 192.168.1.2:/TransferTemp /pc
mount: mounting 192.168.1.2:/TransferTemp on /pc failed: Connection refused

[same answer for just "mount" without invoking busybox]

Windows event log:
Mount operation succeeded. 

Address:192.168.1.222  (that's the ARM board)
Share:D:\Public\TransferTemp

Now that's strange.  ARM thinks it didn't work, Windows says it did.

Ah!

I missed an option which appears to be vital to the mount.  Thought it was
the default, but possibly not in the ARM linux distro.

It's mount -t nfs -o nolock etc...  The "nolock" is the bit that made it
work.  Now I can mount nfs at least.  CIFS doesn't matter, so will ignore
that!

if address wrong then what will be the output of mount??????