Re: Booting GRUB on a drive other than (hd0)

[cr]

On Wed, 31 Dec 2003 07:03, Derek Scherger wrote:
> Hi folks, I have a question relating to the following line in the GRUB
> manual from the Installing GRUB Natively section:
>
>       If you install GRUB into a partition or a drive other than the first 
> one,
> you must chain-load GRUB from another boot loader. Refer to the manual for
> the boot loader to know how to chain-load GRUB.
>
> Does this simply mean that I need something in the MBR that will look for
> the active partition where I have GRUB installed so that it is loaded and
> executed? Some clarification in the manual would be most helpful here.

Grub installs in two parts, IIRC - a 512-byte Stage 1 (usually in the MBR of 
the active drive) that points to the much bigger Stage1.5 or Stage2 in a 
location of your choice.

If Stage1 *isn't* in the MBR of the first (active?) hard drive, then the BIOS 
won't find it unless some other bootloader redirects the system to the right 
location.   However Grub Stage 1 is *usually* put in /dev/hda so the above 
doesn't apply.


> I've been trying to get GRUB installed on my second drive (hd1) and it's
> very close to working but it seems that the BIOS tells GRUB that it is
> starting from (hd0) even though it's jumpered to be the primary slave
> device. This leaves GRUB thinking that the root device is (hd0) when it
> really should be (hd1).
>
> I've tried a couple of different things like map (hd0) (hd1) and map (hd1)
> (hd0) to see if I can fix the problem but one of two things happens. Either
> GRUB can't find files because they're on (hd1) which it thinks is (hd0) or
> it hands off some bad info to the linux kernel which panics when it tries
> to mount the root filesystem, presumably because it's looking on the wrong
> device. 

This is a sure sign that the Linux kernel is indeed looking in the wrong 
place.    

See my comment at the end.

> This is late enough in the linux boot process that it has reported
> about drives and partitions and it still sees hda as the primary master and
> hdb as the primary slave.
>
> What I'm wondering is the following:
>
> (1) Is it possible to get this to work with GRUB on the primary slave with
> the BIOS configured to boot from that device first and if so what is
> required?
>
> (2) Would GRUB be better off looking at the hardware more like the linux
> kernel does to determine the real identity of the drives so that it gets
> (hd0) and (hd1) right? I don't know how the kernel does this but it's
> clearly possible to do. Once GRUB stage1 is running does it really care
> which device it was booted from since this seems like it may almost always
> be (hd0) even when it shouldn't be? It seems to me (without knowing much
> about the internals of the kernel or GRUB) that what's really needed at
> this point is knowledge about the actual drive configuration and where the
> kernel to be booted lives, i.e. (hd1) in my case. As a follow on to this
> I'm also wondering whether the real root device is identifed or coded into
> the GRUB boot record or whether GRUB simply uses whatever device the BIOS
> has told it to use. Would this be possible to add as a configuration
> option, to hard code the root device, rather than relying on the BIOS to
> determine it?
>
> Thanks for any info...
>
> Cheers,
> Derek


Your Grub menu.lst file needs an entry something like this:

title           Debian GNU/Linux, kernel bf2.4   on  /hdc1
root            (hd1,0)
kernel          /boot/vmlinuz-2.4.18-bf2.4  root=/dev/hdc1  hdb=ide-scsi  ro


In the above, 'title' can say anything I like.
The 'root (hd1,0)' tells Grub to make /dev/hdc1 the current root partition.   
(On my system, hda is a IDE drive which Grub calls hd0, hdb is a IDE CD-ROM 
which Grub ignores, so hdc = hd1 in Grub terms).
Then 'kernel' looks for and loads the vmlinuz kernel at 
/dev/hdc/boot/vmlinuz....
In the 'kernel' line, note the 'root=/dev/hdc1'.   This has nothing to do 
with Grub's 'root', it's just a parameter Grub passes to the Linux kernel.   
It could say 'root=/bananas' and Grub wouldn't care.    However, the Linux 
kernel needs it because otherwise Linux will assume it's living on /dev/hda1 
(I think), hence the 'kernel panic' when it can't find itself.


Where does menu.lst live?   In the same directory with the other Grub files, 
e.g.  (on my system)   

address@hidden:/W98/boot/grub$ ls
e2fs_sta.5  jfs_stag.5  menu.lst    stage1      xfs_stag.5
fat_stag.5  minix_st.5  stage2  ffs_stag.5  reiserfs.5  vstafs_s.5

('W98' is what I have  /dev/hda1 mounted as - yep it's a FAT16 partition full 
of Windoze.   Makes no odds to Grub as long as it can find its files.)

If I ever give my Windoze drive (hda) the flick, or shuffle drives around, 
I'll just have to reinstall Grub.

When (re)installing Grub, if installing Stage1 from within Grub (e.g. using a 
boot floppy rather than Linux grub-install), then  (using the example in the 
manual) 

root = (hd0,0)   tells Grub to make /hda1 the current root partition (where 
the Grub files are)
find /boot/grub/stage1   will locate the Stage1 file that Grub needs to....
setup (hd0)      ... copy to the MBR of /hda (and I think, in the process, 
Grub sets Stage1 to point to /hda/boot/grub/stage2)

Hope this helps and I haven't been too confusing (or, worse, misleading)  :)

cr