Cookbook: The Anatomy Of Boot & Boot Recovery
Cookbook: The Anatomy of Boot & Boot Recovery
Understanding the Boot Process
The boot process is a complex series of events that occur when a computer is powered on. It involves the interaction of various components, including the BIOS, UEFI, GRUB, Linux kernel, initrd, and init system. In this article, we will delve into the anatomy of the boot process and explore the different stages involved.
BIOS
The BIOS (Basic Input/Output System) is the firmware that controls the computer's hardware components. It is responsible for loading the UEFI bootloaders, which are stored on a FAT file system. The BIOS usually has a UEFI boot manager that can read any EFI partitions on each disk and allow you to edit the boot menu by adding or removing entries consisting of an arbitrary label, the disk path, and the .efi bootloader file.
UEFI
UEFI (Unified Extensible Firmware Interface) is a firmware interface that provides a more advanced and flexible way of booting the operating system. Bootable disks will contain an EFI filesystem with bootloaders. They are in the pattern of:
\efi\<os>\<loader><arch>.efi
For example:
\efi\Boot\bootx64.efi
\efi\Boot\fbx64.efi
\efi\Boot\mmx64.efi
\efi\ubuntu\shimx64.efi
\efi\ubuntu\grubx64.efi
\efi\ubuntu\mmx64.efi
\efi\ubuntu\fbx64.efi
\efi\ubuntu\bootx64.csv
\efi\ubuntu\grub.cfg
\efi\Microsoft\Boot\bootmgr.efi
\efi\Microsoft\Boot\bootmgrfw.efi
\efi\Microsoft\Boot\BOOTSTAT.DAT
\efi\Microsoft\Boot\boot.stl
File | Description |
---|---|
bootx64.efi | usually a generic, default backup bootloader for recovery (it'll probably be built to find a Windows EFI bootloader) |
shimx64.efi | A common, shared UEFI loader (traditionally signed by Microsoft) as a workaround to load grubx64.efi for Secure Boot |
grubx64.efi | The main GRUB bootloader in EFI format. Loads vmlinuz and initrd.img |
mmx64.efi | MokManager (Machine Owner Key Manager). Used to manage Secure Boot keys (MOK) for user-trusted binaries |
fbx64.efi | Framebuffer bootloader, providing basic graphical support before the OS loads |
bootx64.csv | A UTF-16LE-encoded CSV with boot entries for Secure Boot |
grub.cfg | typically just enough grub config to help it load the rootfs and continue from /boot/grub |
bootmgr.efi | Microsoft's bootloader loader (finds and loads winload.efi ) |
BOOTSTAT.DAT | part of Microsoft's bootloader config data |
boot.stl | contains certificates, and perhaps other config |
GRUB
GRUB (Grand Unified Bootloader) is a bootloader that provides a menu-driven interface for selecting the operating system to boot. It has a POSIX shell (not bash), but with commands geared towards booting Linux (and BSD and some others). It has tab-completion.
If you can get to the grub>
prompt - either because you just get dropped there, or by hitting e
to edit, you can likely find and boot your system.
ls
will show available partitions.
insmod
may or may not be necessary to load additional featureshd0
is roughly equivalent to/dev/sda
(hd0,gpt3)
is roughly equivalent to/dev/sda3
insmod lvm
insmod ext2
ls
ls (hd0,gpt3)/
If you can find the boot volume, then you can usually use the current vmlinuz
and initrd.img
set root=(hd0,gpt3)
linux /vmlinuz root=/dev/sda3
initrd /initrd.img
boot
Linux Kernel + Initrd
The initrd.img
is a BusyBox ram disk - basically a POSIX shell with utilities for mounting and fixing the rootfs.
ls /dev/
You can run fsck
to fix a file system, mount
to make it accessible and bind the special kernel filesystems.
mkdir -p /root
mount /dev/sda3 /root
You can chroot
into the rootfs to perform maintenance.
mount -o bind /dev /root/dev
mount -o bind /proc /root/proc
mount -o bind /sys /root/sys
chroot /root /bin/bash
In the chroot
, you have access to all commands, but the kernel is still in a recovery state, without much loaded.
modprobe vfat nls_cp437 nls_iso8859-1 nls_ascii
mount /boot/efi
upgrade-grub
umount /boot/efi
exit
umount /root/dev
umount /root/proc
umount /root/sys
Contrary to intuition, you exit
to continue the boot process - assuming that the root filesystem has been mounted. A pivot_root
will be performed and the system will continue to boot as usual.
Init System
/sbin/init
is the "thing that starts the stuff" in both VMs (and physical machines) and containers.
systemd is the [controversial][https://www.linux-magazine.com/Online/Features/Re-evaluating-systemd] system launcher that is used by cloud-init, and almost every major linux distribution - excluding Alpine, Devuan, and Arch (though Arch seems to be more of a Linux-enthusiast Desktop system than a cloud system).
It controls... a lot. It's actually difficult to describe because it does so much, that it's not entirely clear what it does - hence the controversy. It manages startup tasks, logging, auto-mounting network drives, permissions, and even containerization to some degree.
openrc init is the reasonable alternative. It just manages the startup sequence of system resources and services - making sure the network comes up, then things that depend on networking come up after, etc.
sysvinit is the old, ancient system that everyone loved, but everyone loved to hate. It operated sequentially, which made the boot slow - if networking came first then nothing could load on networking - not even the other things that didn't depend on it.
Login Prompt
If you get here, boot is done. Everything worked. All system services are running and any user launchers will launch at this point.
Boot Recovery
If the boot process fails, you can attempt to recover by using the efibootmgr
command. This command allows you to list, create, and delete boot entries in the UEFI firmware.
efibootmgr # lists boot menu (the one the BIOS sees, NOT what GRUB sees)
efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\debian\grubx64.efi' --label "Debian" --bootnum 0009
efibootmgr --bootnum 0009 --delete-bootnum
You can backup or delete old or corrupted config:
cp -RPp /boot/efi/EFI/ubuntu /boot/efi/EFI/ubuntu.bak
rm -rf /boot/efi/EFI/ubuntu.bak
And regenerate and reinstall the config:
upgrade-grub
grub-install
The efibootmgr
should have been used to create a new entry, if necessary.
Conclusion
In this article, we have explored the anatomy of the boot process and the different stages involved. We have also discussed the various components that make up the boot process, including the BIOS, UEFI, GRUB, Linux kernel, initrd, and init system. Additionally, we have covered the process of boot recovery and how to use the efibootmgr
command to recover from a failed boot process.
Cookbook: The Anatomy of Boot & Boot Recovery - Q&A
Q: What is the BIOS and how does it relate to the boot process?
A: The BIOS (Basic Input/Output System) is the firmware that controls the computer's hardware components. It is responsible for loading the UEFI bootloaders, which are stored on a FAT file system. The BIOS usually has a UEFI boot manager that can read any EFI partitions on each disk and allow you to edit the boot menu by adding or removing entries consisting of an arbitrary label, the disk path, and the .efi bootloader file.
Q: What is UEFI and how does it differ from BIOS?
A: UEFI (Unified Extensible Firmware Interface) is a firmware interface that provides a more advanced and flexible way of booting the operating system. It is designed to replace the traditional BIOS and provides a more secure and efficient way of booting the operating system. UEFI is more flexible than BIOS and allows for more advanced features such as Secure Boot and firmware updates.
Q: What is GRUB and how does it relate to the boot process?
A: GRUB (Grand Unified Bootloader) is a bootloader that provides a menu-driven interface for selecting the operating system to boot. It has a POSIX shell (not bash), but with commands geared towards booting Linux (and BSD and some others). It has tab-completion.
Q: What is the Linux kernel and how does it relate to the boot process?
A: The Linux kernel is the core of the Linux operating system. It is responsible for managing the computer's hardware components and providing a platform for running applications. The Linux kernel is loaded by the bootloader (GRUB) and is responsible for initializing the system and loading the initrd.
Q: What is the initrd and how does it relate to the boot process?
A: The initrd (initial ramdisk) is a BusyBox ram disk - basically a POSIX shell with utilities for mounting and fixing the rootfs. It is loaded by the Linux kernel and is responsible for providing a temporary root filesystem for the system to boot from.
Q: What is the init system and how does it relate to the boot process?
A: The init system is responsible for starting the system services and managing the system's startup sequence. It is responsible for loading the system's configuration files and starting the system's services.
Q: What is systemd and how does it differ from other init systems?
A: systemd is a modern init system that is designed to replace the traditional sysvinit. It is more flexible and efficient than sysvinit and provides a more advanced way of managing system services.
Q: What is the purpose of the login prompt and how does it relate to the boot process?
A: The login prompt is the final stage of the boot process. It is responsible for authenticating the user and providing access to the system.
Q: How can I recover from a failed boot process?
A: You can recover from a failed boot process by using the efibootmgr
command. This command allows you to list, create, and delete boot entries in the UEFI firmware.
Q: What is the purpose of the efibootmgr
command and how can I use it?
A: The efibootmgr
command is used to manage the UEFI firmware's boot entries. It allows you to list, create, and delete boot entries in the UEFI firmware.
Q: How can I backup or delete old or corrupted config?
A: You can backup or delete old or corrupted config by using the cp
and rm
commands.
Q: How can I regenerate and reinstall the config?
A: You can regenerate and reinstall the config by using the upgrade-grub
and grub-install
commands.
Q: What is the difference between upgrade-grub
and grub-install
?
A: upgrade-grub
is used to update the GRUB configuration, while grub-install
is used to install the GRUB bootloader.
Q: How can I troubleshoot a failed boot process?
A: You can troubleshoot a failed boot process by using the dmesg
command to view the system's boot logs. You can also use the ls
command to view the system's file system and the cat
command to view the system's configuration files.