Bug 97884 - badblocks reports no partition header during RHR run, parted and badblocks say it's fine afterwards
Summary: badblocks reports no partition header during RHR run, parted and badblocks sa...
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 2.1
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-23 17:42 UTC by Glen A. Foster
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-22 23:34:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Glen A. Foster 2003-06-23 17:42:54 UTC
Description of problem: During a Red Hat Ready self-certification test on an
Everest (HP rx5670) server, an error was reported in the FDISK (fixed disk)
section -- in particular, "/dev/hdd does not contain a valid partition header".
 I got this error 5 times from badblocks (as expected, per the RHR certification
requirements), yet at the end of the run I tried running both parted and
badblocks on /dev/sdd and they report it's _fine_... (I did nothing to the disk
drive to cause any change in behavior, not even rebooting).

Version-Release number of selected component (if applicable):
# rpm -q kernel-smp e2fsprogs parted

How reproducible: not sure, only happened this one time AFAIK

Steps to Reproduce:
1. RHR certification run on HP rx5670 4-way, 96GB RAM, 27 drives and a lot of
separate I/O cards (list available upon request)

Additional info: I'm copying Larry Troan on this because I'd really like to not
have to re-run this certification test; it'll tie up the Everest for another 6
days and we need to test other, newer alpha-cuts from Red Hat on that system.

Comment 1 Glen A. Foster 2003-07-22 23:34:47 UTC
Looks like a 1-time thing, cannot reproduce; closing.

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