Linux system administration course Spring 2019: 2nd slideset 1 Booting a PC There are ancient and also brand new dragons here... 2 Starting a Linux PC ● PC firmware is started (BIOS or UEFI) ○ Devices are initialized and scanned: CPU, memory, devices, disks ○ Device controllers firmware initialization is run (network card, RAID controllers) ○ The boot device (disk or network device) is decided. ○ either by non-volatile firmware configuration or manually. ● The firmware loads and starts a boot loader from the boot device. ○ GNU Grub2 or Windows boot manager (there are others however) ○ Boot loader loads its configuration from disk or network. ○ Boot loader loads kernel and initial ramdisk (initrd) to memory. ● Boot loader starts Linux Kernel. ○ Kernel starts user space software on initrd ○ Initrd loads drivers and locates the OS system installation ● Initrd starts the Linux distribution Linux system administration, 2nd slide set © Jani Jaakkola 2019 3 Starting a Linux PC - TL;DR version 1. PC is powered on. 2. PC firmware is started. 3. Firmware locates boot device (network or disc). 4. Firmware load and starts boot loader (grub 2) from boot device. 5. Boot manager loads kernel and initial ramdisk. 6. Boot manager starts kernel. 7. Kernel starts software on initrd. 8. Initrd loads drivers. 9. Initrd mounts root filesystem. 10. Initrd starts /sbin/init (systemd) and is removed from memory. Linux system administration, 2nd slide set © Jani Jaakkola 2019 4 Legacy BIOS boot ● Legacy BIOS does not know how to use file systems. ○ It was invented in the 80’s. MS-DOS was the OS that had an actual file system. ● It can read the MBR (Master Boot Record) partition table. ● Boot loader (1st stage of it) is installed in known location in the MBR. ○ The boot loader is started from MBR in 16-bit non protected mode, just like MS-DOS ○ This is the only place left where 16-bit non protected mode is used in 2019. ○ There can be only one MBR boot loader on a given disk. ● The MBR partition table has a maximum size of 2T. ● … Amazingly, this system actually works. ○ Virtual machines are still mostly booted this way, even when PCs are not. Linux system administration, 2nd slide set © Jani Jaakkola 2019 5 UEFI boot ● BIOS boot was simple and worked. ○ Intel Itanium (RIP) needed a way to boot and didn’t have 16-bit real mode. ○ So new standard was required to make booting more complex (and buggy). ○ The need for 16-bit real mode got removed. This was nice. ● UEFI specification supports multiple architectures. ○ 32-bit Intel architecture and 64-bit Intel architecture and ARM architectures. ○ Forget the 32-bit Intel architecture: it wasn’t actually used, when 64 bit CPUs arrived. ● Has a standardised preboot execution environment with .EFI binaries. ○ Boot loaders are implemented as .EFI binaries. ○ Binaries can be loaded from a FAT partition on a disk or from network. ○ Support boot time applications (BIOS updates, hardware key management). ● GPT partition tables remove old MBR partition table limits. ○ No disc size limit. Linux system administration, 2nd slide set © Jani Jaakkola 2019 6 UEFI boot - Linux ● For Linux (and Windows) there needs to be a FAT32 formatted EFI partition. ○ This partition contains the bootable .EFI boot loader. ○ Usually mounted in /boot/efi ● The boot loader is installed in /boot/efi and is almost always Grub 2. ● UEFI has a nonvolatile memory storage for EFI variables. ○ These are used to configure the UEFI boot, including the selected boot loader. ○ These are managed with command line tool efibootmgr Linux system administration, 2nd slide set © Jani Jaakkola 2019 7 UEFI Secure boot ● UEFI binaries can be cryptographically signed. ● When secure boot is enabled, UEFI will verify signatures of binaries. ○ If the signature is not known, booting is refused. ○ Also, system will refuse to run anything unsigned in the kernel security ring. ○ The idea is to protect the system from malicious boot loaders and evil maids. ○ Typically the trusted signatures are from the vendor and MS and no one else. ○ This is a problem for open source and operating system development. ○ MS signs Linux boot loaders for Ubuntu and other commercial Linux platforms. ● Plain secure boot is just useless... ○ An attacker can always find a signed old binary containing security holes from the Internet. ○ If the disc is not encrypted, attacker just modifies the plain text parts of the operating system. ● Secure boot with TPM (Trusted Platform Module) can provide actual security. ○ Including validation that system isn’t modified and secure storage of disc encryption keys. Linux system administration, 2nd slide set © Jani Jaakkola 2019 8 Network boot ● During network boot the PC firmware queries the network for bootable image instead of a disc. ● The firmware configures the network with DHCP (Dynamic Host Configuration Protocol) and the booted image is selected with DHCP options. ● Legacy bios has PXE (pre boot execution environment) ○ Can boot Grub and PXELinux. ● UEFI boots normal *.EFI binaries ○ Which must be signed to use secure boot. Linux system administration, 2nd slide set © Jani Jaakkola 2019 9 Starting Linux Grub 2, initial ramdisk, systemd 10 Grub 2 Linux boot loader ● Grub 2 is the default boot loader of most Linux distributions ○ There are others, but most of them don’t work well with UEFI. ● Grub 2 supports legacy BIOS boot, Legacy network boot (pxe), UEFI boot, UEFI network and boot UEFI secure boot. ○ With different grub 2 binaries. ● Can provide an interactive boot menu. ● Has a programmable configuration file syntax. ● Has support for multiple Linux filesystems ○ Including virtual block devices, like logical volume management and RAID. ○ Can open and boot encrypted Linux partitions (rarely used however). ● Has a command line and an editor from on the fly modification of configuration Linux system administration, 2nd slide set © Jani Jaakkola 2019 11 Grub 2 boot process 1. Firmware starts the grub binary 2. Grub reads its configuration file grub.cfg 3. The configuration file provides a boot menu (if any) 4. A menu entry is booted: manually selected or default entry after a timeout. 5. Grub loads Linux kernel image specified in the menu entry to memory 6. Grub loads initrd specified in the menu entry to memory 7. Grub passes arguments to the kernel and starts it ● Kernel arguments can be read from /proc/cmdline Linux system administration, 2nd slide set © Jani Jaakkola 2019 12 Grub configuration and installation ● Grub is installed to a disk with the command grub-install <disk> ● Grub configuration /boot/grub/grub.cfg is normally automatically generated by the distribution. ○ Including the ability to boot to other OS like Windows, or other Linux installations. ○ You can write your own however. ● A new file is generated whenever there is a new kernel installed. ○ Or Grub is upgraded to a newer version. ● In Ubuntu and Debian this happens with the script update-grub ○ There are hooks to modify and add boot entries of your own. ● You need to modify grub configuration when: ○ You want to boot non distribution kernels or other operating systems. ○ You want to modify kernel boot arguments. Linux system administration, 2nd slide set © Jani Jaakkola 2019 13 Initial ramdisk - initrd ● Initrd is a small complete boot time Linux system. ○ It is loaded to memory by boot loader and then uncompressed and started by the Linux kernel. ● Initrd contains drivers and configuration for the installed system. ○ Initrd is specific to the system where it is started. ○ Only drivers which are needed during the boot are added to initrd. ■ Disc drivers, filesystem drivers, logical file system drivers. ● Can provide a splash screen when booting (with Plymouth scripting) ● Initrd scans the system and locates the root device directory / ○ Opening encrypted root file system is (usually) managed by initrd. ○ And the starts /sbin/init from the root file system ● After initrd has done its job, its memory is freed. ● Created with mkinitramfs (Ubuntu, Debian) or dracut (Red Hat) Linux system administration, 2nd slide set © Jani Jaakkola 2019 14 /sbin/init ● The first process to start in a Linux (and Unix) system is /sbin/init ○ Started right after initrd has mounted root filesystem and gone away. ● Init starts all the other daemons and configuration scripts needed for a working system. ○ Mount other file systems. ○ Start getty on virtual consoles and serial terminals to enable logins. ○ Start network configuration. ○ Start sshd. ○ ... ● Init always has process id (PID) 1. ○ Traditionally you communicated with init by sending signals to PID 1. Linux system administration, 2nd slide set © Jani Jaakkola 2019 15 SysVinit ● Ancient: Introduced by AT&T at UNIX system III at 1981. ● The system had 6 different runlevels. ○ However only few were actually used by Linux systems. ○ 1: single user mode (rescue mode) ○ 3: multi user mode ○ 5: graphical GUI mode with X server ○ 6: reboot ● The services that start and stop during startup are determined by the runlevel. ○ Every runlevel has a directory /etc/rcX.d which contains scripts that start services and daemons ○ Services are started sequentially in lexicographical order. ○ This is slow and prone to hangs when a service does not start. ● SysVinit is not used anymore in 2019. Old scripts might still exist though. Linux system administration, 2nd slide set © Jani Jaakkola 2019 16 Upstart and Devuan project ● Ubuntu wanted to replace SysVinit with something more modern: upstart ● Upstart was still in use in Ubuntu 14.04 installations, but was later replaced by systemd. ● Devuan project was established to provide a Linux distribution with old SysVinit and no systemd. Linux system administration, 2nd slide set © Jani Jaakkola 2019 17 Systemd Linux system administration, 2nd slide set © Jani Jaakkola 2019 18 Systemd ● Systemd has replaced init and most other system daemons in Linux distributions ○ Which is a the exact opposite of the old Unix philosophy: Do one thing and do it well.