Some plans for migrating my workstation from MBR booting to UEFI

January 13, 2018

Today I finally assembled the machine that is to be my new office workstation, although I wasn't anywhere near brave enough to change over to using it on a Friday. For the most part I expect the change over to be pretty straightforward, because I'm just going to transplant all of my current disks into it (and then I'll have to make sure the network interface gets the right name, although I have a plan). However, I want to switch my Fedora install from its current MBR based booting to UEFI booting (probably with Secure Boot turned on), because it seems pretty clear that UEFI booting is the way of the future (my toe-stubbing not withstanding).

My current set of SSD root disks are partitioned with GPT and have an EFI system partition, although the partition is unused and unmounted; while I have a /boot/efi directory with some stuff in it, that's part of /boot and the root filesystem. In order to switch over to UEFI booting, I think I need to arrange for the EFI system partition to take over /boot/efi, get populated with the necessary contents (whatever they are), and then set up an UEFI boot entry or two. But the devil is in the details.

Currently I have the machine set up with a Fedora 27 install on a scratch disk, so I can run burnin tests and similar things. This helpfully gives me a live Linux that I can poke around on and save things from, although it also means that I have pre-existing UEFI boot entries that are going to become invalid the moment I remove the scratch disk.

So I think that what I want to do is something like this:

  1. Copy all of /boot/efi from the current scratch install to an accessible place, so I can look at it easily in case I need to.
  2. Make sure that I have all of the necessary and relevant EFI packages installed on my machine. Based on the scratch install's package list, I'm definitely missing some (eg grub2-efi-x64), but I'm not sure if all of them are essential (eg mactel-boot). I might as well install everything, though.

    (It appears that all files in /boot/efi on my scratch install are owned by RPMs, which is what I'd hope.)

  3. Turn off Secure Boot in the new machine's BIOS and enable MBR booting. My motto is 'one problem at a time', so I'd like to move my disks over to the new machine and sort out the inevitable problems without also having to wrangle the UEFI boot transition.

  4. Figure out the right magic way to format my existing EFI system partition in the EFI-proper way, because apparently I never did that. Naturally, Arch's wiki has good information.
  5. Mount the EFI system partition somewhere, copy all of my current /boot/efi to it, and shuffle things around so it becomes /boot/efi.
  6. Either copy my current grub.cfg to /boot/efi/EFI/fedora and edit it up or try to (re)generate a completely new one through some magic command. Probably I should start with what grub2-mkconfig produces when run from scratch and see how different it is from my current one (hopefully it can be persuaded to produce an EFI-based configuration even though my system was MBR booted).

  7. Set up a UEFI boot entry for Fedora on my EFI system partition. As I found out, this should boot shimx64.efi. I'm inclined to try to do this by modifying the existing 'Fedora' boot entry instead of deleting it and recreating it; in theory probably the only thing that needs to change is the partition GUID for the EFI system partition.

Assuming that I got everything right, at this point I should be able to boot my machine through UEFI instead of through MBR booting. I'm not sure if the motherboard's BIOS defaults to UEFI boot or if I'll have to use the boot menu, but either way I can test it. If the UEFI boot works I can turn on Secure Boot, at which point I will be UEFI-only.

I think the most likely failure point is getting a working UEFI grub.cfg. Grub2-mkconfig somehow knows whether or not you're using UEFI (and there doesn't seem to be any command line option to control this), plus my current grub.cfg is fairly different from what the Fedora 27 grub2-mkconfig generates in things like what grub2 modules get loaded. Perhaps this is a good time to figure out and write down what sort of changes I want to make to the stock grub2-mkconfig result, or perhaps I should just abandon having a custom version in general.

(I don't think my custom version is doing anything vital; it's just got a look I'm used to. And I could test a non-custom version on my current machine.)

I have two system SSDs, so I have an EFI system partition on the second SSD as well. In the long run I should set up an EFI boot environment on it as well, but that can definitely wait until I have UEFI booting working in general. I'll also need to worry about keeping at least grub.cfg in sync between the two copies. Or maybe I should just stick to having the basic EFI shell and Grub2 boot environment present, and assume that if I have to boot off the second SSD I'll need to glue things together by hand.

(My root filesystem is mirrored, but I obviously can't do that with the EFI system partition. Yes, technically I might be able to get away with it with the right choice of software RAID superblock, but no, I'm not even going to try to go there.)

Written on 13 January 2018.
« Open source software licenses matter
Our small tools for running commands on multiple machines »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jan 13 02:04:38 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.