SEO

I am using Gentoo, and I updated the system using emerge -uDA. I am no
longer able to mount NFS fileshares on my NFS server (running Debian).

mount neptune:/volumes/vol3a/ /volumes/vol3a/
mount: wrong fs type, bad option, bad superblock on
neptune:/volumes/vol3a/,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

I have no messages relating to NFS in either syslog or dmesg on the
client, with last messages in dmesg as follows:

dmesg|tail
smc-ultra.c: ISAPnP reports SMC EtherEZ (8416) at i/o 0x240, irq 5.
smc-ultra.c:v2.02 2/3/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
eth%d: SMC EtherEZ at 0x240, 00:e0:29:4c:ce:16,assigned IRQ 5
programmed-I/O mode.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Adding 2706912k swap on /dev/hda8. Priority:-1 extents:1
across:2706912k
Real Time Clock Driver v1.12ac

I performed a system trace as follows:

strace -o/tmp/mount.strace mount neptune:/volumes/vol3a/ /volumes/vol3a/

This produces the following output:

execve("/bin/mount", ["mount", "neptune:/volumes/vol3a/",
"/volumes/vol3a/"], [/
* 22 vars */]) = 0
brk(0) = 0x8056000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12566, ...}) = 0
mmap2(NULL, 12566, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f6d000
close(3) = 0
open("/lib/libblkid.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3 60!\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=36312, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7
f6c000
mmap2(NULL, 39188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7f
62000
mmap2(0xb7f6a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRIT
E, 3, 0x7) = 0xb7f6a000
close(3) = 0
open("/lib/libuuid.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\ 20\0\0004\0\0\0"..., 5
12) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=13824, ...}) = 0
mmap2(NULL, 16608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7f5d000
mmap2(0xb7f60000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7f60000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a \1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1192036, ...}) = 0
mmap2(NULL, 1197520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7e38000
mmap2(0xb7f57000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11f) = 0xb7f57000
mmap2(0xb7f5a000, 9680, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5a000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7e37000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e37700,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f57000, 8192, PROT_READ) = 0
mprotect(0xb7f60000, 4096, PROT_READ) = 0
mprotect(0xb7f6a000, 4096, PROT_READ) = 0
mprotect(0x8053000, 4096, PROT_READ) = 0
mprotect(0xb7f8b000, 4096, PROT_READ) = 0
munmap(0xb7f6d000, 12566) = 0
brk(0) = 0x8056000
brk(0x8077000) = 0x8077000
umask(022) = 022
open("/dev/null", O_RDWR|O_LARGEFILE) = 3
close(3) = 0
getuid32() = 0
geteuid32() = 0
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=292, ...}) = 0
stat64("neptune:/volumes/vol3a/", 0xbfffbd74) = -1 ENOENT (No such file
or directory)
stat64("/sbin/mount.nfs", 0xbfffbb00) = -1 ENOENT (No such file or
directory)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
stat64("/sbin/mount.nfs", 0xbfffbae0) = -1 ENOENT (No such file or
directory)
mount("neptune:/volumes/vol3a/", "/volumes/vol3a/", "nfs"...,
MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
write(2, "mount: wrong fs type, bad option"..., 134) = 134
write(2, "\n", 1) = 1
stat64("neptune:/volumes/vol3a/", 0xbfffbc70) = -1 ENOENT (No such file
or directory)
write(2, " In some cases useful info"..., 85) = 85
write(2, "\n", 1) = 1
exit_group(32)

Does anyone know what may have gone wrong here?

The kernel is a 2.6.24.3 vanilla kernel on the Gentoo client, running on
an IBM compatible computer using a Pentium compatible processor.

The NFS server is running Debian stable with a 2.6.18-6-486 kernel
(also running on conventional IBM compatible hardware, using a conventional
Pentium processor.)

Thanks in advance to anyone who can help.

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

On Tue, 08 Apr 2008 11:08:04 GMT, Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>I am using Gentoo, and I updated the system using emerge -uDA. I am no
>longer able to mount NFS fileshares on my NFS server (running Debian).

>mount neptune:/volumes/vol3a/ /volumes/vol3a/
>mount: wrong fs type, bad option, bad superblock on
>neptune:/volumes/vol3a/,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so

>I have no messages relating to NFS in either syslog or dmesg on the
>client, with last messages in dmesg as follows:

Have you tried re-emerging nfs-utils?

Mark Hobley wrote:

> I am using Gentoo, and I updated the system using emerge -uDA. I am no
> longer able to mount NFS fileshares on my NFS server (running Debian).

I may be way out of my league here, but I'm willing to point out a few
things that may in turn lead you to resolving this problem. ;-)

