WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [solved] mount.nfs problem  (Read 5561 times)

Offline danifty

  • Newbie
  • *
  • Posts: 4
[solved] mount.nfs problem
« on: November 14, 2009, 02:16:32 PM »
Hello from France! cocoricco  :)

I'm currently working on PXE boot of TinyCore 2.5 "diskless".
bzImage et initrd loads both fine
nfs-utils/filesystems/portmap/tcp_wrapper  tcz's are loaded fine via ftfp.
I finally boot a full working TinyCore system.

As a root filesystem for my TinyCore distro, I want to mount a NFS share (which pre-exists), but there is a problem : a mount.nfs "internal error"... I'm currently trying to mount it manually before including it in boot options.

NFS Server: nfsutils v1.1.4-8 (Fedora 10 - firewall rules OK)
NFS Client: nfs-utils v1.1.2 (TinyCore 2.5)

3 days of web searches and many different tries did not solve the problem...

NFS client says:
Code: [Select]
mount.nfs timeout set for ....
mount.nfs: text-based options: 'addr=192.168.1.10'
mount.nfs: internal error

NFS server says nothing... Or I don't know where to look for...

I can mount the same NFS shares in a SSH console directly on the server.

Does anyone knows what meens this "internal error" from mount.nfs ?
Is there any different way I can "mount"/"test" this NFS share from my TinyCore diskless laptop ?

Many thanks in advance.


