Red Hat Bugzilla – Bug 108075
e2fsck dumps core
Last modified: 2015-01-07 19:06:45 EST
Description of problem:
e2fsck segfaults + dumps core when trying to check a filesystem on an attached
FC storage. Core attached.
[root@dl3131 root]# uname -a
Linux dl3131 2.4.9-e.12enterprise #1 SMP Tue Feb 11 01:29:18 EST 2003 i686 unknown
[root@dl3131 root]# modprobe qla2300_6x
[root@dl3131 root]# dmesg
scsi2 : QLogic QLA2300 PCI to Fibre Channel Host Adapter: bus 0 device 8 irq 18
Firmware version: 3.01.18, Driver version 6.04.02
SCSI device sde: 83886080 512-byte hdwr sectors (42950 MB)
[root@dl3131 root]# fdisk -l /dev/sde
Disk /dev/sde: 64 heads, 32 sectors, 40960 cylinders
Units = cylinders of 2048 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sde1 1 40960 41943024 83 Linux
[root@dl3131 root]# ulimit -c
[root@dl3131 root]# e2fsck /dev/sde1
e2fsck 1.26 (3-Feb-2002)
Segmentation fault (core dumped)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: coredump
Expected Results: fsck
will gladly provide more details. just ask.
Created attachment 95512 [details]
e2fsck core dump
This problem can be easily reproduced by running e2fsck on the 1MB
snippet from the beginning of the partition I'll attach right now.
Created attachment 95729 [details]
first one million bytes of the partition in question
This file contains the first one million bytes of the partition (BZ attachment
limitation). Running e2fsck on the file reproduces the problem, when running it
on only the first 100kB, e2fsck gets a short read and aborts.
e2fsprogs-1.34-1 from Fedora Core doesn't crash and brings:
e2fsck 1.34 (25-Jul-2003)
Superblock has a bad ext3 journal (inode 8).
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Steffen Mann was puzzled over kernel 2.4.9-e.12enterprise (As shown in
first report). Upgraded machine to kernel-enterprise-2.4.9-e.25. Did
not change behaviour. Duh.
I would have been really surprised if upgrading the kernel changed the
erroneous behaviour of e2fsck. After all, the error could be
reproduced by running e2fsck on normal file, so the bug would have to
be with e2fsck if other programs don't show the error.
re: Surpise - Me too. But I'm not trying to make sense of it, just
trying to keep RH support happy. If a more recent kernel makes them
happy, so be it. As long as it is one we certified ;-)
And this bug seems to have no friends. Really. Still "NEW" after all
Support ticket is #267706, filed with my account "541004 - Web". Last
thing they told me is they are "escalating to development". Let's see
how fast we come around full circle.
Newer e2fsprogs can fix this problem. I'll have to check if we will
update e2fsprogs to a newer version, but this is probably a too big
upgrade step for an RHEL AS release.
The real question here is what is causing the data corruption and what
kernel or hardware problem you are running into with some reproducable
report and then open that issue up with Red Hat.
Florian La Roche
cannot say _why_ the fs becam corrupted - all I know is, that after an
unclean shutdown, the fsck refused to work on the fs. When I see
something like this again, I'll certainly give more info - but I am
not in a position to do testing with the goal beeing to determine
possible sources of fs corruption. If you have more specific ideas
about test cases, we could make available a test machine. Again - at
this point my ideas of how and what to test are pretty global, too
global to act upon them with justifiable effort.
No reproducable bug for the kernel and working ok for the newest
e2fsprogs rpm to fix the corrupted partition.
Florian La Roche