Bug 108075
Summary: | e2fsck dumps core | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Florenz Kley <florenz.kley> | ||||||
Component: | e2fsprogs | Assignee: | Florian La Roche <laroche> | ||||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Jay Turner <jturner> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 2.1 | CC: | nphilipp, srevivo, tao | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2003-12-09 14:22:28 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Florenz Kley
2003-10-27 14:01:30 UTC
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).
Clear<y>? yes
*** 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 this time. 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. greetings, 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. greetings, Florian La Roche |