Grub on 2nd disk, /boot partition
Yuan Liu
This is a Compaq Presario using a BIOS I've never seen. (I used another
Presario that used Pheonix, and tons of other BIOS') Anyway, it has two
ATA100 ports; one hooked up with a CD-RW and a DVD, whatever they do,
the other had an IDE drive shipped. I don't want to fips the Windows
main partition because it's NTFS (shipped with Win XP pre-inst), so I
bought another IDE drive. I used the default "cable select" jumper
settings. So after booting up, the BIOS detected the second drive, and
decided it's #2.
Now I went on to install RedHat 7.3 on the 2nd drive, which was
identified as /dev/hdb. As is RedHat way, a /boot partition is created
on /dev/hdb1. I asked it to install GRUB on the boot sector of the
/boot partition instead of /dev/hda's MBR. (/dev/hda is Windows,
remember. It didn't give me a choice to install on /dev/hdb's MBR.
From the very early LILO days I'm wary of overwriting MBR's on my own
systems although I did this for my clients sometimes.)
In order to boot from /dev/hdb1, or (1,0) in GRUB convention, I have to
change boot option in BIOS. Unlike many others, it lists the 2 IDE
drives, showing the first to be bootable and second to be non-bootable.
It also allows a toggle to set the second to be bootable; in this
case, the first would be non-bootable. I thought this would allow GRUB
to do its job and selectively boot Linux or Windows.
However, after this change, the BIOS system check will pass and the prompt
GRUB
will appear on my screen. Then nothing. I don't get the ">" prompt,
can't type anything, ... The only thing I can do is to cycle power. If
I change BIOS to let the first drive boot, Windows will boot OK. This
experience made me even more nervous to install GRUB to the first
drive's MBR.
I then tried to change grub.conf to use (0,0) instead of (1,0) to see if
the BIOS change made the second drive first. (I made a boot diskette and
fooled around grub shell to reinstall grub.) Nope. Just the silent
GRUB
and nothing.
I think there's a possibility that I swap the IDE cable connectors so my
new drive becomes first and use GRUB to fool Windows into thinking that
it is still using the first drive. But that'll be a bit of sweat, and I
don't understand why GRUB would not function out of the 2nd drive
(sometimes known as a slave drive), non-MBR. If BIOS allows boot from a
slave, what's wrong with that? (I also checked that /dev/hdb1 was active.)
Have read though many google results and several GRUB-related posting
from newsgroups. Still couldn't figure out. Thanks for enlightenment.
Yuan Liu
Drydd
than the Primary Master will actually swap I/O addresses and
interrupts (gotta love plug and pray) around so that the selected boot
device actually functions for all intents and purposes as the primary
master. It could very well be that GRUB is looking at the wrong drive
for boot information after that change is made.
Restart the machine with a boot disk and fiddle around with
fdisk to see which drive is showing up as /dev/hda now. Honestly
though, a "real" hardware solution will be more reliable in terms of
compatability with anything written to interact with the BIOS
directly, so I'd just switch the drives around on the cable and call
it a day.
Yuan Liu
> A lot of times a BIOS that allows booting from a driver other
> than the Primary Master will actually swap I/O addresses and
> interrupts (gotta love plug and pray) around so that the selected boot
> device actually functions for all intents and purposes as the primary
> master. It could very well be that GRUB is looking at the wrong drive
> for boot information after that change is made.
Exactly (except I can't see how I/O ports and interrupts are used during
boot up) and thanks, Drydd. Further more, the fix is a little far
reaching. Just in case someone else uses this BIOS (the EPROM set-up
program only says the setup program belongs to Compaq, no identification
of the BIOS at all) and a second disk, here's the deal (after a
sleepless night, a whole series of trial and error, and a bit of good luck):
True, the BIOS assigns the boot device, whatever it actually is, as the
1ST drive (hd0 under GRUB), but only during bootup. Immediately after
boot loader, however, it tells the truth. So the trick is to install
(setup) GRUB while in bootup state.
I haven't figured out any other way to perform this trick but to create
a GRUB floppy, itself a tricky job on my system, then "setup" GRUB to
hard disk. So here are the steps:
1. Modify the GRUB configuration created for you during installation.
(It doesn't matter if you assigned 1st or 2nd disk as bootable before
your CD-based installation; GRUB, under Linux, will always happily see
your GRUB root device as 2nd drive.)
The original device.map would look something like this:
$ cat /boot/grub/device.map # wrong
(fd0) /dev/fd0
(hd0) /dev/hda
(hd1) /dev/hdb
$
It is important to "swap" between hd0 and hd1, so your final device.map
would be:
$ cat /boot/grub/device.map # correct - during bootup anyway
(fd0) /dev/fd0
(hd1) /dev/hda
(hd0) /dev/hdb
$
The original grub.conf would look something like this:
$ cat /boot/grub/grub.conf # wrong
default=0
timeout=10
splashimage=(hd1,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-4)
root (hd1,0)
kernel /vmlinuz-2.4.18-4 ro root=/dev/hdb5 idebus=66
initrd /initrd-2.4.18-4.img
title Red Hat Linux (2.4.18-3)
root (hd1,0)
kernel /vmlinuz-2.4.18-3 ro root=/dev/hdb5 idebus=66
initrd /initrd-2.4.18-3.img
title WinXP
rootnoverify (hd0,0)
chainloader +1
$
Instead, it should be:
$ cat /boot/grub/grub.conf # correct - for bootup anyway
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-4)
root (hd0,0)
kernel /vmlinuz-2.4.18-4 ro root=/dev/hdb5 idebus=66
initrd /initrd-2.4.18-4.img
title Red Hat Linux (2.4.18-3)
root (hd0,0)
kernel /vmlinuz-2.4.18-3 ro root=/dev/hdb5 idebus=66
initrd /initrd-2.4.18-3.img
title WinXP
map (hd1) (hd0)
rootnoverify (hd1,0)
chainloader +1
$
Note how we have to swap hd0 and hd1 before chainloading Windows. The
order of the map IS important. Additionally, note we are NOT changing
the way Linux looks at the world, so /dev/hdb5 remains /dev/hdb5; it's
not becoming /dev/hda5. Also note that I'm using RedHat's /boot
partition convention, so every path is relative to /boot. (The
auto-generated grub.conf file contains sufficient comments.)
Needless to say, Step 0 is to boot your system using either the boot
diskette you created during Linux installation or the rescue mode from
the installation CD.
Warning: Don't think you can setup GRUB on the hard disk using the
"correct" configuration. It ain't work.
2. Create a GRUB floppy. I tried to follow cautions in GRUB info and
FAQ's and tried all alternatives other than using grub-install. dd
stage1 and stage2 to /dev/fd0 resulted in a GRUB"able" diskette but it
displays "geometry error" and couldn't find stage2. "setup" (/sbin/grub
--batch --device-map=/dev/null <<EOT, and several variants) under e2fs
resulted in exactly the same problem as on the hard disk: a hung "GRUB
". (At least by following the advice that only stage1, stage2, and
grub.conf needs be on floppy; without stage15, it seems, stage2 is in
jeopardy. I haven't tried to copy stage15 to the floppy then run setup.)
The only successful installation of GRUB on the floppy is by
$ /sbin/grub-install --stage2=/boot/grub/stage2 (fd0)
You can add -p /grub/grub.conf. (Don't sniff at the $ prompt; for
reasons beyond my comprehension, RedHat allows an ordinary user to
easily access floppy - even to reboot under this prompt:-(
Trust me, I also tried to grub-install to hard disk. This results in
the same hanging "GRUB " because under Linux, my 2nd drive is still 2nd.
You gotta run setup without OS. That is, while BIOS is lying.
2. Run GRUB from the floppy. If you are (un)lucky like me so
grub-install assumes -p /boot/grub/grub.conf (a file path non-existent
to GRUB the boot loader), you'll fall into the
grub>
prompt. Otherwise, you'll get to your configured GRUB menu. I
seriously suggest that you don't run that menu, which ; instead, press
"c" to fall back to command mode. From here, you can grind your grub
skills using "root", "kernel", "boot" commands to boot into the
installed Linux system.
3. The one more important skill to grind is "setup". First, confirm
your GRUB root device (not to be mixed with your Linux root partition):
grub> find /grub/stage1
(hd0,0)
grub>
It is hd0 because BIOS temperarily assigned the 2nd disk as 1st; I used
/grub/xxx instead of (the presumably more standard) /boot/grub/xxx
because RedHat by default sets aside a /boot partition and I'm a happy
follower.
4. Run setup before BIOS changes its mind:-)
grub> root (hd0,0)
grub> setup --prefix=/grub (hd0,0)
...
... sucessful
grub> reboot
Note we use --prefix=/grub because of the /boot partition. This ensures
that the -p parameter setup passes to install is correct. Also note
that I'm setting up to (hd0,0), the boot sector of the 1st partition on
that drive; if you really like the (more popular) MBR solution, go with
(hd0). The last "reboot" command is just to save your power button.
(I'm not sure if this command actually reboots; it hung my system so I
had to recycle power.)
Here, I assume you've already changed the BIOS to make your 2nd drive
the bootable one.
Though lots of sweat (and deprivation of sleep, fast), this is good
experience. I think GRUB has some way to go to deal with diverse BIOS'
and disk configurations before it reaches R1. Keep your fingers crossed.
Final note: Looking back, it is possible that if I trusted GRUB to
install to the MBR of my "master" drive, I would have saved the trouble.
But hey, what's the fun? A feature is a feature.
And by this, I call it a day:-) Thanks again, Drydd.
Yuan Liu