GRUB updates have been known to result in Linux computers booting into the BIOS or UEFI settings. The fix for this takes advantage of a useful system recovery trick you really ought to know about.
A Case Study: GRUB 2:2.06.r322
A system update for Arch and Arch-based Linux distributions in summer 2022 included a new version of GRUB. GRUB stands for grand unified bootloader.
A bootloader is an application that kicks off the boot-up process when your computer is turned on. Several software tools and utilities need to be launched—from the right partition and in the right order—to eventually result in an operational and accessible operating system. GRUB kicks off that cascade of events.
If you have more than one operating system installed on your computer, GRUB provides a menu so that you can select which operating system to use. One of the code changes to GRUB 2:2.06.r322 added support for a new GRUB option, --is-supported. The option is used to indicate whether a boot to firmware capability is present or not. If it is, GRUB adds an entry to the boot menu to let you boot into your EUFI settings.
The new option was referenced in a script called “30_uefi-firmware.in.” The diff for this file shows that an if statement was removed, and two lines were added.
One of the new lines was a replacement if statement. The other new line contains fwsetup --is-supported . The “fw” in “fwsetup” stands for firmware. But because that line is above the new if statement, it is always going to run. If it was inside the body of the if statement it would only run when the test in the if statement resolved to true.
This caused problems on many, but not all, UEFI computers. It depended on whether the version of GRUB you already had installed supported this command. Affected machines would do one of two things. They’d either go into a boot-loop where the boot process was never completed but continually restarted, or the computer would boot straight into the UEFI firmware settings. Either way, there was no way to force your computer to boot into Linux.
When you’re faced with situations like this there is always the nuclear option of doing a complete reinstall. That’ll work, but depending on how your hard drive has been partitioned, without a recent backup, you may lose data.
The low-impact method uses chroot and a Live USB or Live CD/DVD. This is a good technique to understand and have up your sleeve for all sorts of system failures when you can’t boot or log in to your Linux computer.
The Technique We’ll Use
In order to use this technique you need to have either a bootable USB or CD/DVD with a Linux distribution on it, that boots into a live Linux instance. Typically these are called a Live USB or Live CD/DVD. All the major distributions support this function.
We’re not going to install anything, so the live media doesn’t have to be the same distribution that you have installed on your computer. You could use an Ubuntu USB to repair an EndeavourOS computer, for example. If you don’t have access to any live media, you’ll need to use another computer to download an image and write it to a USB memory stick or to a CD/DVD.
When you boot from the live media you’ll be able to mount and access your existing file system. Your installed file system will appear as part of the file system of the Linux that was booted from the live media. That’s great. If we can access it, we have a chance of repairing it. But it does raise an issue.
The root of this hybrid file system is the root of the live media file system, not the root of your installed file system. To make the file paths configured in your Linux system reference their correct target locations—somewhere inside your file system, and not somewhere relative to the root of the live Linux—we need to use chroot to set a new root that points to the root of your installed file system. In other words, paths that start with “/” will use the root of your file system as their starting point.
The test computer we used for this uses the ext4 file system, but you can use this technique on other file systems too. You just have to identify which partitions or volumes you need to mount, and where to mount them. The principles are the same.
Putting It Into Practice
We created a bootable USB drive and booted our stricken computer from it. The distribution we used was EndeavourOS. The EndeavourOS live media boots into the XFCE 4 desktop environment.
To identify which partitions hold the root of your file system, and which is the boot partition, open a terminal window and use the fdisk command. We’re using the -l (list partition) option. You’ll need to use sudo, too.
sudo fdisk -l
Scroll through the output until you see entries labeled “EFI System” and “Linux filesystem.”
On this computer, they’re both on the sda hard drive. They’re in partitions one and two, as indicated by the partition labels /dev/sda1 and /dev/sda2.
On your computer, they might be on different hard drives and partitions. Take care to note the partitions they’re on, we’ll need to use these in the next commands.
We need to mount the file systems on these partitions by attaching them to the live file system. The mount command will do that for us. Remember, your partition labels are likely to be different, so make sure you use the ones from the results of your fdisk command.
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
To make the effective root of the file system start at the root of your actual, installed file system, we’ll use chroot to set the root to be the “/mnt” mount point. This is where the root of your installed file system is grafted onto the live file system.
sudo chroot /mnt
Note that the command prompt changes to show you are now effectively logged in as root, and you are at the root directory “/”of the file system of your computer.
We can easily test this, by changing into the “/home” directory and checking what directories exist inside it.
cd /home
ls
You should see a directory for each user configured on your computer, including one for your own user account. This computer has a single user, called “dave.” If we’d used cd /home before we used the chroot command, we’d have entered the “/home” directory of the live file system.
Just to be clear, you’re now accessing your real file system as the root user, so be careful.
To fix the issue with GRUB 2:2.06.r322, all we needed to do was run the grub-install command.
grub-install
Running grub-install blindly like this isn’t usually recommended. In this instance, it is what was required.
Repair or Replace
If you’re trying to fix a different problem, you’ll need to check the forums for your distribution for the appropriate fix for your issue. If it is a widespread complaint, you’ll soon find a resolution for it.
At the very least, now that you can access your file system, you’re able to copy your data to some removable media. If you decide to do a full reinstall, you won’t lose data.
RELATED: How to Copy Files Using the “install” Command on Linux
