Bug 430620

Summary: anaconda sets up wrong disk in grub
Product: Red Hat Enterprise Linux 5 Reporter: Chris Pepper <pepper>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.1CC: hdegoede
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: 2009-11-30 11:06:22 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 Chris Pepper 2008-01-29 04:56:44 UTC
Description of problem:
I have 2 disks: sda & sdb. I kickstarted RHEL5.1 onto sda successfully:
bootloader --location=mbr --driveorder=sda --append="text console=tty0 console=ttyS0"
ignoredisk --drives=sdc,hda,hdb
part /boot --onpart=sda1 --fstype=ext2
part /     --onpart=sda2 --fstype=ext3
part swap  --onpart=sda3 --size=2048
part /var  --onpart=sda5 --fstype=ext3
part /home --onpart=sda6 --noformat

After completing configuration and patching, I kickstarted a fresh install onto sdb, for comparison:
bootloader --location=mbr --driveorder=sdb --append="text console=tty0 console=ttyS0"
ignoredisk --drives=sdc,hda,hdb
clearpart --all --initlabel --drives=sdb
part /boot --ondisk=sdb --fstype=ext2 --size=256  --asprimary
part /     --ondisk=sdb --fstype=ext3 --size=8092 --asprimary
part swap  --ondisk=sdb               --size=2048 --asprimary
part /var  --ondisk=sdb --fstype=ext3 --size=32768
part /home --ondisk=sdb --fstype=ext3 --size=100 --grow

But the second installation configured grub to use (hd0,0), even though it hadn't actually installed Linux there:
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ text console=tty0 console=ttyS0 rhgb quiet
	initrd /initrd-2.6.18-53.el5.img


Modules like network drivers failed to load, perhaps because of this -- I got lots of these in /var/log/messages:
Jan 28 23:07:12 pe modprobe: FATAL: Could not load /lib/modules/2.6.18-53.1.4.el5/modules.dep: No such file or 
directory 



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

How reproducible:
Kickstart onto sda; then kickstart onto sdb.

Steps to Reproduce:
1.Kickstart onto sda.
2.Kickstart onto sdb.
  
Actual results:
grub uses sda (hd0,0).
System looks for modules in lib/modules/2.6.18-53.1.4.el5/, which does not exist.

Expected results:
grub should use sdb (hd1,0), which it's just installed.
The just-installed modules should be loaded from /lib/modules/2.6.18-53.el5/.

Additional info:

Comment 1 Chris Pepper 2008-01-29 05:42:47 UTC
Clarification -- the first problem is due to the way anaconda creates grub.conf (referring to hd0,0 when 
installing onto hd1,1).

The second issue is because anaconda writes the MBR on the specified drive, but if that is not the default 
boot device this is not actually used. If anaconda is writing to a secondary (never used) MBR, it should 
warn the user that manual intervention will be required, either to use this MBR, or to configure the 
*active* MBR to boot to the RHEL being installed.

Comment 2 Hans de Goede 2009-11-30 11:06:22 UTC
With the "--driveorder=sdb" you are telling anaconda, that your BIOS boot order is first sdb, then sda. Grub harddisk numbers refer to BIOS harddisk numbers, so you are telling anaconda that:
sdb == hd0
And therefor that:
sda == hd1

And you are getting exactly the grub.conf that you ask for. Note that we
also write a device.map to tell grub about:
sdb == hd0
sda == hd1

So yes if you pass "--driveorder=sdb" the mbr will get written to the sdb disk,
as you've told us that that is what the BIOS will boot from.

Comment 3 Chris Pepper 2010-03-22 14:43:26 UTC
Then is it impossible to create a configuration that can boot from sdb, with or without sda online? Sorry, I thought I was specifying a preference to boot from sdb, but now it sounds like perhaps I cannot have an sdb configured so it will work as a backup either way.

Comment 4 Hans de Goede 2010-03-22 14:55:56 UTC
(In reply to comment #3)
> Then is it impossible to create a configuration that can boot from sdb, with or
> without sda online? Sorry, I thought I was specifying a preference to boot from
> sdb, but now it sounds like perhaps I cannot have an sdb configured so it will
> work as a backup either way.    

The problem is in the:
"with or without sda online?"

Part of your wishes. To use sdb as a backup, when sda is "gone" what you did
will work. As once sda is removed from the system sdb becomes the first bios drive (drive "80" in bios terms, hd0 in grub terms) and all is well.

But when you are chainloading from sda's mbr sdb, is drive 81 / hd1, yet its grub is configured to look at hd0 -> fail.

And if you configure its grub to look at hd1, then things will fail when sda
is removed from the system, as now it is hd1. So for your purposes of having a backup installation ready to boot, what you did is correct, but to test this while sda is still in the system, you need to change the harddrive order in the BIOS (most modern BIOS's allow this). You cannot test this using chainloading.

I hope this helps / clarifies, if not keep asking always happy to help.

Regards,

Hans
\