Linux on your laptop: Here's what you need to know about UEFI firmware

Understanding UEFI firmware, and the Linux utilities to manage it, can save you a lot of time and trouble.
Written by J.A. Watson, Contributor

This will be my last foray into UEFI firmware for quite a while. For those who are already tired of my writing about it, I apologize in advance; for those who have asked for more, here it is.  

For the rest of you, I hope that you can find a few interesting and helpful tips and tricks in the following information.

UEFI Firmware configuration

There have been several questions and comments on my previous posts about UEFI boot. Let me start with a description of what I do with the BIOS configuration on all of the laptops I have with UEFI firmware.

SEE: 20 quick tips to make Linux networking easier (free PDF)    

While there are significant differences in the specifics of BIOS configuration utilities between laptop manufacturers, there are a few critical things which are common to all of them. One of those things is the choice between UEFI or Legacy boot modes. On every system I have (or have ever had), there are three possibilities:

  • UEFI Secure Boot: This is almost always the default mode on a new laptop. It requires that any and all bootable objects and firmware be signed with a recognized SSL certificate. The stated purpose of this kind of boot is to protect you from booting or otherwise using firmware images which have been maliciously modified. As I have said many times, my personal opinion is that this is a vastly over-complicated solution for a virtually non-existent problem.
  • UEFI Boot (Secure Boot Disabled): Every system I have used which has UEFI firmware has had the possibility to disable Secure Boot, but still use EFI boot. By doing this you get the benefits of the new firmware design over the old (very old) BIOS firmware, and of course the new boot configuration management structure, as I described in the previous post. This is the way that I have all of my UEFI firmware systems configured, and it is what I recommend to others who ask for my opinion.
  • Legacy Boot: This effectively returns the system to the old BIOS/MBR setup. In my opinion (and experience), the biggest problem with this is that it goes back to using the "magic" Master Boot Record configuration, which is much less flexible and much less robust, especially for multi-boot systems.

When UEFI boot configuration fails, changes or gets lost

I frequently hear from people who have installed Linux as a second operating system on a Windows laptop with UEFI firmware, and one of three things has happened:

  • After the installation apparently completes successfully, the laptop reboots and Windows starts with no sign of Linux having been installed.
  • Linux has been installed and booted successfully, and the world seems to be a wonderful place, but some time later, usually when Windows updates are installed, or a laptop firmware update is installed, it goes back to booting Windows again.
  • Linux has been installed, as in the previous point, but suddenly, without installing, changing or updating anything, it goes back to booting Windows. This one is actually a variant of the previous point, but it is particularly baffling because you literally didn't do anything at all, you just shut the laptop down and sometime later turned it back on again. In some cases this is accompanied by a message about Windows "repairing the startup configuration" for you, but often not even that.

As I mentioned when this was described in a comment to my previous post, what almost always happened in all three of these cases is that the UEFI boot priority list has been changed or "reset" by something, without your knowledge or permission. People tend to assume that their Linux installation has been wiped out or is otherwise no longer available, but that is generally not the case. The first thing to do when this happens is remember Douglas Adams' invaluable advice - Don't Panic!

When this happens, you will most likely be able to recover using some or all of the following actions:

  • First, check to see if it really is just that the boot sequence has been changed. One way to do that is to hit the "Boot Select" key while the system is starting up. Of course this requites that you know (or are able to figure out) what key that is, because it is different for almost every manufacturer, and sometimes it is even different for various systems from the same manufacturer. Yes, that is frustrating. The ones that I know off the top of my head are F12 for Acer, F9 for HP, and ESC for ASUS. It used to be F5 for very old IBM Thinkpads, but I don't know if that is still true since Lenovo took over Thinkpads from IBM. Anyone who knows for sure what this key is for other manufacturers is very welcome to post that information in the comments. Thanks.
  • If you are able to hit the Boot Select key, you will be presented with the boot list, and if Linux appears in that list, then you are probably in good shape and will be able to recover the boot configuration you want. You have to keep an open mind when you read this list - just because you installed Linux distribution "xyzzy" (Debian, Mint, Ubuntu, whatever), doesn't mean that it will appear in the boot list with exactly that name. Believe it or not, my recently acquired HP laptop insists on calling one of the Linux installations "Linpus". (Yes, I know what Linpus Linux is, and no, I have never installed it on that HP, or any other system in the past 5 years or more). Anyway, if there is a Linux entry in the Boot Select menu, go ahead and boot it and make sure your Linux system comes up normally. If it does, you're not out of the woods yet because you still need to fix the boot priority list (as described in the next point), but at least you know you haven't lost your Linux installation. If it doesn't boot Linux... well, maybe the worst scenario really has happened, and Windows update, or Windows Recovery, or some other "helpful" utility has wiped your Linux system and restored Windows to the entire disk. In this case I can't offer you much other than sympathy, because I've been there.
  • Another alternative is to hit the BIOS Configuration key while the system is starting. This is usually F2, but can also be something else - it is often stated at the bottom of the boot screen with something like "Press F2 for Configuration". Again, every manufacturer's BIOS configuration utility is different so I can't give specific instructions here. Look for Boot in the top-level menu, and there you should find a priority-ordered list of bootable objects. This should include Windows and (hopefully) your Linux system, along with various things like USB drives, Network boot, and a few system still even list Floppy disks. If you're at this point because your system is mysteriously booting Windows instead of Linux, what you need to do is move the line for Linux back to the top of the list. This may involve the F5/F6 keys to move items Up/Down the list, or it might require selecting the list and going one level deeper into the BIOS configuration to reorder things. Whatever the procedure, once you get Linux to the top of the list, your problem should be fixed, so Save-and-Exit, and try booting again.
  • There is one other way to display and modify the EFI boot list, using Linux utilities, which I will describe below. This used to be my "go-to fixit procedure", because like most Linux utilities it is powerful and flexible, but more and more systems have firmware today which either ignore changes you make this way, or restore the old boot configuration the next time the system is rebooted. More on this command below.

