Setting UEFI-loader. The quickest guide in the world

How is the boot of modern OS? How to install the system to configure the boot through UEFI, without drowning in the manuals and without breaking anything?

I promised the "quickest guide." Here it is:

1. Create a GPT partition table on disk
2. Create a FAT32 partition for a couple of hundred megabytes
3. Download from the Internet any UEFI-downloader
   (we need the bootloader itself, this is one binary file!)
4. Rename and put this file on the created section at /EFI/Boot/bootx64.efi
5. Create a text config, put it where the loader expects to see it
   (configuration and location of the config depend on the specific implementation of the bootloader, this information is available on the Internet)
6. After the reboot, we see the bootloader menu
   (If Windows 8 or 10 is installed on the disc, this manual is likely to be reduced to points 3–5.)

TL; DR is not necessary to prescribe the path to the bootloader in the new UEFI boot records - you need to place the bootloader file in the standard "default path", where UEFI will find it, and instead of the UEFI boot menu, use the bootloader menu, which is much easier and safer to configure

How not to do

There are, in fact, several ways to configure a UEFI boot. I will begin with a description of other options - so that it is clear how (and why) you don’t have to . If you come for guidance - shake to the bottom.

No need to go into NVRAM and touch efivars

The most "popular" procedure for installing the bootloader into the system is this: the OS installer creates a special partition, on it - the directory structure and locates the bootloader files. After that, he uses a special utility (efibootmgr in linux, bcdedit in windows) to interact with the firmware of the UEFI chip, adding a boot record to it. This entry indicates the path to the bootloader file (starting from the root of the file system) and, if necessary, the parameters. After that, the OS boot option appears in the boot menu of the computer. For linux, it is possible to do without a bootloader at all. The boot entry indicates the path immediately to the kernel, along with all the parameters. The kernel must be compiled with the EFISTUB option (which has long been the standard for most distributions), in which case it contains the header of the "EFI executable file" that allows the firmware to run it without an external bootloader.

When the system starts, when the user selects the boot record he needs, the UEFI firmware will first look for a special EFI partition on the disk specified in this record, access the file system on this partition (FAT or FAT32), and start the bootloader. The loader reads its config from the settings file, and either loads the OS or provides the boot menu. Noticing anything? Yes, we have two boot menus - one at the level of the UEFI chip firmware, the other at the level of the bootloader. In reality, the existence of a second user may not even guess - if there is only one item in the menu, the Windows bootloader starts loading it without any questions. You can see the screen with this menu if you install a second copy of Windows or just crookedly reinstall it.

Usually, to manage the boot records, online guides suggest interacting with UEFI firmware. There are already five basic options for how this can be done: efibootmgr under linux, bcdedit in windows, some kind of software on Macs, the bcfg command of the uefi shell utility (runs from under UEFI, “on bare hardware” and without OS, because compiled in that very special format) and for especially high-quality firmwares - graphical UEFI tools (in popular terms, "in the BIOS settings").

For all the above multi-books, you could easily have missed such an idea: the user, in order to change the settings of the program part (for example, add the OS startup parameter), has to rewrite the flash memory of the chip on the board. Are there any pitfalls here? Oh yeah! Windows can sometimes make a brick out of a laptop , linux, too , and in many different ways . The quality of the firmware often leaves much to be desired - the UEFI standards are either implemented crookedly or not implemented at all. Logically, the firmware is obliged to experience the complete deletion of all efivars variables without consequences, do not store critical data for them and restore the default values ​​on their own - simply because the user has access to them, and the probability of their complete removal is far from zero. I personally, in the course of experiments, repeatedly (fortunately, reversibly) “bricks” my Lenovo - all items disappeared from the boot menu, including the option “enter settings”.

Working with UEFI boot records is also not sugar. For example, the efibootmgr utility does not have the "edit existing entry" option. If you want to change the kernel parameter a bit, you delete the entire record and add it again, already modified. In this case, the string contains double and single quotes, as well as forward and back slashes in a not particularly obvious order. When I finally forced this magic to work, I saved it in the form of bash scripts, which are still in my root filesystem:

