Setting up NFS client

[Chris Plasun]

Hi,

With the help of Steve and Denys I was able to get network connectivity
on my Freescale MPC8313 board running Linux version 2.6.20.

I would like to get the MPC8313 board running as a NFS client connected
to a SUSE installation in VirtualBox running on a winbox.

The PC, virtual SUSE installation and the board are all pinging each
other happily.

I set up NFS server in SUSE and apparently its running. I've set up the
exports file in /etc and running chkconfig nfs returns that NFS is on.

On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
/nfstest" but it eventually returns with the following error:

mount: RPC: Timed out
mount: nfsmount failed: Bad file descriptor
mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
Bad file descriptor

What steps must I take to get this working?

Thank you,
Chris Plasun

[Ralf Friedl]

Chris Plasun wrote:
> I would like to get the MPC8313 board running as a NFS client
> connected to a SUSE installation in VirtualBox running on a winbox.
>
> The PC, virtual SUSE installation and the board are all pinging each
> other happily.
>
> I set up NFS server in SUSE and apparently its running. I've set up
> the exports file in /etc and running chkconfig nfs returns that NFS is
> on.
What does "apparently its running" mean in this case?
First, chkconfig indicates that a service is to be run on startup, not
whether it is currently running.
Second, the service name you are looking for is not "nfs" (the client)
but "nfsserver" (the server).
To check for the NFS-Server use this command:
$ rcnfsserver status
To start the NFS-Server use this command:
$ rcnfsserver start

Also, you must make sure that portmap is running before starting the NFS
server (chkconfig -a portmap; rcportmap start).

A simple test would be whether a NFS-mount on the server to the server
itself works.

Regards
Ralf Friedl

[Paul Smith]

On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
> On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
> /nfstest" but it eventually returns with the following error:
>
> mount: RPC: Timed out
> mount: nfsmount failed: Bad file descriptor
> mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
> Bad file descriptor

