Mixing UEFI and MBR

As mentioned in an earlier post, I recently took the hard drive from an older MBR based system, and installed in a newer UEFI box.  Opensuse 12.3 was already installed on the older system, set to boot with grub2 and booting from the partition boot record in “/boot”.  I now wanted to use it in the UEFI box without reinstalling.

One way of booting the older disk would be to disable secure boot in the UEFI firmware, and make sure that legacy BIOS support is enabled.  Then, using the BIOS boot menu (hit F12 during boot on this box), I could select to boot the older system.  That works (or worked – perhaps it doesn’t work now).  But I wanted to boot as a UEFI system.

It turns out that there were no huge problems in doing this.  So perhaps this will be a boring post.

First success

My first successful boot was with the older disk installed in a disk enclosure, and accessed with a USB.  I went into more detail in that earlier post.  Some of the steps there were because of the USB access.  Once I installed directly into the system, instead of by USB, the complications disappeared.

What worked was this:  I already had another opensuse installation on the UEFI box.  I ran “grub2-mkconfig” on that installation, and it added a boot entry for the linux system on the older disk.  As a technicality, I did have to decrypt the LVM and make it accessible, before the opensuse system on the older disk was visible to grub2-mkconfig.

The result was that, although I had installed the system for MBR booting, I was now booting it with the grub2-efi from my other install on that box.

This turns out to cause no problems whatsoever.  Currently running from that older disk, there is no “/boot/efi”, and Yast thinks it is using grub2, not grub2-efi.  However, in other respects it works like a UEFI install.  In particular, the command “efibootmgr” works.  Without options, it displays basic boot information for the box.  It (efibootmgr) does not list the system I am running as a boot choice, but that does not matter as long as the grub boot menu provides access.

Any update to grub will presumably cause grub2 to be reinstalled in the partition boot record of my “/boot” partition, and not actually affect the UEFI boot setup at all.  I could presumably go into Yast bootloader settings, and tell it to not use a bootloader.  For reasons mentioned below, I won’t actually do that.

Using configfile

There’s one downside to booting linux this way.  If a system update requires a boot configuration change, I will have to boot into my other opensuse install, and rerun “grub2-mkconfig” there.  For example, I would need to do that after a kernel update.

A simple solution to this problem is to use “configfile” in the grub2 configuration.  Editing the grub configuration (actually “/etc/grub.d/40_custom”) on the UEFI installed system where I was running grub, I added the lines:

### Entry to boot opensuse on sdc1
       menuentry "configfile for opensuse on /dev/sdc1"  {
       set bootdir='hd3,gpt1'
       search --fs-uuid --set=bootdir 05c50aaa-7233-46f1-b0fb-dff31d7ea9e8
       configfile (${bootdir})/boot/grub2/grub.cfg

That gives me an entry in the grub2 menu I am using, that simply runs the boot menu for the older disk.  The “menuentry” line defines the entry that I will see when booting.  The “set” line sets a default, in case the subsequent search fails.  The “search” line locates the partition by its UUID, and sets $bootdir to that directory.  And the “configfile” line then tells grub2-efi to simply use the configuration there.

I have successfully tested that menu entry.  The main benefit is that if the opensuse system on the older disk updates the kernel, the grub.cfg for that system will be updated.  When I use “configfile”, I will be using that updated “grub.cfg”.  This works because when kernel is updated, Yast thinks it is updating the grub2 for the older system, and that includes updating its grub.cfg.  I would lose this benefit if I changed to not having a bootloader installed for that instance of opensuse.

A note on secure-boot

The system installed for MBR booting is working fine with secure-boot.  If I use the boot menu line added to my grub2-efi menu, that will check the signature on the kernel.  However, if I boot with the configfile entry, then the kernel signature is not checked.  In that case, secure-boot is only checking the integrity of the grub2-efi installation.


The older disk came with MBR partitioning.  I have heard rumors that Windows 8 does not like a mix of GPT and MBR partitioned disks.  So I booted Windows 8 on my UEFI box, and it did not complain.  It could see the additional hard drive in the disk manager software, and it listed the partitions.  Admittedly, these were all linux partitions.  I have not tested what would happen if there were a Windows partition there.

I decided to switch to GPT partitioning anyway.  That can be destructive.  The GPT partition table takes more space than an MBR partition table.  It takes around 34 sectors near the beginning of the disk, and another 34 sectors near the end for a backup partition table.

As it happened, I was not using any of the first 34 sectors, other than the MBR itself.   And I was not using the last 34 sectors (mostly a matter of luck).  So it looked safe to convert.

I ran “gdisk” which converted to GPT partitioning, though initially without saving the changes.  I compared the listed partitioning with the list from an earlier check with “fdisk”.  Everything looked good.  So I told gdisk to save the changes.  It warned me that this was potentially desctructive, but I went ahead anyway.  And that did not cause any problems at all.

I’ll note that you cannot ignore all “gdisk” warnings.  If the GPT partition table would have overlayed existing partitions, “gdisk” would have warned about that when initially converting.  That particular warning should not be ignored.  In my case, there was no such warning because no overlaying was required.


Tags: , ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: