Bug 609651

Summary:	Anaconda picks non-raid device for default boot loader
Product:	Red Hat Enterprise Linux 6	Reporter:	Mike McGrath <mmcgrath>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED NOTABUG	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.1
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-06-30 20:20:31 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 Mike McGrath 2010-06-30 18:44:03 UTC

Description of problem:

I've got a /dev/sd[a-c].  In that I have a partition on sdb and sdc which are raided as /dev/md0 and mounted on my /boot.  Anaconda was attempting to install the boot loader on /dev/sdb instead of /dev/md0

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

Whatever version comes with the RHEL6 beta 2 that launched today.

How reproducible:

Only tested once so far.

Steps to Reproduce:
1.  Create /dev/sdb1 and /dev/sdc1
2.  Software raid them (raid1) at /boot ext4
3.  click next to the boot loader screen.
  
Actual results:

"Install boot loader on /dev/sdb" was displayed

Expected results:

"Install boot loader on /dev/md0"

Additional info:

This was done with a kickstart install but we had the storage section blank so we could do that manually.

Comment 2 RHEL Program Management 2010-06-30 19:03:19 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Mike McGrath 2010-06-30 20:20:31 UTC

Nope, looks like what I thought would work does in fact not work.  The behavior it's showing seems to be correct.