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 77222 - Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Summary: Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-03 16:24 UTC by Matt Dorsch
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-11-03 16:24:34 UTC


Attachments (Terms of Use)

Description Matt Dorsch 2002-11-03 16:24:28 UTC
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 21:00:19 UTC
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.