Red Hat Bugzilla – Bug 430620
anaconda sets up wrong disk in grub
Last modified: 2010-03-22 10:55:56 EDT
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"
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"
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:
title CentOS (2.6.18-53.el5)
kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ text console=tty0 console=ttyS0 rhgb quiet
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
Version-Release number of selected component (if applicable):
Kickstart onto sda; then kickstart onto sdb.
Steps to Reproduce:
1.Kickstart onto sda.
2.Kickstart onto sdb.
grub uses sda (hd0,0).
System looks for modules in lib/modules/2.6.18-53.1.4.el5/, which does not exist.
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/.
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.
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.
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.
(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.