Your message dated Sat, 11 Nov 2006 20:43:14 -0500
with message-id <[EMAIL PROTECTED]>
and subject line e2fsprogs: e2fsck segfault when setting i_fsize to zero
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 ---
Subject: e2fsprogs: e2fsck segfault when setting i_fsize to zero
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.)
--
gif
KC8PIN
Give a man a fire, and he'll be warm for a day.
Set a man on fire, and he'll be warm for the rest of his life.
--- End Message ---
--- Begin Message ---
Package: e2fsprogs
Version: 1.38-2
This is another manifestation of the same bug as Debian bugs #316736 and
#318463. It was fixed in e2fsprogs 1.39, as well as in Debian e2fsprogs
package 1.38-2.
It's been too much of a pain to get an update into stable-updates (I've
tried twice, and for reasons unknown to me it hasn't happened), so at
this point my suggestion is for you to use the e2fprogs from
backports.org.
Regards,
- Ted
--- End Message ---
