So I have a UEFI capable motherboard and three hard drives:
- /dev/sda – 256G SSD (MBR)
- /dev/sdb – 230G HDD (MBR)
- /dev/sdc – 512G SSD (GPT)
For historical reasons sda and sdb have MBR partition tables and they are older drives. The sda drive contains a working Windows 7 install which I'm very keen on keeping while sdb contains large data I'm also keen on keeping… Archives and video and the like.
The sdc drive is a new drive I bought and partitioned using the Windows Disk Manager to have half for windows and half for a dual boot linux later on. I wasn't paying attention when I partitioned it and it created a GPT partition table and a Microsoft Reserved Partition. Time passed and sdc now contains a lot of data I'd rather not mess about with and it's time to install that dual boot linux.
As the partition table is GPT, Grub2 wants an EFI System Partition (ESP) at the head of the drive (which is occupied by the MSR) and actually refuses to install.
So my questions are:
- Can I nuke the MSR from orbit to sandwich in the ESP and maybe /boot? My Win7 booted fine before that harddrive was installed so I don't see how it would affect anything.
- If I change my boot order to use UEFI and boot from sdc, it would load grub, will grub be able to chainload from the MBR on sda (keeping sda unmodified)?
(Clarification: I'm not bothered about the space the MSR uses, it's simply in the way for the ESP I would like to get in there so that I can boot)
Best Answer
My problems stemmed from confusion and lack of knowledge. I will try to summarise what I've learned here in the hope that some one finds it useful.
BIOS vs UEFI Hardware
When your power on your computer it has to start executing a program somewhere. Typically this is a ROM on the motherboard that contains a program, for a long time this program was called BIOS and it functioned in specific (somewhat) standard ways. It controlled some hardware features among other things but most importantly it passes control over to an OS on some other media in a well defined manner.
The BIOS "standard" program was later replaced by UEFI which has the same purpose (mostly) and it too has a method of passing control over to an OS on some other media.
BIOS boot
When BIOS boots, it reads the first sector from the primary boot device which is assumed to contain a bootloader and starts executing it. This first sector is called the Master Boot Record (MBR). The disk is assumed to be using the DOS partitioning scheme.
On the old DOS partitioning scheme (also sometimes referred to as MBR) a whopping 446 bytes of program space is reserved for the bootloader in the MBR. Who would ever need more than 446 bytes amirite? So larger bootloaders typically make use of a "feature" of the DOS partitioning scheme where there is around 1-2 MBs or so of unused space immediately following the MBR. The bootloader would have a "stage 1" and "stage 2" where stage 1 is stored in the MBR and simply loads stage 2 which is stored in this "unused" area.
UEFI boot
When UEFI boots it assumes that the primary boot device is using GPT, and looks for a partition with a specific type, namely: "EFI System Partition". This partition is assumed to FAT 12,16 or 32. Once found, it scans the partition for bootloaders by looking for files with names that end in
.efi.I found that in the context of installing grub, the texts I read were referring to the UEFI boot procedure as simply UEFI, and BIOS boot procedure as BIOS. Which was confusing as I thought they were talking about the actual software on the motherboard ROM.
At any rate an UEFI motherboard can still perform a BIOS boot procedure, typically called "Legacy Boot" or CSM in the UEFI settings.
GPT and DOS/MBR
While GPT differs greatly from the old MBR/DOS partitioning scheme, it has reserved the region where the bootloader on an MBR partitioned disk would reside. This means that you can install a "legacy" bootloader into this reserved space on GPT and use BIOS boot. However there is a caveat, remember that stage 1/2 thing? Yeah GPT doesn't have that "feature" and the reserved region is still only 446 bytes. So to house the stage 2 of the bootloader a special partition type was introduced: "bios_boot". So the bootloader has to be aware that it is being installed on a GPT disk and find the "bios_boot" partition and put it's stage 2 there and let stage 1 find this partition somehow.
Summary
So there are three ways you can boot:
UEFI boot + GPT
Create a partition to hold the bootloader(s), 100 MB or so should be more than enough, set it's type to "EFI System Partition", format it with FAT 12,16 or 32. Mount it somewhere, typically
/boot/efi. Then tell grub to install an EFI loader:grub-install --efi-directory=/boot/efi.UEFI boot should find the partition by looking at the partition table.
I am told that you can use the ESP for your '/boot' as well but I haven't tried.
BIOS boot + GPT
Create a partition to hold stage 2 of the loader, 1-2 MB typically, and set the type to "bios_boot". You do not need to put a filesystem on this partition or to mount it, grub will "own" it do the what it needs. The position of this partition on the disk should be irrelevant. Then install grub on MBR as usual
grub-install /dev/sdx. Grub should detect that it is a GPT disk, find the bios boot partition (and complain if it doesn't!) and install the appropriate stage 1 and stage 2.BIOS boot + MBR
Simply create a DOS partition scheme on your disk and use
grub-install /dev/sdxto write the MBR, the bios boot partition is not needed.Chain loading secondary drive with MBR from primary drive with GPT
So I found out that grub doesn't allow chain loading a BIOS bootloader from an UEFI bootloader for whatever reason. I personally don't see why it wouldn't be possible but at least grub doesn't seem to support it.
So to fix my issues I set my GPT drive as primary boot device in UEFI settings, then use BIOS boot to load grub from the GPT device as above. Which means that it is able to chain load Win7 from the MBR on the first disk.