NFSv2 problem? initctl problem?

NFSv2 problem? initctl problem?

[mjt]

Hi!

I've been trying, quite desperately, to get FAI working but there appears
to be some bad karma.

The server exports /usr/local/share/fai with async,rw and
/usr/lib/fai/nfsroot with async,rw,no_root_squash
Originally I had ro, but that did not seem to matter.

I get to the point where the 2.4.24-fai kernel of Debian boots, but it
stalls after the FAI_FLAGS: syslogd=1 line.

According to Ethereal, the big problem is in getting a getattr response
from the server. It looks like this:

mount: RPC: Remote system error - Connection timed out
/fai/class not found. Aborting.

It did not abort, though; it still sends out the getattr query
and gets a response.

According to the tcpdump, the file id in question is 147491.

mjt@hinkistan:~$ find /usr/lib/fai/nfsroot/ -inum 147491 | xargs file
find: /usr/lib/fai/nfsroot/var/spool/cron/crontabs: Permission denied
find: /usr/lib/fai/nfsroot/root/.ssh: Permission denied
/usr/lib/fai/nfsroot/dev/initctl: fifo (named pipe)

On the server side I'm running Debian Sarge with 2.4.18-bf2.4, all
clear, and trying to use 2.4.24-fai for the installer, which should
be clear as well.

It doesn't matter whether I use the kernel- or user-space NFS implementation,
it still dies on me, except that I'd rather use the kernel-space one.

Now what I'm wondering about is where is the error?

Is it possible there's some issue with NFSv2; should I use NFSv3 instead?

How can I force the client to use only NFSv3? rpc.mountd -N2 -V3 should
work, right? But it still speaks v2 according to the traffic AND affects
only the server-side, in theory, if not in practice apparently.

The underlying filesystem is ReiserFS, so I'm sending a copy of this
mail to the ReiserFS list as well, to see if anyone over there knows
anything about this. If need be, I can reinstall the FAI server to use
some other FS, but I would not like to do that.

With the user-space NFS implementation I got the file id of 1476542499
which does not have a file in the file system at all. Might this be
because of ReiserFS? An ancient curse? NFS just being broken?

Any help is greatly appreciated here, I have a deadline coming up for
this installation and just out of principle I would dislike doing it
from a CD as I'm going to install a lot more of these Debians and need
FAI working...

PS.
Semi-off topic, what's the status of NFSv4? rpc.mountd supports something
like it but is it in Linux already?
Should I seek answers elsewhere than in 0d NFS protocols?

Thanks a million!

-- 
mjt

Re: NFSv2 problem? initctl problem?

[Bernd Schubert]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]


> It doesn't matter whether I use the kernel- or user-space NFS
> implementation, it still dies on me, except that I'd rather use the
> kernel-space one.

Don't use te unfsd except for special reasons. If you want to test a userspace 
daemon just use unfs3 (unfs3.sf.net).

>
> Now what I'm wondering about is where is the error?
>
> How can I force the client to use only NFSv3? rpc.mountd -N2 -V3 should
> work, right? But it still speaks v2 according to the traffic AND affects
> only the server-side, in theory, if not in practice apparently.

"man 5 nfs", mountoption is "nfsvers=3"

>
> The underlying filesystem is ReiserFS, so I'm sending a copy of this
> mail to the ReiserFS list as well, to see if anyone over there knows
> anything about this. If need be, I can reinstall the FAI server to use
> some other FS, but I would not like to do that.
>
> With the user-space NFS implementation I got the file id of 1476542499
> which does not have a file in the file system at all. Might this be
> because of ReiserFS? An ancient curse? NFS just being broken?

I wouldn't use the old userspace daemon with reiserfs at all, if you want to 
do this, just use unfs3.

>
> Any help is greatly appreciated here, I have a deadline coming up for
> this installation and just out of principle I would dislike doing it
> from a CD as I'm going to install a lot more of these Debians and need
> FAI working...

Well, your testing approach is a bit strange:

1.) I would use the knfsd.
2.) To test if exporting works, I would take a second non-rootnfs system and 
try to mount the exported directories on this system. This will help you a 
lot since you can experiment with mount options on this system and you can 
check the syslogs.
3.) I mounting from you second server works, you can go on and see what 
happens in your fai environment.

>
> PS.
> Semi-off topic, what's the status of NFSv4? rpc.mountd supports something
> like it but is it in Linux already?
> Should I seek answers elsewhere than in 0d NFS protocols?

Your questions are completety off topic from the view of reiserfs, since there 
are many people (including our group) who use nfs and reiserfs. However you 
should use unfsd and reiserfs. A group suitable for nfs questions is 
"nfs@lists.sourceforge.net".  NFSv4 is still in early development and I 
wouldn't use it except for some tests (actually I never used it at all, but I 
see all of those patches about it on the nfs-list).


Cheers, 
	Bernd

PS: If you should decide to unfs3 for some tests, make sure it is able to 
include the ext2_fs.h, unfortunality the one from the debian kernel-headers 
package is broken :(, replace it with the file from Mariusz Mazur headers 
(http://ep09.pld-linux.org/~mmazur/linux-libc-headers/)


-- 
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NFSv2 problem? initctl problem?

[mjt]

On Thu, Aug 19, 2004 at 12:56:34PM +0200, Bernd Schubert wrote:
>
>Don't use te unfsd except for special reasons. If you want to test a userspace 
>daemon just use unfs3 (unfs3.sf.net).

I may have given the wrong impression here, I am still trying to use
knfsd here, I just tried the userspace one and noticed that it did not work.

>"man 5 nfs", mountoption is "nfsvers=3"

Heh, sorry about that one :)
OK, just have to google around on how to have it affect root=/dev/nfs

>> With the user-space NFS implementation I got the file id of 1476542499
>I wouldn't use the old userspace daemon with reiserfs at all, if you want to 
>do this, just use unfs3.

So I assume there's something really broken here, but still, it is irrelevant
because knfsd, which should work, doesn't work. And unless you or anyone
else who knows better than me about the situation on Linux NFS implementations
tells me unfs3 is better than knfsd, I'll stick to it :)

>2.) To test if exporting works, I would take a second non-rootnfs system and 
>try to mount the exported directories on this system. This will help you a 
>lot since you can experiment with mount options on this system and you can 
>check the syslogs.

I can mount the root-fs-to-be, /usr/lib/fai/nfsroot, on netbsd and read
from it. Unfortunately I don't yet have any other Linux at hand, and
depending on if FAI works or not, I won't have one today. At least I don't
think I can accomplish one, unless I conjure up an installation CD.

>3.) I mounting from you second server works, you can go on and see what 
>happens in your fai environment.

Is there any way of seeing more of the FAI environment?
Possibly I should edit in an interactive shell somehow.

But is it usual for knfsd with v2 to get stuck on /dev/initctl?
For the record, I also tried sync instead of async and with taking away
devfs=nomount...

From what I've gathered, getattr is just a side-effect of doing something
else, but NFS doesn't say what it's doing to a file. Does FAI or something
have a verbosity switch for this? More verbose than FAI_FLAGS: verbose=1 :P

>Your questions are completety off topic from the view of reiserfs, since there 
>are many people (including our group) who use nfs and reiserfs. However you 

I'm almost desperate here, please forgive me :)

I will remove the reiserfs-list in my next reply.

>PS: If you should decide to unfs3 for some tests, make sure it is able to 

I might if I have more time, now I'd rather have just something, ANYTHING,
that works..

>include the ext2_fs.h, unfortunality the one from the debian kernel-headers 
>package is broken :(, replace it with the file from Mariusz Mazur headers 
>(http://ep09.pld-linux.org/~mmazur/linux-libc-headers/)

Thanks for the tip and the reply!

-- 
mjt