Bug 50988

Summary: Grub sometimes put on wrong disk for RAID configs
Product: [Retired] Red Hat Public Beta Reporter: Christopher Barton <cpbarton>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: roswell   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-07 15:47:56 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 Christopher Barton 2001-08-06 05:01:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
Anaconda tends to put the disks for the /boot md device in the wrong order 
in /etc/raidtab.  Grub is then installed on raid-disk 0 (not /dev/hda, in 
some cases) & the machine can't boot.

How reproducible:
Sometimes

Steps to Reproduce:
1. Place /boot on an md device, RAID1	

Actual Results:  System is sometimes unbootable.  Suppose /dev/md2 
contains /boot.  Anaconda tends to generate this (apparently bad) entry 
in /etc/raidtab:

raiddev             /dev/md2
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hde1
    raid-disk     0
    device          /dev/hda1
    raid-disk     1

Grub is subsequently installed on (hd1,0)

Expected Results:  /etc/raidtab should probably always list /dev/hda as 
raid-disk 0:

raiddev             /dev/md2
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda1
    raid-disk     0
    device          /dev/hde1
    raid-disk     1

Additional info:

This happened twice, on two seperate roswell installs.  Generally it 
happened when I started with no partition tables, but I have no recipe to 
reproduce this one.

It happened 50% of the time for me (2 out of 4).  Linux (grub, really) was 
subsequently unbootable.

Comment 1 Glen Foster 2001-08-06 22:53:21 UTC
We (Red Hat) really need to fix this defect before next release.

Comment 2 Jeremy Katz 2001-08-07 16:34:04 UTC
Fixed in CVS so that we make sure that raid members are always sorted