Messages in this thread | | | Date | Fri, 2 Jul 1999 15:52:55 -0400 | Subject | Re: Filesystem corruption, undeletable device files | From | tytso@mit ... |
| |
From: karlheg@debian.org (Karl M. Hegbloom) Date: 30 Jun 1999 02:40:24 -0700
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/
| |