GRUB: Control your boot
Mats Tage Axelsson takes you through the intricacies of GRUB that you never thought you would wonder about…
Mats Tage Axelsson explains the inner workings of GRUB and how it can unify booting all your operating systems – while looking pretty, too.
Booting your PC is something that just happens and most people don’t even give it a second thought, unless it’s brain-numbingly slow or something goes about as wrong as Brexit has. This is largely as most distributions, when you install them, automatically create the partitions and sets up any dual-boot required. Beyond that, most users leave it be and get on with their lives.
This makes the thing we call GRUB and generally the entire boot process a mystery to most people. In this article, you can start clearing the fog a little bit and see what you can do to improve things. If dual-booting isn’t on your agenda, you still have other interesting options to explore along expanding your knowledge.
If you’re wondering what it stands for, GNU GRUB is the Grand Unified Bootloader. The bootloader is the software glue that sits between the BIOS/UEFI firmware that kickstarts your PC hardware into life and the Linux (or Windows) kernel being run – started by the bootloader – and then the Process ID One (PID1) ‘init’, very often Systemd.
Depending on what you are after, you may need to compile (don’t panic!) GRUB or even the kernel. One interesting feature to consider is EFI_STUB, which makes the kernel a boot loader that you can set to be the first to load. That will be faster, but you will be unable to dual-boot your machine, which can make life complicated. Single-booting is not necessarily bad though – have you decided to stick with Linux or do you need other operating systems? If you only have one or two applications that need Windows, you can run that in a virtual machine.
In most cases, your GRUB binary is good to go, as you can make many tweaks to your system without compiling. If you do need to compile, the tools are the common ones: GCC, make and binutils. For ordinary tweaking, you have plenty of tools available together with GRUB itself. Please remember that you are playing with the boot system: do something wrong and you may need to do a recovery (why not see our recovery feature on page 44) action. This can take time and you may lose all your data.
Wise readers always have important data backed up using the cloud, Clonezilla or the backup application delivered with your distribution. If you want to boot without GRUB, you may need to compile your kernel.
32-bit vs 64-bit
GRUB comes as both 32-bit and 64-bit, though in today’s world, the former is seldom useful. However, you may have an old system lying around that you want to boot from a memory stick, so consider getting GRUB 32-bit for this edge case. While you can start a 32-bit OS with GRUB 64-bit, you may need 32-bit GRUB only for the case of an old 32-bit computer. This is common for old (2006) imac computers. The limitation is in the UEFI being 32-bit, making GRUB unbootable.
The package that handles this is grub-efi-ia32; you will ordinarily have to do a bit of work to make it work. sudo apt install grub-efi-ia32 grub-efi-ia32-bin
You should be aware that when you install this you change the GRUB version on the machine you’re working on. This could be a disaster if you do it on your ordinary machine. The safe alternative is to create one
using an ISO image. Ordinarily, you copy an ISO image using dd, which creates the entire disc on that medium. With some trickery, though, you can put several ISO images on a memory stick and boot the image using
GRUB instead.
BIOS vs UEFI
Most of us know that the BIOS system is old and UEFI is newer, but what has changed? The big difference is that UEFI can address larger disks using the GUID partition table or GPT. It also enables CPU independence and things like network capability before the OS starts. This makes it possible to troubleshoot a system remotely even before you have a running OS.
Another interesting difference is that UEFI does not rely on the boot sector alone; instead, you call a boot manager. In your case, this will be GRUB. Most distributions use GRUB as the default bootloader and boot manager, so the install procedure will create all files and install them to an appropriate drive. If you have some odd setup you are interested in creating, you need to consider where it should be and what you want to add.
The common method in modern systems is to have GRUB in the MBR (Master Boot Record) and a UEFI partition for the boot and other files that relate to the start of the system. You can install GRUB to a place on the UEFI partition and use a generic boot loader in the MBR. In the box bottom right, you can read about refind, which can load GRUB or do this job on its own. You can use other methods but usually you will only need to do this with very odd hardware.
Where the files are placed varies between distributions, Fedora places all files in the EFI System Partition (called the ESP). Ubuntu mixes where the files go: the ESP is mounted under /boot/efi/ and /boot is on your system partition. This could be complicated if your system partition is damaged.
The manual method from tutorials on the web usually describes where everything is under the ESP. This would place the kernels in your ESP, which could require a large ESP. With two kernels and all the mode files, you end up with 150MB of ESP. Most of us can live with that and an automatically-created ESP is usually around 300MB, so do this when you are making your own system.
When you start experimenting with GRUB, you may end up with failed boots, so choose a method that can help you back to a booting system.
Boot editing
If you think that a change to kernel parameters may have a positive effect on your system, you should try them out at boot. All parameters that you pass to the kernel are in the list in GRUB before boot.
You can stop the boot and change the values before you allow the boot to start. When you do this, the changes you make are not stored in the GRUB configuration – it only changes that particular boot. You will have to continue changing the values in your running system and update the configuration until you have found the best solution for you.
In GRUB itself, you even have the possibility to use command-line tools that are included. You also have the choice to put GRUB on a memory stick and boot from that. This also makes it possible to have your main system running while you try out new choices on another system. There are many scripts to help you do this – Grml comes to mind. This system builds a directory tree with ISO images and creates your GRUB configuration. To understand it well, try the manual approach using grub-install:
$ grub-install --force --removable --boot-directory=/ mnt/usb/boot --efi-directory=/dev/sd[x]/efi/boot/
This command needs to have all the files needed for the boot. These files are the binaries and configuration files that are usually put there by the distribution scripts. The important ones are the EFI binaries. There is one for each system type, 32-bit and 64-bit. All these files are available at https://webativo.com/uploads/ files/usb-pack_efi.zip. The other files are modules for different functions, the crucial ones being to support different file systems.
Vdi inside a VM
The safest way to try things out is to use a virtual machine to test everything. For the sake of speed, use small distributions so it is easy to start and restart.
GRUB usually boots to one of the partitions on your
hard disk. However, there are many other ways to fetch the image and also more places to fetch it from. With the correct configuration files, you can boot from USB using GRUB. It also supports IPXE so you can boot from the network. When you are booting many operating systems, you may need to chain-load them. This is usually the case with Windows. Chain loading means that GRUB sets the root and hands over control to the next actor – it does not pass any parameters to it. In the case of a Linux kernel, you pass kernel and initrd parameters to it to help run the system.
When you are testing out stuff, you may want to use an ISO file to get started. Most distributions come as an ISO file intended to be copied to a USB disk and then used to install it to the system. You can choose to run the ISO from the disk; all you need to do is open it with
loopback before you set the values to boot. The boot will then act as if you booted from external media. Since you can edit an ISO, you can change the ISO file to suit your needs; this is a useful way to prepare a deployment ISO with a special configuration.
Place the ISO file in a directory that GRUB can reach – anywhere except an encrypted data partition. You then rewrite your GRUB configuration to point to the ISO file: menuentry “Run Ubuntu Live ISO” { loopback loop /ubuntu.iso linux (loop)/casper/vmlinuz boot=casper iso-scan/ filename=/ubuntu.iso splash -initrd (loop)/casper/initrd.lz }
This code first opens the ISO file in a loopback device and then hand parameters to the Linux kernel and initrd files. You can use any ISO file with the same settings; just make sure you have the files inside your ISO file. Each distribution has its own needs but you can check the ISO before you start, or even read it using
GRUBS built-in commands. One caveat is that you need to install grub-imageboot on the system you are booting from. In the default configuration, there are five parameters (out of many more):
GRUB_DEFAULT=0 sets which entry in the table is executed when the user does not intervene.
GRUB_TIMEOUT=10 sets the default time to wait before booting automatically.
GRUB_DISTRIBUTOR=’LSB_RELEASE -i -s 2> /dev/null || echo Debian’ shows the distribution you use.
GRUB_CMDLINE_LINUX_DEFAULT=”QUIET splash” sets how Linux boots – in this case, without showing text and showing a splash screen.
GRUB_CMDLINE_LINUX=”” Here you can set special commands you want to run to set up your kernel boot. The other ones are useful for handling odd screens and preparing the kernel for bad memory.
Kernel parameters
The more common Linux kernel parameters are quiet splash ro . If you want to know what is going on during boot, remove quiet so you can see the bootup text. Other things you may need to change are memoryrelated stuff and graphics card info. You can set vga in case you have a problem seeing the boot. Values are the resolution for your screen, seldom used in x86_64 scenarios. video sets the frame buffer resolution during boot. panic sets the delay before the kernel reboots at a panic. You can set this value to negative so that you get reboots immediately on a panic. gpt forces the kernel to uses any valid GPT signature so you don’t read MBR from any disks.
The Linux command loads the kernel and prepares all the parameters; next, initrd sets its parameters and loads itself. Once you have loaded everything, you run the boot command. First, you pick the kernel from the disk; usually, this is named vmlinuz-x.y.z-amd64. Next you pick the root partition to boot from. Finally, you choose the file system to be read-only. The file system will be set to read-write as soon as the boot is finished.
Some other values you can choose include rootflags to set the root filesystem flags, and init to choose another init system. This is especially useful if you want to try out sinit, for example, without changing your existing system.
Here, you can also set the swap device to return from when you resume from hibernating, with resume=/
File structure
When you want to change your configuration, you need to change some files. GRUB uses a set of files that are compiled by update_grub, so if you want to stay with
your distribution, you need to change only specific files. The most common file to change is /etc/default/ grub, in which you can set the delays and other defaults mentioned earlier.
The other directory you need to know about is /etc/ grub.d/, which contains files that update-grub uses to compile the final settings. For interest, the final file is /boot/grub/grub.cfg. This file is created by your scripts and you should not edit it. When you have special requirements, such as starting from an ISO file, you can use a file in /etc/grub.d/.
Using /etc/grub.d/
Filenames in this directory start their names with numbers, a system inherited from Sysv init. The files are handled in numerical order and some are reserved, while others you can use.
The files starting with 00, 10 and 20 are reserved. If you want to add another OS, you can use 01, 11 and so on to define the order in which they are placed in the boot menu. The best place to place your changes is to leave them in 40_custom, since this is the convention.
If you want to change the look of GRUB, you can use /etc/default/grub to add a background image. You need to point to the image file and run the update-grub command. The code is simple since there is already a keyword for it. Grub_background=”/usr/share/images/grub/
Windbuchencom.png”
This will only change your background to a nice winter background. You need to be careful though – you may not be able to read the menu entries if you have the wrong colour of background. To make sure you can read what GRUB tells you, try a theme instead. To install a theme, you need the files of all the fonts available to GRUB. The safest place is under / boot/grub/themes/. This directory is not there by default, so may need to add it. You can find a theme on www.gnome-look.org. Once the files are there, you need to add the theme to your configuration. Add the below code to your /etc/default/grub.
GRUB_GFXMODE=1280X760 Grub_background=/boot/grub/themes/
Ageofsystems/background.png Grub_theme=/boot/grub/themes/
The first value sets the resolution of the GRUB screen, and the next sets the background. The last one is a link to the theme.txt file. This contains code similar to CSS but with the elements of a GRUB screen.
During boot, you can stop GRUB and try out the commands that you will later set in your grub.cfg. A good tip is to try this out in a virtual machine to get the hang of it. Any script GRUB needs to have support for filesystems and procedures to load the specific system.
The script first loads the modules GRUB requires. This usually means loading filesystem modules. To get access to the command line, you stop GRUB from continuing and then press C. You can print all commands with the help command and you have command completion using the Tab key. If you have an odd filesystem, you will need to load a module for that. To load the ext2 filesystem, use: $ insmod ext2
The system can now use ext2 to find your files. Note that the module is called with the name, not including the ‘mod’ extension.
List what partitions you have with ls . You can also find devices that have the boot value set using the search command. There are many parameters available so you can choose the one whose system you are trying to start. The most robust way is to use this to pick a UUID to boot from. With the set parameter in the search command, you can then set root to that value, like so:
$ search --fs-uuid
You can then use the root variable in your linux command:
$ linux /boot/vmlinuz-5.0.0-32-generic root=root
After that, you load your initial ramdisk with the initrd image of your choosing, if necessary.
$ initrd /boot/initrd.img-5.0.0-32-generic
This provides an initial filesystem to boot from, useful in most cases as it loads in a fast, compact initial root filesystem. refind is the most similar alternative to
GRUB, but it’s made especially for UEFI so does not support BIOS.
You can also make your system boot directly into the Linux kernel. To achieve this, you need to have a kernel with the efi-stubloader compiled into it. This is usually the case in regular distributions.
Most of us won’t change the boot very often. In fact, who needs to boot at all, with sleep and hibernate features? However, when we want a special setup, it is wise to investigate what options there are. If you are dead-set on using only one kernel and distribution, you should set your machine to boot straight into the kernel as it will reduce boot times.