strange NFS problems (ARM client, x86 server)

strange NFS problems (ARM client, x86 server)

[Lennert Buytenhek]

Hi Trond,

I have an NFS server running 2.6.8-1.521smp (Fedora Core 2 kernel) on
an x86 host, and a client running 2.6.9-rc2 on a big-endian ARM on an
embedded card.  I'm using nfsroot because this card has no directly
attached storage.

>From time to time I see strange problems with files suddenly not being
there anymore but then reappearing, etc.  Today I saw this happening:

-/bin/bash-2.05b# ls -al aumix-2.8-8.armv4b.rpm 
-rw-r--r--  1 root root 72854 Sep 28 20:13 aumix-2.8-8.armv4b.rpm
-/bin/bash-2.05b# rpm -Uvh aumix-2.8-8.armv4b.rpm
/etc/security/selinux/file_contexts: No such file or directory
Preparing...                ########################################### [100%]
error: open of aumix-2.8-8.armv4b.rpm failed: No such file or directory
-/bin/bash-2.05b# strace rpm -Uvh aumix-2.8-8.armv4b.rpm
[...]
chdir("/")                              = 0
chroot("/")                             = 0
[...]
write(1, "Preparing...                ", 28Preparing...                ) = 28
[...]
chroot(".")                             = 0
chdir("")                               = -1 ENOENT (No such file or directory)
[...]
open("aumix-2.8-8.armv4b.rpm", O_RDONLY|O_LARGEFILE)     = -1 ENOENT (No such file or directory)
write(2, "error: ", 7error: )                  = 7
write(2, "open of aumix-2.8-8.armv4"..., 48open of aumix-2.8-8.armv4b.rpm failed: No such file or directory
[...]
-/bin/bash-2.05b# cat aumix-2.8-8.armv4b.rpm > /dev/null
-/bin/bash-2.05b# pwd
/usr/src/redhat/RPMS/armv4b
-/bin/bash-2.05b# cd /usr/src/redhat/RPMS/armv4b
-/bin/bash-2.05b# rpm -Uvh aumix-2.8-8.armv4b.rpm
/etc/security/selinux/file_contexts: No such file or directory
Preparing...                ########################################### [100%]
   1:aumix                  ########################################### [100%]
-/bin/bash-2.05b#


I tried rpm a few times in a row before I changed the directory to `pwd`,
but it failed every time, with every time a similar strace.

Also, my overnight native gcc compile bombed out with the following
message.  Normally it manages to build just fine.

gcc.o: No such file or directory
{standard input}: Assembler messages:
{standard input}:46857: FATAL: Can't write gcc.o: Illegal seek
make[2]: *** [gcc.o] Error 1


I guess you need tcpdumps, no?


thanks,
Lennert

Re: strange NFS problems (ARM client, x86 server)

[Trond Myklebust]

På on , 29/09/2004 klokka 10:23, skreiv Lennert Buytenhek:

> 
> I guess you need tcpdumps, no?

...and a list of mount options used please.

Cheers,
  Trond

Re: strange NFS problems (ARM client, x86 server)

[Tonnerre]

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

Salut,

On Wed, Sep 29, 2004 at 10:23:07AM +0200, Lennert Buytenhek wrote:
> chdir("")                               = -1 ENOENT (No such file or directory)

Interestingly,  rpm requested an  empty chdir.  This narrows  down the
problem.

The following miniapp should be able to reproduce the problem:

cat << EOT > blah.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void) {
	if (chdir("")) {
		perror("chdir");
		exit(1);
	}
	exit(0);
}
EOT

Does it?

			    Tonnerre

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

Re: strange NFS problems (ARM client, x86 server)

[Lennert Buytenhek]

On Wed, Sep 29, 2004 at 10:33:47PM +0200, Tonnerre wrote:

> Salut,

Hi,


> > chdir("")                               = -1 ENOENT (No such file or directory)
> 
> Interestingly,  rpm requested an  empty chdir.  This narrows  down the
> problem.

I don't think it does, as the second invocation of RPM (after cd 'pwd')
also does this, but works fine.


> The following miniapp should be able to reproduce the problem:
> 
> cat << EOT > blah.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> 
> int main(void) {
> 	if (chdir("")) {
> 		perror("chdir");
> 		exit(1);
> 	}
> 	exit(0);
> }
> EOT

'current directory' is per-process state.  You'll end up changing the
current directory in the child process, but not the parent.


--L