Bug 472282

Summary:	Wrong disk order in anaconda grub install
Product:	Red Hat Enterprise Linux 5	Reporter:	Daniel Riek <riek>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED NOTABUG	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.3	Keywords:	Regression
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:	2008-11-19 20:00:13 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 Daniel Riek 2008-11-19 19:36:27 UTC

When booting the installer from a USB stick on a Lenovo X60, X61, or T61 Laptop, anaconda orders /dev/sdb (the usb stick) before /dev/sda (the disk in the laptop) and subsequently installs GRUB to /dev/sdb (the usb stick). The first boot subsequently fails. 

If the order is changed manually in the Advanced options, it works.

This has a high potential do cause high call volume.

Comment 1 Chris Lumens 2008-11-19 20:00:13 UTC

Is this a regression from RHEL4 or from an earlier release of RHEL5?  I'm guessing on RHEL4, as installation to USB devices was first introduced with RHEL5 GA.  This is actually a side effect of supporting installation to USB, as you may very well have a large USB disk that you really do want to install the bootloader to.  We have no way of telling whether something's a large USB disk or a relatively small (and not likely to be frequently attached) USB key.  So, we just have to go with the full support.

If you deselect the USB device as a device to use on the initial partitioning screen, I believe it should get removed as a possibility for installing a bootloader to.

If you really feel this is a significant problem for 5.3, we can add a release note explaining the situation.  However, as far as I know it's been this way throughout the life of RHEL5 and there's not really anything to do about it.