Hello,
it looks like that the latest security update to the kernel fixes this
problem:
http://www.debian.org/security/2006/dsa-1184
here:
http://bugzilla.kernel.org/show_bug.cgi?id=6828
and here:
http://www.securityfocus.com/bid/19396/info
Best.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTE
Hello Goswin,On 6/16/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
Did you reboot the nfs server while clients had the fs mounted? Orstoped the nfsd and run fsck or a resize? Anything that could change
the inode numbers without the clients getting any notice?Yes, we rebooted and recreated the
Hello,at the moment our server prints regularily like two times a minute the same message to kern.log:EXT2-fs error (device dm-5): ext2_get_inode: bad inode number: 30130240I checked and the inode really does not exist on the specified device (dm-5 is
the device with minor number 5 under /dev/mappe
Hello,
thanks for your info. That means it is a bug in ext3. It seems
to ignore the errors=continue mount option, although
according to the manpage it should support all the
options that ext2 does.
Unfortunately I'm not able to reproduce this exact behaviour, however
I am able to produce a file
Package: kernel-image-2.6.8-2-686-smpVersion: 2.6.8-16Hello, Our central nfs-server is running Debian/Sarge and there are ~300 nfs Clients running under Debianor Solaris. At one point we had to recreate the exported (ext3) filesystems on the server and
copy the data back from backup. Although we
5 matches
Mail list logo
