Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Fedora/1.7.10-1.5.1 Description of problem: I get messages like this in the message log: Aug 8 13:51:28 mayday rpc.idmapd: nfsdreopen: Opening '' failed: errno 2 (No such file or directory) When trying to export like this: /home/adrian/linux-sh/initrd 192.168.61.55(rw,sync,nohide,no_root_squash,insecure,no_subtree_check,insecure_locks) The directory does exist: 1817267 drwxrwxr-x 8 adrian adrian 4096 Aug 4 23:09 initrd When I attempt to mount, as nfsroot, this directory the client (a Sega Dreamcast with a 2.6.12.3 kernel) reports an server error -13 and then a kernel panic as there is no root filesystem. Version-Release number of selected component (if applicable): 2.6.12-1.1398_FC4smp kernel How reproducible: Always Steps to Reproduce: 1. edit /etc/exports or use system-config-nfs 2. 3. Actual Results: Error message as described, susbsequently mount fails Expected Results: Filsystem should be exported, Additional info: Have seen a very similar error reported for FC4 but no record of this with FC3
What appears in /var/log/messages when I attempt to mount this: Aug 8 14:06:55 mayday kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Aug 8 14:06:57 mayday dhcpd: DHCPDISCOVER from 00:d0:f1:03:12:b9 via eth0 Aug 8 14:06:58 mayday dhcpd: DHCPOFFER on 192.168.61.55 to 00:d0:f1:03:12:b9 via eth0 Aug 8 14:06:58 mayday dhcpd: Wrote 1 leases to leases file. Aug 8 14:06:58 mayday dhcpd: DHCPREQUEST for 192.168.61.55 (192.168.61.50) from 00:d0:f1:03:12:b9 via eth0 Aug 8 14:06:58 mayday dhcpd: DHCPACK on 192.168.61.55 to 00:d0:f1:03:12:b9 via eth0 Aug 8 14:06:58 mayday rpc.mountd: bad path in mount request from 192.168.61.55: "192.168.61.50:/home/adrian/linux-sh/initrd"
sorry, above should say: have seen a similar bug reported for FC3, but NOT FC4
The "rpc.idmapd: nfsdreopen: Opening..." is a known problem that is fixed in a updated release of nfs-utils. Please upgrade your nfs-utils and try again...
Currently using nfs-utils-1.0.7-10. Not aware that yum has ever offered me anything else...but will seek to update now.
hmm it appears the fix went in around 1.0.7-8 (see bz158188)...
Downgraded to 1.0.7-8 and still had the problem... /var/lib/nfs/xtab remains empty [root@mayday ~]# exportfs -av exporting 192.168.61.55/255.255.255.0:/home/adrian/linux-sh/initrd [root@mayday ~]# cat /var/lib/nfs/xtab [root@mayday ~]# Upgraded again and the problem remains...
From the client side it looks like this... IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) NET: Registered protocol family 1 NET: Registered protocol family 17 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Sending DHCP requests ., OK IP-Config: Got DHCP answer from 192.168.61.50, my address is 192.168.61.55 IP-Config: Complete: device=eth0, addr=192.168.61.55, mask=255.255.255.0, gw=192.168.61.50, host=192.168.61.55, domain=, nis-domain=(none), bootserver=192.168.61.50, rootserver=192.168.61.50, rootpath= Looking up port of RPC 100003/3 on 192.168.61.50 Looking up port of RPC 100005/3 on 192.168.61.50 Root-NFS: Server returned error -13 while mounting 192.168.61.50:/home/adrian/linux-sh/initrd VFS: Unable to mount root fs via NFS, trying floppy. Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
If I do not specify an NFS root in the client kernel command line but instead rely on the client attempting to mount /tftpboot/X.X.X.X (and assuming that is exported), it will mount the root
I have got the same error message, and 'exportfs' shows nothing, but mounting from remote hosts works. Kernel 2.6.12-1.1456_FC4smp x86_64 nfs-utils-1.0.7-11
This is fixed in later version nfs-utils-1.0.7-19
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.