Cookbook: The Anatomy Of Boot & Boot Recovery

by ADMIN 46 views

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 features
  • hd0 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.