Bug 77222 - Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-03 11:24 EST by Matt Dorsch
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-03 11:24:34 EST
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 Matt Dorsch 2002-11-03 11:24:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-3 i686)

Description of problem:
I am upgrading from a FIC SD11 mobo to an Asus P4PE mobo. The Asus uses the
Intel 845PE chipset. The linux install is 7.3. When I first performed the
upgrade, I did run into the Ultra DMA issues previously reported. I upgraded to
2.4.18-17, and UDMA started working. However, yesterday I found my root
partition (ext2) with filesystem corruption after a clean shutdown. I ran fsck.
It found a few dozen errors, including bad dtimes, and "compression bit is set
for file on uncompressed filesystem". I ran badblocks. It found block 530112 to
be bad. (The partition has blocks 0 through 530113.) I downloaded Seagate's
drive tools to check the new ST380021A drive I had upgraded to. It found the
drive to be in perfect condition. I tried badblocks using the rescue mode on the
7.3 install CD. It complained that block 530112 was bad. I removed the drive and
placed it in the old SD11 system. I booted with the 7.3 CD. Badblocks found the
partition to be in perfect condition. As for the filesystem corruption, i'm not
sure how to reproduce it. I just used the system as I normally would. I'm not
even sure it's part of the same problem, though I would think they would be
symptoms of the same defect. What should I do next? 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Place drive in my 845PE system.
2. Boot with 7.3 CD rescue mode.
3. Run badblocks on /dev/hda5.
(I have no idea how well this will reproduce on other 845PE systems with other
drives tho...)
	

Actual Results:  badblocks indicates 530112 is bad.

Expected Results:  No bad blocks should be found.

Additional info:

(I'm setting the severity to high because of the filesystem corruption. If you
want to change that, feel free to.)
Comment 1 Matt Dorsch 2002-11-03 16:00:19 EST
Ok, the kernel does not seem to be the issue for the bad block indication. When
I use the rescue mode, one is given three options for mounting the host
filesystems: Continue (?), Read Only, and Skip. When I choose Continue, the
rescue process mounts my partitions as found in /etc/fstab under /mnt/sysimage.
When I do this, badblocks reports the bad block. If I just choose skip and leave
it unmounted, badblocks says it's a clean partition. I think the issue is that I
have had the filesystem mounted on certain tests, and not on others. Remind me
to use e2fsck -c next time, eh? I think I'm going to mark this as not a bug. If
I happen to run into fs errors in the future, I'll post more info.
My apologies for the false alarm. (Note: it seems that even in read-only mode,
something seems to be locking something on the partition. I can't unmount this
partition if I have the wizard mount it.)

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