Package: e2fsprogs Version: 1.37-2sarge1 Severity: important
-- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages e2fsprogs depends on: ii e2fslibs 1.37-2sarge1 ext2 filesystem libraries ii libblkid1 1.37-2sarge1 block device id library ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an ii libcomerr2 1.37-2sarge1 common error description library ii libss2 1.37-2sarge1 command-line interface parsing lib ii libuuid1 1.37-2sarge1 universally unique id library -- no debconf information When running e2fsck on a corrupted filesystem on a raid array, I'm getting predictable, repeatable segfaults. The basic symptoms of an inode that will demonstrate my issue are as follows: i_file_acl for inode 16770 (...) is 3754291225, should be zero. Clear? yes i_faddr for inode 16770 (...) is 1230742022, should be zero. Clear? yes i_frag for inode 16770 (...) is 21, should be zero. Clear? yes i_fsize for inode 16770 (...) is 183, should be zero. Clear? yes Segmentation fault Now, if I do the following: i_file_acl for inode 16770 (...) is 3754291225, should be zero. Clear<y>? yes i_faddr for inode 16770 (...) is 1230742022, should be zero. Clear<y>? yes i_frag for inode 16770 (...) is 21, should be zero. Clear<y>? yes i_fsize for inode 16770 (...) is 183, should be zero. Clear<y>? no Unattached inode 16770 Connect to /lost+found<y>? yes Inode 16770 ref count is 50532, should be 1. Fix<y>? yes and then re-run fsck and do the following during pass 2: i_fsize for inode 16770 (/lost+found/#16770) is 183, should be zero. Clear<y>? yes Entry '#16770' in /lost+found (13) has an incorrect filetype (was 3, should be 0). Fix<y>? yes Then I'm in the clear. Thoughts? (Yes, I fixed this one. Don't worry; I have plenty more examples.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
