Root-on-NFS /dev has incorrect major/minor numbers

Hi there,

I've been nutting out this problem that I've come across after upgrading
one of my linux machines that acts as an NFS server to another machine
on which I am trying to install Debian 3.0 in a completely diskless way.

The problem is essentially incorrect major/minor numbers in the /dev
directory on the remote client's root filesystem which happens to be
mounted over NFS from the server. After much searching and tidbits of
information from various places, it would appear to be something to do
with how NFS v2 and v3 handle device files.

Mounting the filesystem using NFSv2 gives the client properly formed
device files with correct major/minor numbers. Mounting using NFSv3
appears to copy the major number over the minor number and thus most
devices don't work.

Does anyone know if this seemingly incorrect behaviour is intentional?
I'm using 2.2.20 on the client and 2.4.20 on the server. Is it likely to
be fixed, or should I be going about it completely differently (e.g.
/dev on ramdisk or something similar)?

Cheers,
Oliver

Oliver Hookins wrote:
>
> Mounting the filesystem using NFSv2 gives the client properly formed
> device files with correct major/minor numbers. Mounting using NFSv3
> appears to copy the major number over the minor number and thus most
> devices don't work.

What versions does the server support? If the server is only v2 that
might explain it.

>
> Does anyone know if this seemingly incorrect behaviour is intentional?
> I'm using 2.2.20 on the client and 2.4.20 on the server. Is it likely to
> be fixed, or should I be going about it completely differently (e.g.
> /dev on ramdisk or something similar)?

I was unable to duplicate your problem. I was using v3 on server and
client. I suspect there is something wrong with your configuration.

Grant wrote:
>
> What versions does the server support? If the server is only v2 that
> might explain it.

The server supports v2 and v3.

[root@hektor root]# nfsstat
Server rpc stats:
calls badcalls badauth badclnt xdrcall
13674 0 0 0 0
Server nfs v2:
null getattr setattr root lookup readlink
1 0% 2 0% 0 0% 0 0% 1148 98% 2 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% 7 0% 1 0%

Server nfs v3:
null getattr setattr lookup access readlink
1 0% 3 0% 8 0% 3614 28% 8397 67% 8 0%
read write create mkdir symlink mknod
424 3% 8 0% 0 0% 0 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 36 0% 0 0%
fsstat fsinfo pathconf commit
3 0% 3 0% 0 0% 8 0%

>> Does anyone know if this seemingly incorrect behaviour is intentional?
>> I'm using 2.2.20 on the client and 2.4.20 on the server. Is it likely
>> to be fixed, or should I be going about it completely differently
>> (e.g. /dev on ramdisk or something similar)?
>
> I was unable to duplicate your problem. I was using v3 on server and
> client. I suspect there is something wrong with your configuration.

The server is a pretty fresh load of Redhat 7.3 with updates. As far as
configuration goes, /etc/exports reads as follows:

/tftpboot/192.168.1.170 192.168.1.170(rw,no_root_squash)

I actually had it all working properly when I had Redhat 7.1 running on
the server, but I have been assuming there were changes made in the
kernel to the NFS server between those releases which is causing these
problems. I know that going back to 2.4.18 doesn't change it.

The client is mounting with vers=3,dev,rw. I'd be glad if it's just a
configuration issue but I can't think of what it might be - I've
literally set it up exactly the same way as it was running before.

Oliver

Grant wrote:
>
> I was unable to duplicate your problem. I was using v3 on server and
> client. I suspect there is something wrong with your configuration.
>

Could I ask the version of kernel you are running on your server and
client, and if they are custom kernels or precompiled distro-specific?

Thanks,
Oliver