> mount neptune:/volumes/vol3a/ /volumes/vol3a/
> mount: wrong fs type, bad option, bad superblock on
> neptune:/volumes/vol3a/,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so

First of all, you're probably aware that NFS comes in two versions, one of
them being the traditional NFSv3 still used by most implementations, the
other one being the newer NFSv4 that allows a connection over either UDP -
as has always been the custom - or over TCP/IP, which is new.

So I think it's important to check whether the NFS server and the client are
both using the same NFS version and whether they are both speaking the same
network packet protocol. This could pertain to the "wrong fs type, bad
option, bad superblock" error message.

Of course, I am just guessing at this point, and I'm by far not as
experienced with NFS as my willingness to reply to your post seems to
suggest. ;-)

> I have no messages relating to NFS in either syslog or dmesg on the
> client, with last messages in dmesg as follows:
>
> dmesg|tail
> smc-ultra.c: ISAPnP reports SMC EtherEZ (8416) at i/o 0x240, irq 5.
> smc-ultra.c:v2.02 2/3/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> eth%d: SMC EtherEZ at 0x240, 00:e0:29:4c:ce:16,assigned IRQ 5
> programmed-I/O mode.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Adding 2706912k swap on /dev/hda8. Priority:-1 extents:1
> across:2706912k
> Real Time Clock Driver v1.12ac

These are irrelevant, other than that they tell you that you have support
for both UDP and TCP/IP in RPC (remote procedure call).

> I performed a system trace as follows:
>
> strace -o/tmp/mount.strace mount neptune:/volumes/vol3a/ /volumes/vol3a/
>
> This produces the following output:
>
> execve("/bin/mount", ["mount", "neptune:/volumes/vol3a/",
> "/volumes/vol3a/"], [/
> * 22 vars */]) = 0
> brk(0) = 0x8056000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)

First clue... It's looking for something that isn't there (anymore)...

> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=12566, ...}) = 0
> mmap2(NULL, 12566, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f6d000
> close(3) = 0
> open("/lib/libblkid.so.1", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3 60!\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=36312, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7
> f6c000
> mmap2(NULL, 39188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb7f
> 62000
> mmap2(0xb7f6a000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRIT
> E, 3, 0x7) = 0xb7f6a000
> close(3) = 0
> open("/lib/libuuid.so.1", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\ 20\0\0004\0\0\0"..., 5
> 12) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=13824, ...}) = 0
> mmap2(NULL, 16608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0xb7f5d000
> mmap2(0xb7f60000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7f60000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a \1\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1192036, ...}) = 0
> mmap2(NULL, 1197520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0xb7e38000
> mmap2(0xb7f57000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11f) = 0xb7f57000
> mmap2(0xb7f5a000, 9680, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5a000
> close(3) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7e37000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e37700,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> mprotect(0xb7f57000, 8192, PROT_READ) = 0
> mprotect(0xb7f60000, 4096, PROT_READ) = 0
> mprotect(0xb7f6a000, 4096, PROT_READ) = 0
> mprotect(0x8053000, 4096, PROT_READ) = 0
> mprotect(0xb7f8b000, 4096, PROT_READ) = 0
> munmap(0xb7f6d000, 12566) = 0
> brk(0) = 0x8056000
> brk(0x8077000) = 0x8077000
> umask(022) = 022
> open("/dev/null", O_RDWR|O_LARGEFILE) = 3
> close(3) = 0
> getuid32() = 0
> geteuid32() = 0
> lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=292, ...}) = 0
> stat64("neptune:/volumes/vol3a/", 0xbfffbd74) = -1 ENOENT (No such file
> or directory)

Second clue, see the one above... ;-)