In addition to Ralf's good points about checking the config in the NFS
server, you should also make sure the client is properly configured.
You need to enable at least these things in the kernel (I'm assuming
you're building your own kernel for the Freescale?):

CONFIG_NFS_COMMON=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_LOCKD=y
CONFIG_SUNRPC=y

Also, if you're seeing a delay on the client you probably don't have the
portmapper running on the client. If you don't want to add it there
that's OK, but then you have to disable lock management; add the "-o
nolock" option to your mount command on the client.

I don't know what the "bad file descriptor" means. You did
create /nfstest (mkdir /nfstest) first right? If none of this seems to
help then check the /var/log/messages file on the server and see if
there's anything suspicious there.

[Michael Abbott]

On Sat, 18 Apr 2009, Paul Smith wrote:
> On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
> > On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
> > /nfstest" but it eventually returns with the following error:
> >
> > mount: RPC: Timed out
> > mount: nfsmount failed: Bad file descriptor
> > mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
> > Bad file descriptor
> Also, if you're seeing a delay on the client you probably don't have the
> portmapper running on the client. If you don't want to add it there
> that's OK, but then you have to disable lock management; add the "-o
> nolock" option to your mount command on the client.

This issue, the portmapper, threw me for a long time. Is it still not
built into busybox? I have to build this separately (and ended up having
to make a couple of tiny patches for out of tree building to work). I
downloaded portmap-6.0 from http://neil.brown.name/portmap/ .

Presumably it would be worth pulling portmap.c into busybox? I've often
wondered why it's not there, don't know how much work would be needed to
do that.


The patches I needed are below, and I use this command to cross compile it
out of tree:

PORTMAP_PROGRAMS = portmap pmap_dump pmap_set
build:
make -C $(O) -f $(srcdir)/Makefile $(PORTMAP_PROGRAMS) \
srcdir=$(srcdir) VPATH=$(srcdir) \
CC=$(COMPILER_PREFIX)-gcc CFLAGS='$(CFLAGS)' NO_TCP_WRAPPER=y


diff -ur portmap_6.0/pmap_check.c portmap_6.0.patched/pmap_check.c
--- portmap_6.0/pmap_check.c 2007-05-11 04:02:10.000000000 +0100
+++ portmap_6.0.patched/pmap_check.c 2008-10-26 17:47:05.000000000
+0000
@@ -44,7 +44,9 @@
#include <netinet/in.h>
#include <rpc/rpcent.h>
#endif
+#ifdef HOSTS_ACCESS
#include <tcpd.h>
+#endif
#include <arpa/inet.h>
#include <grp.h>

--- portmap_6.0/Makefile 2007-05-11 04:02:10.000000000 +0100
+++ portmap/Makefile 2008-10-30 15:56:24.000000000 +0000
@@ -148,7 +148,7 @@
core portmap.man

-include .depend
-.depend: *.c
- $(CC) -MM $(CFLAGS) *.c > .depend
+.depend: $(srcdir)/*.c
+ $(CC) -MM $(CFLAGS) $(srcdir)/*.c > .depend

.PHONY: all clean install

[Paul Smith]

On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
> On Sat, 18 Apr 2009, Paul Smith wrote:
> > On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
> > > On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
> > > /nfstest" but it eventually returns with the following error:
> > >
> > > mount: RPC: Timed out
> > > mount: nfsmount failed: Bad file descriptor
> > > mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
> > > Bad file descriptor
> > Also, if you're seeing a delay on the client you probably don't have the
> > portmapper running on the client. If you don't want to add it there
> > that's OK, but then you have to disable lock management; add the "-o
> > nolock" option to your mount command on the client.
>
> This issue, the portmapper, threw me for a long time. Is it still not
> built into busybox?

I haven't looked. I just use -o nolock on all my mounts so I don't need
RPC. For my purposes I don't need to worry about this.

> I have to build this separately (and ended up having
> to make a couple of tiny patches for out of tree building to work). I
> downloaded portmap-6.0 from http://neil.brown.name/portmap/ .

Nice; have you send this along upstream? In my experience people are
usually happy to get things like this.

[Mike Frysinger]

On Saturday 18 April 2009 14:14:45 Paul Smith wrote:
> On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
> > I have to build this separately (and ended up having
> > to make a couple of tiny patches for out of tree building to work). I
> > downloaded portmap-6.0 from http://neil.brown.name/portmap/ .
>
> Nice; have you send this along upstream? In my experience people are
> usually happy to get things like this.

i already sent this fix upstream long ago (May 17 2007 to be exact)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090418/31e5bc63/attachment.pgp>

[Michael Abbott]

On Sat, 18 Apr 2009, Mike Frysinger wrote:
> On Saturday 18 April 2009 14:14:45 Paul Smith wrote:
> > On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
> > > I have to build this separately (and ended up having
> > > to make a couple of tiny patches for out of tree building to work). I
> > > downloaded portmap-6.0 from http://neil.brown.name/portmap/ .
> > Nice; have you send this along upstream? In my experience people are
> > usually happy to get things like this.
> i already sent this fix upstream long ago (May 17 2007 to be exact)

Well, the patch to pmap_check.c went into git at the time (date seems to
be May 13, as it happens),
http://neil.brown.name/git/portmap ,
but not into a new release -- looks like your patch was straight after the
6.0 release, and there hasn't been a 6.1.

However the Makefile change isn't there, but it is only to help out of
tree builds, which frankly don't get much attention on most projects (the
amount of time I've spent on enabling this on various components is
ridiculous). To be honest, no I haven't tried pushing upstream -- and the
associated build command may suggest why I didn't bother!


P.S. Anybody here know how to build out of tree kernel modules so that
the built files are in their own "out of tree" directory? Two quite
different uses of the term "out of tree" here, and necessarily four
separate directories: 1. kernel sources; 2. kernel build directory; 3.
module sources; 4. module build directory. Unfortunately I haven't found
any way to avoid (3)==(4).

[Gilles Espinasse]

----- Original Message -----
From: "Michael Abbott" <michael at araneidae.co.uk>
To: "Mike Frysinger" <vapier at gentoo.org>
Cc: <busybox at busybox.net>
Sent: Sunday, April 19, 2009 11:08 AM
Subject: Re: Setting up NFS client


>
> P.S. Anybody here know how to build out of tree kernel modules so that
> the built files are in their own "out of tree" directory? Two quite
> different uses of the term "out of tree" here, and necessarily four
> separate directories: 1. kernel sources; 2. kernel build directory; 3.
> module sources; 4. module build directory. Unfortunately I haven't found
> any way to avoid (3)==(4).

It depend of the module Makefile you build against
You usually need to indicate where the kernel sources, especially when the
kernel version running is not the same as the kernel version you build. If
it's the same version, usually Makefile find it at
/usr/src/linux-$(uname -r)

For openswan for example, when running kernel is not the same as kernel
build, you have to, inside openswan package directory run
make KERNELSRC=/usr/src/linux-$(KVER) module

Usually out of tree modules are installed in /lib/modules/<KVER>/extra

Gilles

[Michael Abbott]

On Sun, 19 Apr 2009, Gilles Espinasse wrote:
> From: "Michael Abbott" <michael at araneidae.co.uk>
> > P.S. Anybody here know how to build out of tree kernel modules so that
> > the built files are in their own "out of tree" directory? Two quite
> > different uses of the term "out of tree" here, and necessarily four
> > separate directories: 1. kernel sources; 2. kernel build directory; 3.
> > module sources; 4. module build directory. Unfortunately I haven't found
> > any way to avoid (3)==(4).
>
> It depend of the module Makefile you build against
> You usually need to indicate where the kernel sources, especially when the
> kernel version running is not the same as the kernel version you build. If
> it's the same version, usually Makefile find it at
> /usr/src/linux-$(uname -r)
>
> For openswan for example, when running kernel is not the same as kernel
> build, you have to, inside openswan package directory run
> make KERNELSRC=/usr/src/linux-$(KVER) module
>
> Usually out of tree modules are installed in /lib/modules/<KVER>/extra

Let me be a bit clearer and more explicit. Some symbols (from my
makefile, none of these are exported):

KERNEL_SOURCE_DIR = /path/to/kernel/source/tree
MODULE_SOURCE_DIR = /path/to/module/source/tree

KBUILD_OUTPUT = /path/to/kernel/build
MODULE_OUTPUT = /path/to/module/build

I'm actually cross-compiling, so there are also exports of CROSS_COMPILE
and ARCH which we don't need to see here.


The kernel was built with the command

make -C $(KERNEL_SOURCE_DIR) O=$(KBUILD_OUTPUT) uImage


The problem comes when I try to build the module. In $(MODULE_SOURCE_DIR)
I have a Kbuild with just two lines:

obj-m := my-module.o
my-module-objs := my-module-source.c

Currently I build with

make -C $(KBUILD_OUTPUT) M=$(MODULE_SOURCE_DIR)

and of course my build output appears in $(MODULE_SOURCE_DIR) -- and of
course MODULE_OUTPUT never got communicated to the kernel makefile.
Unfortunately I can't see any way to do that...

I've tried a variety of combinations on this make command, but I'm running
a bit blind here. I can't see any way to specify all four directories to
the make system! I guess the next step is going to have to be to trace
all the way through the kernel build ... ouch.

[Michael D. Setzer II]

Been watching this NFS client thread for a while.
I had tried to add NFS support to my g4l project some time ago, and ran into
lots of issues. Eventually, I was able to use sshfs instead with very little work.
Just added ssh and sshfs plus support files, and am able to do the mount.

I did try to do the NFS on the Fedora 10 machine in my lab, and it worked
on the machine, but when trying to access it from other machines, it failed
until I completely shut off the firewall.



On 19 Apr 2009 at 11:40, Gilles Espinasse wrote:

From: "Gilles Espinasse" <g.esp at free.fr>
To: "Michael Abbott" <michael at araneidae.co.uk>
Subject: Re: Setting up NFS client
Date sent: Sun, 19 Apr 2009 11:40:55 +0200
Copies to: busybox at busybox.net

>
> ----- Original Message -----
> From: "Michael Abbott" <michael at araneidae.co.uk>
> To: "Mike Frysinger" <vapier at gentoo.org>
> Cc: <busybox at busybox.net>
> Sent: Sunday, April 19, 2009 11:08 AM
> Subject: Re: Setting up NFS client
>
>
> >
> > P.S. Anybody here know how to build out of tree kernel modules so that
> > the built files are in their own "out of tree" directory? Two quite
> > different uses of the term "out of tree" here, and necessarily four
> > separate directories: 1. kernel sources; 2. kernel build directory; 3.
> > module sources; 4. module build directory. Unfortunately I haven't found
> > any way to avoid (3)==(4).
>
> It depend of the module Makefile you build against
> You usually need to indicate where the kernel sources, especially when the
> kernel version running is not the same as the kernel version you build. If
> it's the same version, usually Makefile find it at
> /usr/src/linux-$(uname -r)
>
> For openswan for example, when running kernel is not the same as kernel
> build, you have to, inside openswan package directory run
> make KERNELSRC=/usr/src/linux-$(KVER) module
>
> Usually out of tree modules are installed in /lib/modules/<KVER>/extra
>
> Gilles
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox


+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes at kuentos.guam.net
mailto:msetzerii at gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC at HOME CREDITS
SETI 7,671,635.2685 | EINSTEIN 2,465,893.2309 | ROSETTA
873,793.3373

[Denys Vlasenko]

On Sunday 19 April 2009 11:08, Michael Abbott wrote:
> On Sat, 18 Apr 2009, Mike Frysinger wrote:
> > On Saturday 18 April 2009 14:14:45 Paul Smith wrote:
> > > On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
> > > > I have to build this separately (and ended up having
> > > > to make a couple of tiny patches for out of tree building to work). I
> > > > downloaded portmap-6.0 from http://neil.brown.name/portmap/ .
> > > Nice; have you send this along upstream? In my experience people are
> > > usually happy to get things like this.
> > i already sent this fix upstream long ago (May 17 2007 to be exact)
>
> Well, the patch to pmap_check.c went into git at the time (date seems to
> be May 13, as it happens),
> http://neil.brown.name/git/portmap ,
> but not into a new release -- looks like your patch was straight after the
> 6.0 release, and there hasn't been a 6.1.
>
> However the Makefile change isn't there, but it is only to help out of
> tree builds, which frankly don't get much attention on most projects (the
> amount of time I've spent on enabling this on various components is
> ridiculous). To be honest, no I haven't tried pushing upstream -- and the
> associated build command may suggest why I didn't bother!
>
>
> P.S. Anybody here know how to build out of tree kernel modules so that
> the built files are in their own "out of tree" directory? Two quite
> different uses of the term "out of tree" here, and necessarily four
> separate directories: 1. kernel sources; 2. kernel build directory; 3.
> module sources; 4. module build directory. Unfortunately I haven't found
> any way to avoid (3)==(4).

There is a reason why out-of-tree builds are not as well tested as in-tree ones.

Getting them right, and _maintaining_ them right, as everything else,
needs developer's effort (the limiting resource in our trade).
And most projects are small enough that just making a scratch copy
of the source tree and building in-tree does not require much space
or time.

Thus, it makes sense to not waste developer's time making it work
for small projects. Developer can fix a few real bugs instead.

For big projects like kernel, gcc etc it makes more sense.


IIRC out-of-tree kernel build has this "curious" property that every time
someone embeds __FILE__ into a printk message it ends it being:

/home/peter/srcdevel/big/projects/hacking/kernel/linux-x.y.z/kernel/module.c

instead of:

kernel/module.c

This wastes many kilobytes in kernel image.

This alone makes me willing to create a shadow tree full of symlinks
and make an "in-tree" build there.
--
vda

[Mike Frysinger]

On Sunday 19 April 2009 07:07:39 Denys Vlasenko wrote:
> This alone makes me willing to create a shadow tree full of symlinks
> and make an "in-tree" build there.

`man lndir`
lndir - create a shadow directory of symbolic links to another directory tree
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090420/88a0bdac/attachment.pgp>

[Denys Vlasenko]

On Monday 20 April 2009 07:37, Mike Frysinger wrote:
> On Sunday 19 April 2009 07:07:39 Denys Vlasenko wrote:
> > This alone makes me willing to create a shadow tree full of symlinks
> > and make an "in-tree" build there.
>
> `man lndir`
> lndir - create a shadow directory of symbolic links to another directory tree

I use cp -s
--
vda

[Chris Plasun]

> On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
>> On Sat, 18 Apr 2009, Paul Smith wrote:
>>> On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
>>>> On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
>>>> /nfstest" but it eventually returns with the following error:
>>>>
>>>> mount: RPC: Timed out
>>>> mount: nfsmount failed: Bad file descriptor
>>>> mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
>>>> Bad file descriptor
>>> Also, if you're seeing a delay on the client you probably don't have the
>>> portmapper running on the client. If you don't want to add it there
>>> that's OK, but then you have to disable lock management; add the "-o
>>> nolock" option to your mount command on the client.
>> This issue, the portmapper, threw me for a long time. Is it still not
>> built into busybox?
>
> I haven't looked. I just use -o nolock on all my mounts so I don't need
> RPC. For my purposes I don't need to worry about this.
>
>> I have to build this separately (and ended up having
>> to make a couple of tiny patches for out of tree building to work). I
>> downloaded portmap-6.0 from http://neil.brown.name/portmap/ .
>
> Nice; have you send this along upstream? In my experience people are
> usually happy to get things like this.

***Paul, Ralph, thank you for your help.***

I followed your respective instructions and have verified that NFS works
on the SUSE virtual box by mounting locally. I was able to read a test
file in the exported directory.

However, I was unable to get the MPC8313 board to mount, it just hung
there. I didn't wait for it to return message.

When I started the NFS server the following messages appeared (local
test worked as mentioned above):


**********
linux-9vtc:~ # rcnfsserver start
Starting kernel based NFS server: idmapdexportfs: No options for
/home/na/nfstest *: suggest *(sync) to avoid warning
exportfs: /etc/exports [1]: Neither 'subtree_check' or
'no_subtree_check' specified for export "*:/home/na/nfstest".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: No host name given with /home/na/nfstest (ro), suggest *(ro)
to avoid warning
exportfs: /etc/exports [1]: Neither 'subtree_check' or
'no_subtree_check' specified for export "*:/home/na/nfstest".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: duplicated export entries:
exportfs: *:/home/na/nfstest
exportfs: *:/home/na/nfstest
mountd statd nfsd sm-notify
********

Are "exportfs: No host name given..." and "exportfs: duplicated export
entries:" clues?

I ran Wireshark on the Suse virtual box and the following appeared
(192.168.1.104 is the MPC8313 and 192.168.1.105 is the SUSE virtual box):

********
3 3.764642 192.168.1.104 192.168.1.105 TCP izm > sunrpc [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=401054 TSER=0 WS=1

4 5.113492 192.168.1.104 192.168.1.105 TCP tinc > sunrpc [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=401392 TSER=0 WS=1

5 6.761461 192.168.1.104 192.168.1.105 TCP izm > sunrpc [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=401804 TSER=0 WS=1

6 8.761532 Motorola_00:95:02 CadmusCo_a2:ad:66 ARP Who has
192.168.1.105? Tell 192.168.1.104

7 8.761545 CadmusCo_a2:ad:66 Motorola_00:95:02 ARP 192.168.1.105 is at
08:00:27:a2:ad:66

8 12.761716 192.168.1.104 192.168.1.105 TCP izm > sunrpc [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=403304 TSER=0 WS=1

9 24.761970 192.168.1.104 192.168.1.105 TCP izm > sunrpc [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=406304 TSER=0 WS=1
********

Any ideas?

Thanks guys.

Chris Plasun

[Mike Frysinger]

On Saturday 18 April 2009 13:53:36 Michael Abbott wrote:
> On Sat, 18 Apr 2009, Paul Smith wrote:
> > On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
> > > On the board I run "mount -t nfs 192.168.1.102:/home/na/nfstest
> > > /nfstest" but it eventually returns with the following error:
> > >
> > > mount: RPC: Timed out
> > > mount: nfsmount failed: Bad file descriptor
> > > mount: Mounting 192.168.1.102:/home/na/nfstest on /nfstest failed:
> > > Bad file descriptor
> >
> > Also, if you're seeing a delay on the client you probably don't have the
> > portmapper running on the client. If you don't want to add it there
> > that's OK, but then you have to disable lock management; add the "-o
> > nolock" option to your mount command on the client.
>
> This issue, the portmapper, threw me for a long time. Is it still not
> built into busybox?

portmap is dead; long live rpcbind.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090418/70f2adc2/attachment-0001.pgp>

[Michael Abbott]

On Sat, 18 Apr 2009, Mike Frysinger wrote:
> On Saturday 18 April 2009 13:53:36 Michael Abbott wrote:
> > This issue, the portmapper, threw me for a long time. Is it still not
> > built into busybox?
> portmap is dead; long live rpcbind.

Hmm, not aware of that. Is that this project:
http://sourceforge.net/projects/rpcbind/ ?
Same question applies, though -- not in busybox, as far as I can see.
But is this project mature enough? I see it described itself as "beta",
and it's a 0. release ... haven't tried opening that box yet. (And does
it cross compile out of tree without me having to leap through hoops to
figure it out?!)

Is it bigger or smaller than portmap? (I'll download and answer my own
questions later, hopefully tomorrow) ... but what makes it better than
portmap?