Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154209 - fsck.ext3 played ping-pong fixing i-Block
Summary: fsck.ext3 played ping-pong fixing i-Block
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-08 13:42 UTC by Frank Wittig
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-08 14:44:45 UTC

Attachments (Terms of Use)

Description Frank Wittig 2005-04-08 13:42:43 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
i had some file system inconsistency yesterday evening.
root and /boot filesystems (both ext3 on md-raid1) got corrupted. the corruption caused a remount in readonly mode trough panic since there was a write attempt to root fs on a file with corruptions.

after reboot root fs could be fixed fine by fsck but fixing /boot was very strange. it said something like this (sorry, couldn't make more useful notations during use of recovery console):
i_Block yxz is 28, should be 208. fix <y>?

i said yes and everything looked fine. except after reboot i got to the recovery console and fsck nor said:
i_Block yxz is 28, should be 208. fix <y>?

this litte play got on an on. fsck played ping-pong between the value 28 and 208 of i_Block xvz.
Through this happened on my very imporant server i fixed the problem by copying everything avay with cpio, formatting /boot and copying everything back there. so i don't have the corrupted fs anymore to gather more details. :-(

sorry for not having more info. i can provide system details, if needed.

Version-Release number of selected component (if applicable):
e2fsprogs-1.35-11.2, kernel-2.6.10-1.760_FC3

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:

Comment 1 Stephen Tweedie 2005-04-08 14:20:23 UTC
I'm not sure we'll be able to make any progress on the limited information here.
 What "corruption" initially caused the remount-readonly situation in the first
place?  What sort of errors were fixed on both filesystems?

Without fuller details, this will probably have to be closed as WORKSFORME.

Comment 2 Frank Wittig 2005-04-08 14:39:12 UTC
I just wanted to have someone find my report if this happens again an know that
this sort of behaviour occured before.
Since I don't have the original fs anymore I'm sorry I can't provide further

Comment 3 Stephen Tweedie 2005-04-08 14:44:45 UTC
OK, thanks.  I'll close it for now but it will stay in the records if we see
anything like this again in the future.

Note You need to log in before you can comment on or make changes to this bug.