> stat64("/sbin/mount.nfs", 0xbfffbb00) = -1 ENOENT (No such file or
> directory)

Third clue, ditto... :-)

> rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
> stat64("/sbin/mount.nfs", 0xbfffbae0) = -1 ENOENT (No such file or
> directory)

Fourth clue...

> mount("neptune:/volumes/vol3a/", "/volumes/vol3a/", "nfs"...,
> MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
> write(2, "mount: wrong fs type, bad option"..., 134) = 134
> write(2, "\n", 1) = 1
> stat64("neptune:/volumes/vol3a/", 0xbfffbc70) = -1 ENOENT (No such file
> or directory)
> write(2, " In some cases useful info"..., 85) = 85
> write(2, "\n", 1) = 1
> exit_group(32)
>
> Does anyone know what may have gone wrong here?
>
> The kernel is a 2.6.24.3 vanilla kernel on the Gentoo client, running on
> an IBM compatible computer using a Pentium compatible processor.

The kernel version is less important here than how it was configured. You
should definitely doublecheck the NFS versions supported in the kernel.

> The NFS server is running Debian stable with a 2.6.18-6-486 kernel
> (also running on conventional IBM compatible hardware, using a
> conventional Pentium processor.)

The kernel version of the server is less important, unless it is using a
kernel-based NFS server, of which I don't think it was already present in
the 2.6.18 release anyway.

Up until the availability of a kernel-based NFS server, NFS is typically
exported via the /nfsd/ daemon, which in turn will launch /lockd/ via your
System V /init/ scripts.

> Thanks in advance to anyone who can help.

That's about all I can tell you, and although it isn't much, it might steer
you in the right direction. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

On Tue, 08 Apr 2008 14:53:21 +0200, Aragorn <aragorn@chatfactory.invalid> wrote:
>Mark Hobley wrote:

>> I am using Gentoo, and I updated the system using emerge -uDA. I am no
>> longer able to mount NFS fileshares on my NFS server (running Debian).

>I may be way out of my league here, but I'm willing to point out a few
>things that may in turn lead you to resolving this problem. ;-)

>> mount neptune:/volumes/vol3a/ /volumes/vol3a/
>> mount: wrong fs type, bad option, bad superblock on
>> neptune:/volumes/vol3a/,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so

>First of all, you're probably aware that NFS comes in two versions, one of
>them being the traditional NFSv3 still used by most implementations, the
>other one being the newer NFSv4 that allows a connection over either UDP -
>as has always been the custom - or over TCP/IP, which is new.

>So I think it's important to check whether the NFS server and the client are
>both using the same NFS version and whether they are both speaking the same
>network packet protocol. This could pertain to the "wrong fs type, bad
>option, bad superblock" error message.

In the linux world, nfs4 is still considered experemental and you can't
specify it by accident. fstab has to have 'nfs4' instead of 'nfs' as the
filesystem type. You also have to build a new kernel with nfs4 support
enabled. nfsutils should still support nfs3 and the kernel should also
support nfs3 unless one went into the kernel configuration and specifically
removed nfs3 support then built a new kernel.


I played around w/ nfs4 and found its permissions scheme to be a royal PITA.
Pretty much every single file off the server was considered to be owned by
'nobody'. You have to enable another authentication protocol like kerberos
or gssd and I gave up trying to get it working. And of course, an nfs4
server can not have shared directories from two separate locations; they
have to have a common directory from which they derive.

Mark Hobley wrote:
> I am using Gentoo, and I updated the system using emerge -uDA. I am no
> longer able to mount NFS fileshares on my NFS server (running Debian).
>
> mount neptune:/volumes/vol3a/ /volumes/vol3a/
> mount: wrong fs type, bad option, bad superblock on
> neptune:/volumes/vol3a/,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so

