Your message dated Sat, 29 Jul 2006 23:17:57 -0400
with message-id <[EMAIL PROTECTED]>
and subject line please close this bug
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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.)
--- End Message ---
--- Begin Message ---
Version 1.39 fixed my problem.
--
gif
--- End Message ---
