On Mar 27, 2013, at 2:01 PM, David WE Roberts <[email protected]> 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 _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
