On Wed, 16 Apr 2008, John Summerfield wrote:
Ben wrote:
On Tue, 15 Apr 2008, solarflow99 wrote:
It would also be possible to install grub on the other drive manually if
that is good enough, I have the grub commands if you need.
That's helpful, thanks... but I'd still like to know why it's choosing
the MBR of sdb over the one on sda!
I did a manual install to a dc7700. Here is the relevant section from
anaconda-ks.cfg
bootloader --location=mbr --driveorder=hda,hdc --append="pci=nomsi,nommconf
vga=794 rhgb quiet"
[...]
Yeah, my bootloader line was of the form
bootloader --location=mbr --driveorder=sda
Maybe I should have added ",sdb" to the end?
Now, the drive names _might_ be signficant. So might the fact that the
bootloader line lists two drives.
That's perhaps my thinking. But here's a twist:
I set up two RAID1 arrays. Array one contained disks 0 and 1, array two
contained disks 2 and 3. That was also the order in which I created them.
Pre OS-installation the LSI BIOS listed "Array 1 of 2" as the one containing
disks 0 and 1 and "Array 2 of 2" as having the other pair. "Scan Order" was
listed as "0" for the RAID1 array with disks 0 and 1, and "2" for the second
array. I'm assuming these were (SCSI?) ID numbers (see below).
I did a RHEL5.1 install where the kickstart contained no reference to
partitioning sdb at all. Indeed, I added sdb to the "ignoredisk" line. The
bootloader line was as above (with no sdb reference). Post installation the
OS reported that sda was the only mounted disk and it contained /boot, / and
swap. So far, so groovy.
dmesg reported (snipped for brevity):
[...]
sd 0:1:2:0: Attached scsi disk sda
sd 0:1:0:0: Attached scsi disk sdb
[...]
Which already seems to indicate the ID numbers have been switched around.
I'm looking at the third number in each line (2 and 0). A link with "Scan
Order"?
Within the booted OS I did:
fdisk /dev/sdb (for one full, primary disk partition)
mke2fs /dev/sdb1 -j
edited fstab for /dev/sdb1 and then
mounted it as /VM-storage
All was well. Or so it seemed...
I then rebooted the box and GRUB failed to appear. ONLY after I had gone
into the AMI BIOS (remember this is a Sun x4200 M2) and swapped the boot
order for hard drives thusly:
Boot->Hard Disk Drives
1st Drive [SCSI:#8610 ID02 LU]
2nd Drive [SCSI:#8610 ID00 LU]
(Note that ID00 was first before now and the box booted correctly)
... did GRUB re-appear and the box booted correctly again. This is, to put
it bluntly, fucked up. It seems that while there's no partition table on
sdb (SCSI ID 0 according to the AMI BIOS and dmesg, but "Scan Order 2" in
the LSI BIOS) the AMI BIOS doesn't try to look at the MBR on it and moves
straight to sda (SCSI ID 2 according to the AMI BIOS and dmesg, but "Scan
order 0" in the LSI BIOS) and reads that valid, GRUB-containing MBR. If
there's a valid partition table on sdb it tries to read the MBR on that
(which is empty) and just hangs instead.
Going back into the LSI BIOS it appears now that "Array 1 of 2" is the one
that contains disks 2 and 3 and "Array 2 of 2" is the one containing disks 0
and 1. Yet still they have a "Scan Order" (_does_ this mean SCSI ID?) of
"0" for the array with disks 0 and 1 and "2" for the array with disks 2 and
3.
To add insult to injury after another reboot the AMI BIOS hard drive boot
ordering has changed back to putting ID00 first thus rendering the box
unbootable until I go in and change it, again. Why this setting isn't
sticking I don't know.
Someone, please tell me what blatantly obvious stupidity I'm missing?
Should I try creating the second array first in the LSI BIOS before
installing?
Should I try adding "sdb" to the end of the bootloader --driveorder
directive?
Should I go and stick my head in a pig?
Any useful suggestions appreciated!
Ben
--
Unix Support, MISD, University of Cambridge, England
Plugger of wire, typer of keyboard, imparter of Clue
Life Is Short. It's All Good.
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