Added Sun. Nov. 15:
NFS server seems to receive and understand the request
Code: [Select]
[root@server]# tcpdump -vv|grep 192.168.1.50
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:58:50.890290 IP (tos 0x0, ttl 64, id 56503, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.50.57333 > dc01.sunrpc: S, cksum 0x0162 (correct), 2904531200:2904531200(0) win 5840 <mss 1460,sackOK,timestamp 425399 0,nop,wscale 6>
17:58:50.890375 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) dc01.sunrpc > 192.168.1.50.57333: S, cksum 0x043f (correct), 3224836805:3224836805(0) ack 2904531201 win 5792 <mss 1460,sackOK,timestamp 327093958 425399,nop,wscale 6>
17:58:50.890474 IP (tos 0x0, ttl 64, id 56504, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.57333 > dc01.sunrpc: ., cksum 0x494e (correct), 1:1(0) ack 1 win 92 <nop,nop,timestamp 425399 327093958>
17:58:50.890520 IP (tos 0x0, ttl 64, id 56505, offset 0, flags [DF], proto TCP (6), length 140) 192.168.1.50.57333 > dc01.sunrpc: P 1:89(88) ack 1 win 92 <nop,nop,timestamp 425399 327093958>
17:58:50.890538 IP (tos 0x0, ttl 64, id 5121, offset 0, flags [DF], proto TCP (6), length 52) dc01.sunrpc > 192.168.1.50.57333: ., cksum 0x48f6 (correct), 1:1(0) ack 89 win 91 <nop,nop,timestamp 327093959 425399>
17:58:50.890866 IP (tos 0x0, ttl 64, id 5122, offset 0, flags [DF], proto TCP (6), length 84) dc01.sunrpc > 192.168.1.50.57333: P 1:33(32) ack 89 win 91 <nop,nop,timestamp 327093959 425399>
17:58:50.890937 IP (tos 0x0, ttl 64, id 56506, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.57333 > dc01.sunrpc: ., cksum 0x48d5 (correct), 89:89(0) ack 33 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.890967 IP (tos 0x0, ttl 64, id 56507, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.57333 > dc01.sunrpc: F, cksum 0x48d4 (correct), 89:89(0) ack 33 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.890996 IP (tos 0x0, ttl 64, id 33869, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.50.797 > dc01.44238: S, cksum 0xd8b4 (correct), 2907437562:2907437562(0) win 5840 <mss 1460,sackOK,timestamp 425399 0,nop,wscale 6>
17:58:50.891023 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) dc01.44238 > 192.168.1.50.797: S, cksum 0xb5a8 (correct), 3236249599:3236249599(0) ack 2907437563 win 5792 <mss 1460,sackOK,timestamp 327093959 425399,nop,wscale 6>
17:58:50.891052 IP (tos 0x0, ttl 64, id 5123, offset 0, flags [DF], proto TCP (6), length 52) dc01.sunrpc > 192.168.1.50.57333: F, cksum 0x48d4 (correct), 33:33(0) ack 90 win 91 <nop,nop,timestamp 327093959 425399>
17:58:50.891093 IP (tos 0x0, ttl 64, id 33870, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.797 > dc01.44238: ., cksum 0xfab7 (correct), 1:1(0) ack 1 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.891113 IP (tos 0x0, ttl 64, id 56508, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.57333 > dc01.sunrpc: ., cksum 0x48d3 (correct), 90:90(0) ack 34 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.891149 IP (tos 0x0, ttl 64, id 33871, offset 0, flags [DF], proto TCP (6), length 96) 192.168.1.50.797 > dc01.44238: P 1:45(44) ack 1 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.891162 IP (tos 0x0, ttl 64, id 20167, offset 0, flags [DF], proto TCP (6), length 52) dc01.44238 > 192.168.1.50.797: ., cksum 0xfa8c (correct), 1:1(0) ack 45 win 91 <nop,nop,timestamp 327093959 425399>
17:58:50.891240 IP (tos 0x0, ttl 64, id 20168, offset 0, flags [DF], proto TCP (6), length 76) dc01.44238 > 192.168.1.50.797: P, cksum 0x83cb (incorrect (-> 0x4f54), 1:25(24) ack 45 win 91 <nop,nop,timestamp 327093959 425399>
17:58:50.891312 IP (tos 0x0, ttl 64, id 33872, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.797 > dc01.44238: ., cksum 0xfa73 (correct), 45:45(0) ack 25 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.891325 IP (tos 0x0, ttl 64, id 33873, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.797 > dc01.44238: F, cksum 0xfa72 (correct), 45:45(0) ack 25 win 92 <nop,nop,timestamp 425399 327093959>
17:58:50.891480 IP (tos 0x0, ttl 64, id 20169, offset 0, flags [DF], proto TCP (6), length 52) dc01.44238 > 192.168.1.50.797: F, cksum 0xfa71 (correct), 25:25(0) ack 46 win 91 <nop,nop,timestamp 327093960 425399>
17:58:50.891547 IP (tos 0x0, ttl 64, id 33874, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.50.797 > dc01.44238: ., cksum 0xfa70 (correct), 46:46(0) ack 26 win 92 <nop,nop,timestamp 425399 327093960>
... No tcpdump command on TinyCore client...

TinyCore client laptop RPC debug informations:
Code: [Select]
RPC:    37 __rpc_execute flags=0x280
RPC:    37 rpcb_getport_async(webserver, 100005, 3, 6)
RPC:    37 rpcb_getport_async: trying rpcbind version 2
RPC:       creating rpcbind client for webserver (xprt ec4b6c00)
RPC:    38 __rpc_execute flags=0x281
RPC:    38 call_start rpcbind2 proc GETPORT (async)
RPC:       rpc_release_client(ec4df200)
RPC:    38 __rpc_wake_up_task (now 799674)
RPC:       __rpc_wake_up_task done
RPC:    38 __rpc_execute flags=0x281
RPC:    38 rpc_xdr_encode (status 0)
RPC:    38 using AUTH_UNIX cred ec806e40 to wrap rpc data
RPC:       encoding rpcb request (100005, 3, 6, 0)
RPC:    38 __rpc_wake_up_task (now 799675)
RPC:       __rpc_wake_up_task done
RPC:    38 __rpc_execute flags=0x281
RPC:    38 using AUTH_UNIX cred ec806e40 to unwrap rpc data
RPC:       rpcb getport result: 44238
RPC:    38 rpcb_getport_done(status 0, port 44238)
RPC:       rpc_release_client(ec4df200)
RPC:       destroying rpcbind client for webserver
RPC:    37 __rpc_wake_up_task (now 799675)
RPC:       __rpc_wake_up_task done
RPC:    37 __rpc_wake_up_task (now 799675)
RPC:       __rpc_wake_up_task done
RPC:    37 rpc_xdr_encode (status 0)
RPC:    37 using AUTH_NULL cred c04504b0 to wrap rpc data
RPC:    37 __rpc_wake_up_task (now 799675)
RPC:       __rpc_wake_up_task done
RPC:    37 rpc_verify_header: unknown auth error: 7
RPC:    37 rpc_verify_header: call rejected 7
RPC:    37 rpc_verify_header: call failed with error -5
RPC:       rpc_release_client(ec4df400)
RPC:       rpc_release_client(ec4df400)
...no "dmesg" RPC debugging informations on Fedora 10 NFS server while trying to mount...


For information, I tried booting from CDROM, and installing needed extensions, and the result is the same (mount.nfs: internal error).

Does someone else tried to mount nfs share using TinyCore 2.5 ? - If so, have you experienced problems mounting such a filesystem type ?

Thanks.
« Last Edit: November 17, 2009, 01:34:25 PM by danifty »

Offline danifty

  • Newbie
  • *
  • Posts: 4
Re: mount.nfs problem
« Reply #1 on: November 16, 2009, 01:41:30 PM »
Hi,

After many efforts, I successfully mounted the NFS share.
Problems was between hosts.{allow;deny} on NFS server and my TinyCore laptop which does not auto-start NFS needed deamons...

Starting daemons in separate consoles with:
Code: [Select]
#sudo portmap -dvf
# sudo rpc.statd -F -d -p 40020

gaves me the ability to successfully mount NFS share.

By now, NFS access is partially resolved (partially... because needed daemons are not started automatically at system startup).

My last question is : how can I integrate this changes in modified (or a fresh new) initrd for TinyCore ?
Any tuto/help page welcomed.. This will be my first initrd customization.

Thanks

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: mount.nfs problem
« Reply #2 on: November 16, 2009, 01:44:20 PM »
danifty-

Did you try "/usr/local/etc/init.d/nfs-client start" to start the nfs client utilities?

That command could also be put in /opt/bootlocal.sh for automatic executing on boot.

EDIT: Oh, I see the root filesystem part, so bootlocal.sh may not help.

« Last Edit: November 16, 2009, 01:50:07 PM by Jason W »

Offline danifty

  • Newbie
  • *
  • Posts: 4
Re: mount.nfs problem
« Reply #3 on: November 16, 2009, 02:29:50 PM »
Youpi!

Many thanks Jason for the path of the 'start' utilities! I looked for them for a long time... without finding.
This is why I started daemons manually. Many thanks!

For 'initrd' changes... Do you know a good tutorial on how extracting and "re-packaging" initrd for TinyCore?
I found some which deals with "linux" initrd's as general matter, but many of them are obsurs for me.

Thanks

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: mount.nfs problem
« Reply #4 on: November 16, 2009, 04:31:17 PM »
The wiki has a section on remastering that explains extracting/repacking tinycore.gz in detail.

Offline danifty

  • Newbie
  • *
  • Posts: 4
Re: mount.nfs problem
« Reply #5 on: November 17, 2009, 01:16:40 PM »
Thanks Jason.
I will read it carrefully, and I'll probably (surely?) come back later with much interesting questions.. :-)

Thanks again.