Bug 74463

Summary: Installer doesn't recognize PDC20276 ATA133 RAID controller, fails to boot after install
Product: [Retired] Red Hat Linux Reporter: Need Real Name <spoke>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED DUPLICATE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:49:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2002-09-24 20:31:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Description of problem:
I'm having some trouble installing and booting null on my system. Here are the
relevent specs:
Gigabyte GA-7VAXP motherboard (product page:
http://www.giga-byte.com/products/7vaxp.htm)
2x40Gb Maxtor DiamondMAX ATA133 drives plugged into the first RAID channel and
configured as an 80Gb RAID-0 array. Drives currently run an OS, which sees it as
one 80gb drive. The drives enumerated as /dev/hde and /dev/hdf by the null
installer.
A CD writer as the primary master of the first non-raid ATA133 channel,
enumerated as /dev/hda
A 10Gb Quantum Fireball drive as primary slave on the same channel, enumerated
as /dev/hdb

When anaconda reaches the partitioning phase, I get two warnings about
unknown/corrupt partition tables on /dev/hde and /dev/hdf (the RAID drives).

My options are to rewrite the partition tables or ignore the problem. Seeing as
my main OS and data are on those drives, I choose ignore rather than have the
data destroyed. After all, I intend to install null on a drive at /dev/hdb and
not the RAID array.

The install continues on as if the raid drives don't exist, which is fine by me.
I won't even need to access the array from null anyway.

/dev/hdb partitions and the install seems to work fine. When I reach the point
of installing a bootloader, I opt not to (the machine boots off the RAID array
and I can't put it there since the installer has to either ignore or destroy the
data on the drives). I have a boot disk made instead, but I can't boot off it.
The boot process dies before the image is even half read with an "Unable to load
image" error.

I decided to redo the whole install and use a fresh floppy, but I encountered
the same errors during the install and the same problem booting off the floppy.

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


How reproducible:
Always

Steps to Reproduce:
1. On a Gigabyte GA-7VAXP with a 2-drive RAID array set up and another drive on
a non-raid channel, install to the non-raid drive.
2. Anaconda will display error messages concerning the 2 RAID drives having
invalid partition tables and ask you to either rewrite them or ignore (one error
message for each drive, as if they were not a RAID array). Ignore both so you
don't destroy the data on them.
3. Do not install a bootloader.
4. Make a boot floppy.
5. Attempt to boot off the floppy and it will fail.
	

Actual Results:  Boot process dies while the floppy kernel image loads.

Expected Results:  Linux should boot. :-P

Additional info:

Comment 1 Jeremy Katz 2002-10-02 22:05:09 UTC
We don't currently support installing to drives using the "hardware" raid
features of the Promise ataraid controllers due to the fact that you can't
really tell the difference between a user using the "raid" functionality or
using individual disks.

Comment 2 Need Real Name 2002-10-03 01:44:35 UTC
That's certainly interesting and I wonder if Promise would be forthcoming with
more details about how their RAID controller works... but you seem to have
misread. I was not trying to install to the RAID drives.

I was trying to install to a drive on a plain ATA133 controller and don't really
mind if the OS can't figure out how to read the striped data on the RAID drives
(though it would be nice), so long as it boots.

Comment 3 Jeremy Katz 2003-01-27 22:46:59 UTC
Marking duplicate of my bug on the subject for consolidation purposes

*** This bug has been marked as a duplicate of 82848 ***

Comment 4 Red Hat Bugzilla 2006-02-21 18:49:40 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.