One of the technology mysteries most people don’t really want to spend a second thought on is how the operating system of a PC is booted. When installing Linux next to Windows on the same disk, however, or when you plan to move a disk from one PC to another at some point, or when you want to restore a system image from a backup, it’s worth to understand at least the basics of the process to fix things in case something goes wrong. In a recent edition of the c’t magazine (see here, in German, article behind a paywall) there have been a number of great articles about the topic and here are my takeaways that will help me in the future.
On most of my computers, I don’t use the modern UEFI to boot the computer. It’s complicated and the old BIOS does the job as well. So until now, I’ve always deactivated UEFI in the BIOS settings and instead used the CSM (Compatibility Support Module) to start my operating systems. But that’s a strategy that is not sustainable especially on dual boot Linux/Windows systems and also on newer PCs that contains hardware that is not supported by the old BIOS anymore. O.k. UEFI, so here I come.
The first advice from the articles I will take to heart is that when using UEFI for the boot process, the CSM module should be deactivated in the BIOS settings to prevent a mix of UEFI and CSM boot installations. O.k., that’s easy to do. Also, this will help putting a Linux disk into a newer PC/notebook in the future that requires UEFI due to the old BIOS not supporting some hardware.
UEFI uses an EFI partition on the disk that can contain several bootloaders. If there are several, EFI is configured to always start a particular one. For dual-OS Linux/Windows installations, that would be the boot loader for Shim/Grub. For dual-/multiple-OS installations, Grub then offers a boot menu from which the Linux Kernel or the Windows boot loader is started.
Depending on the BIOS, it is possible to change the default boot loader or to have a menu in the BIOS to select the boot loader. In other words, Windows starts directly via its own EFI boot loader and not via Grub. The menu is usually hidden but when made visible by interrupting the boot process it looks like in the first screenshot above. The second screenshot shows the a BIOS menu in which the boot order can be changed. When putting Windows first the Ubuntu grub/shim bootloader is completely omitted. This might be a good option instead of booting Windows via Grub in case there is a problem during a Windows update that requires a reboot.
Next, I learned that UEFI stores information about the boot process in the so called UEFI variables in non-volatile RAM. Putting a disk in a different PC is therefore not straight forward as those variables are lost. However, there is a recovery mechanism on the EFI partition to restore these variables which usually works without intervention. In case it doesn’t, a boot repair disk is a good tool to recreate the variables again. A tool I use for the purpose, and also to fix boot issues after restoring a system partition from a backup drive is ‘Boot Repair‘. It’s still hosted on Sourceforge, which some might say is a bit odd, but it helped me quite a number of times in the past and is an essential tool in my toolkit. In Linux, the currently configured UEFI variables can be shown as follows:
martin@martin-Latitude-5580:~$ efibootmgr -v BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0001,0000 Boot0000* Windows Boot Manager HD(1,GPT,4af32676-f844-4ebd-9815-57c9f2964623,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.} Boot0001* ubuntu HD(1,GPT,4af32676-f844-4ebd-9815-57c9f2964623,0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
And in case you are interested in more details on EFI, here’s a page that digs into the topic at least 3 layers deeper than what I’ve seen elsewhere.