Linux EFI Boot Management Utilities

Linux includes several utilities specifically for managing the EFI boot configuration, and of course for actually booting the system. These are administrative commands, so they can only be run as root, or using "sudo".

  • efibootmgr: This is the utility I was referring to in the last point above. It can be used to display the current EFI boot configuration, and to add, modify or delete items in the boot priority list. If you are in the situation I mentioned above, where your computer has suddenly changed from booting Linux to booting Windows, and you are able to bring up Linux again via the Boot Select key, then you can use efibootmgr to see what has happened to the boot sequence. A simplified example of such a boot list might look like this:

# efibootmgr

BootCurrent: 0000

Timeout: 0

BootOrder: 0001,0000,0002

Boot0000* openSUSE Tumbleweed

Boot0001*  Windows

Boot0002*  openpensuse-secureboot

This shows that openSUSE Linux and Windows are both installed, and openSUSE has two boot images, one that is signed for use when UEFI Secure Boot is enabled, and one that is not signed. Unfortunately, the BootOrder shows that this system will boot Windows by default, so during a normal start you would never know that Linux was installed.

  • You can change the boot priority using the "-n" option with efibootmgr, so in this simple case to make openSUSE the default boot the command would be:

# efibootmgr -n 0000,0002,0001

  • Keep in mind, though, that this might not work, even though you might have confirmed that the change was properly made by printing the boot list again. As I said above, the current trend in UEFI firmware is that any changes not made using the BIOS configuration utility are discarded on the next boot.
  • gparted.png
    J.A. Watson
  • gparted (or any of a variety of other Linux disk management utilities): Disk management utilities are crucial to your understanding and managing UEFI multi-boot systems. The screen shot shown here is from my HP laptop, which has several different Linux distributions installed, but not Windows (although there are a couple of small relic partitions that I haven't cleaned up yet). The important thing to notice here is that the first partition is an EFI Boot partition (this is the one that was originally created by the pre-installed Windows), and partition 11 is also an EFI Boot partition, which I created to facilitate the installation of both Linux Mint and Ubuntu on this system.
  • Although Linux installers are capable of taking care of disk partitioning for you during installation, I prefer to use gparted to do it myself before running the installer, usually by booting a Live USB stick for a distribution which included gparted. That allows me to create the number and size of partitions I want, and is particularly important if I am installing a distribution for which I plan to use a separate EFI Boot partition.
  • grub2 and associated utilities: grub2 is the bootloader that comes with nearly all current Linux distributions. The grub2 management utilities are used during installation to identify all installed operating systems and create a boot configuration file. The latest versions are amazingly good at this.
  • grub.cfg: This is the boot configuration file. It is a "plain text" file, which means you can read it to see what has been set up on your computer, but it is not advised to modify it because this file will often be automatically overwritten with a new version during installation of various updates (Linux kernel, boot support files and such). If you look at it, you will see that it uses two different mechanisms to actually boot an operating system; for Linux systems it uses linuxefi (and probably initrdefi), while for Windows it uses chainloader. I mentioned in a previous post that I would at least briefly explain the way I use grub2 on EFI multi-boot systems; this is it. If you are experienced enough, confident enough and careful enough to undertake modifying grub.cfg yourself, you can change the linuxefi/initrdefi commands for other Linux distributions to chainloader. You can see the reason for this if you look closely at the automatically generated grub.cfg file; the linuxefi commands include the explicit name of the kernel image file, which generally also includes the kernel version number. That means if you update one of the other distributions, and the kernel version changes, the auto-generated grub.cfg will then fail to boot that distribution. If you use chainloader to boot the other Linux distributions, it goes through the EFI boot process again, and uses the boot configuration files for the distribution you are booting, and those get updated as part of the Linux update process, so that will always work no matter how much or how many times the distribution has been updated.
  • Whew, that's quite a bit to digest, so let me say again, this is absolutely optional, and not recommended unless you are quite experienced and very careful. If you do it, make sure you keep a copy of the new grub.cfg file, because that will be overwritten on the next update, and you'll have to fix it again. This is just me being a stubborn old geek, so if you don't understand it, or don't think it's worthwhile, that's fine too.
  • grub2-mkconfig: This is the Linux utility which actually scans the disk and creates the grub.cfg file. One bit of good news is that in the current versions of Linux this utility will do the right thing and put it in the right place when you run it with only the disk name on the command line - it doesn't require info about distributions, versions, partitions or anything else, it figures it all out on its own. So if there is something wrong with your boot configuration file, just run "sudo grub2-mkconfig /dev/sdX", where "X" is replaced by your disk name, and it will make a new config file. Also, if you just want to create a config file that you can look at for some reason, you can use "sudo grub2-mkconfig -o grub.new".

In summary, I think it should be clear from what has been said above that one of the most difficult issues in dealing with UEFI firmware systems and Linux is the variation between different UEFI implementations. Of course they all implement the same functionality in terms of booting the computer, but the way in which they are managed, the tools which are used to manage them - especially the BIOS configuration software - are very different. So you sometimes have to feel you way through, just keeping your objective in mind and looking for the correct path to reach that objective, and at the same time the way they interact with the Linux UEFI administration tools, down to the level of whether or not they even accept and retain changes made be the Linux tools, make this a difficult and tricky area.

I hope that I have given enough information, and examples, in this post to be useful in helping others find a way to deal with UEFI and Linux successfully.

Editorial standards