Re: Grub rescue

[Chris Murphy]

On Mar 27, 2013, at 2:01 PM, David WE Roberts <address@hidden> wrote:
> 
> We seem doomed to exchange messages but completely fail to communicate.

Well you're being stubborn too, you have to admit that. I've lost count of how 
many questions people have asked you that you don't answer.

> Throughout all of this grub *always* boots from the MBR on /dev/sda.

OK and that is a BIOS issue. The BIOS is responsible for determining what drive 
it looks to first, it blindly executes the first 446 bytes of code in LBA 0. In 
the case of GRUB that code usually just forwards loading to core.img found in 
the MBR gap, which contains a prefix for /boot/grub. Normally this is all on 
the same disk. That I know works whether MBR or GPT, without having to specify 
modules. It just works.

> As Jordan has said, if when you run 'grub-install' the location of /boot/
> grub is on a GPT disc then "part_gpt" will be included in core.img.
> 
> If the location of /boot/grub is on an MBR disc then 'part_msdos' will be 
> included in core.img.
> 
> The initial job of 'core.img' is to get itself up and running and then 
> locate the partition where /boot/grub resides and it can then proceed to 
> load all the additional modules and set all the variables it needs to get 
> ready to boot a variety of OS, and then present the user with a menu.
> 
> The copy of 'core.img' stored in the MBR is a pared down version because 
> of the lack of available space and the restricted environment it starts in.
> 
> Once it has found /boot/grub it can then flesh itself out with all the 
> other modules it needs such as for example NTFS support.

OK the part you're missing? Is your CSM-BIOS is apparently the limiting factor. 
I haven't ever heard of a CSM that only sees one disk. But yours seems to be 
doing that, as the ls command at the rescue prompt shows only one disk. If 
that's always true, you will not be able to have a split GRUB bootloader setup. 
GRUB boot.img, core.img, and /boot/grub will have to be on one disk. And 
further, you'd have to put the /boot volumes on that disk also, for Windows, 
and whatever Linux volumes you have. Because GRUB isn't going to find a boot 
volume on a drive the BIOS isn't admitting exists. Once the kernel takes over, 
it will see the other drives, so you can have rootfs on other drives. Windows 
and Linux support such setups.

As an example of EFI CSM's not behaving like a full BIOS: Apple's EFI CSM can 
see and boot from multiple disks, but there's no UI. The CSM determines the 
boot order, looks at the first drive for boot code in the MBR - if it's there, 
it executes it. Period. User doesn't get a choice. To get GRUB, or any boot 
loader, to load itself from another disk, I first have to zero the first 440 
bytes on LBA 0 on the first disk. In effect, only one disk can have code in the 
MBR bootstrap region. However, whether grub rescue or grub shells, the ls 
command displays all disks and all of their partitions, both MBR and GPT.

So I think you need to learn more about your CSM-BIOS, possibly blow away some 
MBR bootstrap code regions so you can figure out what disk the bootloader is 
coming from, and whether GRUB really only sees one disk at a time no matter 
what. Or you go down the UEFI rabbit/rat hole.

Chris Murphy