This indicates the version of nfs you try to mount ain't supported on the
client machine.

I suggest you run

rpcinfo -p neptune

on the client machine, and you should get an output something like:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32769 status
100024 1 tcp 49475 status
100005 1 udp 32770 mountd
100005 1 tcp 54715 mountd
100005 2 udp 32770 mountd
100005 2 tcp 54715 mountd
100005 3 udp 32770 mountd
100005 3 tcp 54715 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 45138 nlockmgr
100021 3 tcp 45138 nlockmgr
100021 4 tcp 45138 nlockmgr

If you don't, then you don't even have the right to connect to the remote
machine with the nfs share.

You can also run "nfsstat" on the remote machine, this way you can see which
NFS version it runs (debian suxx on sharing the configuration through proc).


--

//Aho

In alt.os.linux.gentoo J.O. Aho <user@example.net> wrote:

> This indicates the version of nfs you try to mount ain't supported on the
> client machine.

> rpcinfo -p neptune

Here is my output:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 2051 status
100024 1 tcp 2135 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 udp 2062 nlockmgr
100021 3 udp 2062 nlockmgr
100021 4 udp 2062 nlockmgr
100021 1 tcp 4500 nlockmgr
100021 3 tcp 4500 nlockmgr
100021 4 tcp 4500 nlockmgr
100005 1 udp 754 mountd
100005 1 tcp 757 mountd
100005 2 udp 754 mountd
100005 2 tcp 757 mountd
100005 3 udp 754 mountd
100005 3 tcp 757 mountd

> You can also run "nfsstat" on the remote machine, this way you can see which
> NFS version it runs (debian suxx on sharing the configuration through proc).

On remote (neptune):

nfsstat
Server rpc stats:
calls badcalls badauth badclnt xdrcall
1136889 0 0 0 0

Server nfs v2:
null getattr setattr root lookup
readlink
1 100% 0 0% 0 0% 0 0% 0 0% 0
0%
read wrcache write create remove rename
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
link symlink mkdir rmdir readdir fsstat
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%

Server nfs v3:
null getattr setattr lookup access
readlink
11 0% 266236 23% 45752 4% 247414 21% 156077 13% 2837
0%
read write create mkdir symlink mknod
171355 15% 107666 9% 38574 3% 4977 0% 12744 1% 1
0%
remove rmdir rename link readdir
readdirplus
39049 3% 3809 0% 2837 0% 1 0% 1675 0% 25528
2%
fsstat fsinfo pathconf commit
49 0% 19 0% 0 0% 5446 0%

Client rpc stats:
calls retrans authrefrsh
0 0 0

Client nfs v4:
null read write commit open
open_conf
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
open_noat open_dgrd close setattr fsinfo renew
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
setclntid confirm lock lockt locku access
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
getattr lookup lookup_root remove rename link
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
symlink create pathconf statfs readlink readdir
0 0% 0 0% 0 0% 0 0% 0 0% 0
0%
server_caps delegreturn
0 0% 0 0%

I did manage to get NFS working prior to the kernel upgrade.

I am currently rebuild nfs-utils, so I will know shortly whether or not
that fixes the problem.

Mark.

Regards,

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

In alt.os.linux.gentoo Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
> I am currently rebuild nfs-utils, so I will know shortly whether or not
> that fixes the problem.

Hmmm, it actually has fixed the problem. I wonder why emerge -uDN world
does not update this package. I thought it was supposed to rebuild the
entire system.

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

Mark Hobley wrote:
> In alt.os.linux.gentoo Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>> I am currently rebuild nfs-utils, so I will know shortly whether or not
>> that fixes the problem.
>
> Hmmm, it actually has fixed the problem. I wonder why emerge -uDN world
> does not update this package. I thought it was supposed to rebuild the
> entire system.

The file ain't in the world file (/var/lib/portage/world), which means it
won't be updated when you update world. Add it to the file and it should be
updated next time.


--

//Aho