I just got a report from `sxid'[1] showing some files with wierd
modes that have uid/gid settings for users and groups that do not
exist on this laptop. When I went to investigate, I found that I
could not remove those files, and discovered that they are device
nodes.
... which cannot be removed. I tried to `lsattr' them, and it says
it cannot find the modules for those devices. I ran a find command
and verified that those are the only device nodes outside of /dev. I
don't know how to check /dev/ for oddball nodes that don't belong
there or are camoflaged hack devices or what could they be.
This problem is caused by random garbage getting written to your inode
table. Typically it's caused by hardware problems, although sometimes
unclean powerdowns can cause this (presumably because the disk drive
writes wrote data to the wrong place due to the shutdown).
The block device files have the immutable and/or append-only flag set,
which is why you can't delete them. Unfortunately, chattr can't clear
the immutable flag since currently setting and clearing flags is done
using an ioctl, and the block device grabs the ioctl before ext2 has a
chance to process it. So normally you can't set or clear ext2 flags on
devices. But if the flags are artificially set, due to garbage written
to the inode table, there's no way to clear them programmatically.
The latest version of e2fsck, in e2fsprogs version 1.14, has code to
better detect and clear such garbage block devices. I would advise
upgrading to the latest version of e2fsck and running it on your
(unmounted) filesystem. That's the easist way to clear the bogus
entries.
You should try to determine why you are getting garbage written to your
inode table, since this will almost certainly cause you data loss in the
long run. For example, the contents of these files (at least) were
certainly lost:
b--s--S-wx 1 24933 26988 107, 116 Jan 19 1970 /usr/src/cmucl-2.4.8/src/tools/CVS/Entries
br-s-w-rwx 1 25710 27476 46, 107 Jan 4 1970 /usr/src/cmucl-2.4.8/src/tools/build-and-install
b--xr-SrwT 1 25971 28271 103, 46 Jan 18 1970 /usr/src/cmucl-2.4.8/src/tools/clmcom.lisp
You said this was on a laptop; do you always do clean shutdowns before
powering off your laptop? Are you using the APM "hibernate" feature?
(If you can associate the damage occuring with use of the "hiberate"
feature, it may be that you have a buggy APM bios that isn't handling
save-to-disk correctly.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/