efibootmgr -c -L "Archlinux (debug)" -l '\EFI\archlinux\vmlinuz-linux' -u "root=/dev/mapper/vg1-lvroot rw initrd=\EFI\archlinux\initramfs-linux.img systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0" 

Do not use GRUB

This is a damn mastodon, 90% of the functionality of which is intended for disks with MBR. To configure, you need to edit a number of files, and then execute the command for generating a config. The output is a huge, incomprehensible normal person sheet. In the composition - a mountain of executable files. It is put by a team that you can’t take out of your head just like that - you have to go to the documentation

 grub-install --target=x86_64-efi --efi-directory=esp_mount --bootloader-id=grub 

For comparison, the simplest UEFI bootloader, which is included in the systemd package, is set by the command

 bootctl install --path=/boot 

This command does exactly two things: it copies the loader's executable file to the EFI partition and adds its boot record to the firmware. And the config for it takes exactly seven lines.

"The quickest guide" - a little more detail

The boot menu must be implemented at the bootloader level - editing text configs is much easier and safer.

We don’t need a boot record - the fact is that when setting a boot from a disk in BIOS settings, UEFI firmware first looks for an EFI partition on it, and then tries to execute the file at a strictly fixed address on this partition: /EFI/Boot/BOOTX64.EFI

What is an "EFI partition"? In theory, it should have a special type of "EFI System" (ef00). In practice, the first partition on a GPT disk, formatted in FAT32 and having enough space to accommodate the bootloader and auxiliary files (if any), is suitable .

Point 3: "Download any UEFI downloader from the Internet" . What does it mean? The loader is simply an executable file of a specific format, to which the bundle comes with a config. For example, if you have an installed package with systemd at hand, you can find the bootloader file at /usr/lib/systemd/boot/efi/systemd-bootx64.efi, rename it to bootx64.efi and copy to / EFI / Boot / on the EFI section. Not at hand systemd? Download the archive from the Archlinux website. Or from the Ubuntu repository. Or Debian. Is there a Windows system at hand? Take the Windows bootloader from there, it will also fit)) If you can configure it, I honestly have not tried it.

Point 4: "Configure config" . Like a regular program, when the bootloader starts up, it expects to find configuration files along certain paths. Usually this information is easily found on the Internet. For the systemd-boot loader, we need to create a directory "loader" in the root of the EFI partition, and in it the file "loader.conf" with three lines (I bring my own):

 default archlinux timeout 10 editor 1 

The editor parameter is responsible for the ability to edit the boot menu item before starting.

Next to loader.conf, you need to create a directory of entries - one file in it will be responsible for one boot record in the boot menu. I have one arch.conf file with the following content:

 title Arch Linux linux /efi/archlinux/vmlinuz-linux initrd /efi/archlinux/initramfs-linux.img options root=/dev/mapper/vg1-lvroot rw initrd=\EFI\archlinux\intel-ucode.img 

I did not mention, but rather obviously, the kernel and initramfs should be on the same file system as the boot loader, that is, on the EFI partition. Paths to them in configs are counted from the root of this file system.

Other loaders

systemd-boot is very simple and provides a spartan-looking black and white menu. There are more beautiful options, if the soul asks for beauty.

rEFind is a very beautiful loader. You can download it here as a deb-package. I use on my laptop. Able to create a boot menu automatically, without a config — simply by scanning files.

Clover . Allows you to set the native screen resolution, has mouse support on the boot screen, different themes. The default theme is terrible, the config in the form of xml is not readable, could not be configured.

Various non-obvious consequences

You can easily try this scheme at work. Take a USB flash drive, format it into a GPT partition table, create a FAT partition and copy the bootloader there. The computer will be able to start with it.

If you simply copy the boot-partition of the installed linux to such a USB flash drive, the system will safely boot from the USB flash drive without seeing the difference.