Bug 154209 - fsck.ext3 played ping-pong fixing i-Block
fsck.ext3 played ping-pong fixing i-Block
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-08 09:42 EDT by Frank Wittig
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-08 10:44:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Wittig 2005-04-08 09:42:43 EDT
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 10:20:23 EDT
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 10:39:12 EDT
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
details.
Comment 3 Stephen Tweedie 2005-04-08 10:44:45 EDT
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.