>>>>> "Douglas" == Douglas Eck <[EMAIL PROTECTED]> writes:
Douglas> I am running debian sid. I am on a network with my
Douglas> homedirectory served via NFS by a Dell intel box (note,
Douglas> not IRIX) running Redhat 7.1.
Douglas> Under kernels 2.4.14 [patched with sourceforge NFS patch
Douglas> linux-2.4.14-seekdir.dif] and also with unpatched 2.4.7 I
Douglas> have problems with screwed up file reading and writing
Douglas> under nfs. Here's what happens:
What is that patch?
Douglas> If I create a large number of files very quickly... for
Douglas> example by untarring an archive or running a fast script
Douglas> over a directory mounted via NFS, the ls command cannot
Douglas> find the files recently written to:
I was really tearing my hair out over another problem today, maybe it
is related, maybe not.
I mounted a (mostly stable) root partition, over NFS as /mnt. I then
"chroot /mnt" into it, and try to install the libc6, using dpkg (no
apt):
dpkg -i /var/cache/apt/archives/libc6_2.1.3-19_i386.deb
There are two errors I always get, for no good reason.
rmdir("/lib/libthread_db-1.0.so.dpkg-new") = -1 ENOENT (No such file or
directory)
rmdir("/lib/libthread_db-1.0.so.dpkg-tmp") = -1 ENOENT (No such file or
directory)
open("/lib/libthread_db-1.0.so.dpkg-new", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7
shmat(7, 0, 0x3ptrace: umoven: Input/output error
) = ?
fstat64(0x7, 0xbfffeecc) = 0
this one really has me puzzled. Restarting the NFS-server usually helps.
scrooge:stable:/# dpkg -i /var/cache/apt/archives/libc6_2.1.3-19_i386.deb
(Reading database ... 62657 files and directories currently installed.)
Preparing to replace libc6 2.1.3-18 (using .../libc6_2.1.3-19_i386.deb) ...
Unpacking replacement libc6 ...
dpkg: error processing /var/cache/apt/archives/libc6_2.1.3-19_i386.deb
(--install):
unable to create `./lib/libnss_compat-2.1.3.so': Too many levels of symbolic
links
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/libc6_2.1.3-19_i386.deb
this is more typically. Too many symbolic links?????? I can't see
any symbolic links here:
scrooge:stable:/# ls -l ./lib/libnss_compat*
-rw-r--r-- 1 root root 41356 Mar 26 2001
./lib/libnss_compat-2.1.3.so
-rw-r--r-- 1 root root 41660 Oct 31 09:44
./lib/libnss_compat-2.2.4.so
lrwxrwxrwx 1 root root 22 Nov 16 12:04
./lib/libnss_compat.so.2 -> libnss_compat-2.2.4.so
(obviously, yes, I have been screwing around with my system a bit,
with the different versions of glibc... but I don't think that is a
factor with this, the errors always seem to come from the kernel, as
shown with strace.)
strace showed the error occurring when trying to create the .dpkg-new
file, IIRC. Unfortunately I can't get it to reproduce this error
again, right now :-(.
Another strace shows:
rename("//lib/libBrokenLocale-2.1.3.so.dpkg-tmp",
"//lib/libBrokenLocale-2.1.3.so") = 0
rmdir("//lib/libBrokenLocale-2.1.3.so.dpkg-new") = -1 ENOENT (No such file or
directory)
lstat64(0x82f7fe8, 0xbffff91c) = 0
rename("//lib/ld-2.1.3.so.dpkg-tmp", "//lib/ld-2.1.3.so") = 0
rmdir("//lib/ld-2.1.3.so.dpkg-new") = -1 ENOENT (No such file or directory)
close(6dpkg-deb: subprocess paste killed by signal (Broken pipe)
) = 0
haven't seen that one until now.
Any ideas?
--
Brian May <[EMAIL PROTECTED]>
