LPI Linux Certification/Boot the System
101.2 Boot the system
edit(LPIC-1 Version 5.0)
Weight: 3
Description:
Candidates should be able to guide the system through the booting process.
Key Knowledge Areas:
- Provide common commands to the boot loader and options to the kernel at boot time
- Demonstrate knowledge of the boot sequence from BIOS/UEFI to boot completion
- Understanding of SysVinit and systemd.
- Awareness of Upstart.
- Check boot events in the log files
The following is a partial list of the used files, terms and utilities:
dmesg
journalctl
- BIOS
- UEFI
- bootloader
- kernel
initramfs
init
- SysVinit
systemd
Boot Process Overview
editWhen a typical PC is powered on, the BIOS (Basic Input Output Service) detects hardware devices including hard drives and goes through a boot priority list. Assuming we are booting from a hard drive, it will execute the first 512 bytes of code from the first boot disk's MBR (stage1 bootloader). The stage1 boot loader is very basic and its function is to load the stage2 (or stage1.5 in some cases) boot loader. The next step depends on the type of bootloader being used. There are 2 popular boot loaders in Linux: LILO and GRUB
LILO (LInux LOader) is an older boot loader and modern Linux distributions use GRUB rather than LILO but it might still be in use on older systems. When LILO stage2 boot loader is loaded, depending on configuration, it might display a menu that allows a user to specify kernel options. Once kernel options are specified GRUB loads the kernel and initrd and executes the kernel passing any parameters specified by the user. It is important to remember that LILO is not filesystem aware so kernel and initrd are loaded from a predefined location on the hard drive.
GRUB (GRand Unified Bootloader) is a newer and more flexible boot loader. When stage1.5 is loaded it reads /boot partition and loads the stage2 bootloader from there. The stage2 bootloader reads configuration from /boot/grub/grub.conf (RedHat based distributions) or menu.lst (Debian based distributions) and presents user with options (if configured to do so). When the choice is made it loads kernel and initrd from /boot/ partition and executes it passing any options passed by user.
When the kernel loads it detects devices. One of the tasks it has to perform is to mount the root partition. If required hardware and filesystem support is built into the kernel it can be done immediately and /sbin/init program is loaded. This situation is very rare and majority of modern systems will require dynamically loaded modules to be loaded into the kernel in order to mount the root partition. These modules are contained within initial RAM disk (initrd). Once the root partition is ready the kernel runs /sbin/init program which continues to load the operating system.
/sbin/init is the first process started by the kernel and it becomes parent of all other processes. Usually it reads /etc/inittab configuration file however, some newer alternatives like upstart are not using this file any more. In RedHat based system init will execute /etc/rc.d/rc.sysinit and in Debian based systems /etc/init.d/rcS. This script will mount partitions and perform basic system setup. Next it will run all scripts located in /etc/rcX.d/ where X is runlevel number. This could be the default specified in /etc/inittab file or the number provided by administrator as kernel parameter. The last script to run is /etc/rc.local which can be used to add system specific initialization steps. Once this script is executed boot process is complete.
Bootloaders Configuration
editLILO is older boot loader and has some limitations. One of them is the fact that kernel and initrd locations are hardcoded into stage2 bootloader. It means that every time new kernel image is added, administrator has to run /sbin/lilo command to reinstall LILO; configuration file used by the /sbin/lilo executable is located in /etc/lilo.conf and might look like:
#begin LILO global section boot=/dev/hda bitmap=/boot/image.bmp bmp-colors=255,0,255,0,255,0 append="vt.default_utf8=0" map=/boot/System.map install=/boot/boot.b prompt timeout=50 #VESA framebuffer console @ 1246x768x256 vga=773 #end LILO global section #Linux bootable partition config begins image=/boot/vmlinuz-2.0.36 label=linux root=/dev/hda2 read-only #Linux bootable partition config ends #second bootable partition config begins...
- boot - this parameter specifies where LILO will be installed. In example above it will be MBR of /dev/hda disk. (or in some cases /dev/sda).
- bitmap - it will append a custom background image for your distribution.
- bmp-colors - it will set other background color scheme to the loader.
- append - will provide any additional commands to the kernel during boot for a specific setup, adding or removing a kernel feature or module.
- map - the map file is automatically generated by LILO and is used internally. It is recommended not to change this option.
- install - specifies which image to use for boot sector. Again it is not recommended to change this parameter.
- prompt - this options enabled administrator to append kernel command line options when system boots.
- timeout - specifies prompt timeout in tenths of a second so in example above timeout is set to 5 seconds.
- vga - in some systems this will indicate what video resolution the boot process will be in.
- image - kernel location. (use different kernel names for separate boot sections)
- label - name which will be displayed in LILO menu during boot.
- root - root filesystem location.
- read-only - see kernel parameters section below
Grub offers many benefits over LILO. One of them is fact that it offers bash-like command line which can be used to dynamically change kernel or initrd image used. Sample configuration file is listed below:
default 0 timeout 5 title Debian GNU/Linux, kernel 2.6.26-2-686 root (hd0,0) kernel /vmlinuz-2.6.26-2-686 root=/dev/mapper/Disk-root ro quiet initrd /initrd.img-2.6.26-2-686
First line specifies default image, in this case image number 0 which is the only one configured. Second line specifies prompt timeout in seconds. If it is set to 0 grub will immediately boot default image without any prompt. Next 4 lines define menu entry:
- title - name of menu entry
- root - partition on which to find kernel and initrd. In example above (hd0,0) is first partition on the first disk
- kernel - kernel image to be loaded together with kernel parameters. Kernel's location is relative to the top of root partition, usually /boot (do not confuse with linux root partition or /)
- initrd - initial ramdisk image.
It is common for grub to contain many title/root/kernel/initrd sets for different kernel versions.
Kernel Parameters
editAs mentioned above kernel requires some arguments which can be configured in grub, LILO or dynamically appended by user during system startup. List of common kernel parameters below:
- root=<disk> - specifies root filesystem which will be mounted as /. It can be partition (ie. root=/dev/sda2), disk label (root=LABEL=root_partition) or logical volume (root=/dev/mapper/vg_root-root)
- ro or read-only - instructs the kernel to mount root filesystem as read only. This allows filesystem to be checked before partition is remounted read-write. This option is used in almost all cases
- quiet - do not print diagnostic messages to the screen
- single - boot system into single user mode (runlevel 1)
- console= - tells kernel to send output to console. For example to send it to serial port use console=/dev/ttyS0
- init=/ - can be used to specify replacement for /sbin/init process for example to get root shell without password use init=/bin/bash
Checking Logs
editAll kernel messages diagnostic messages are send to kernel ring buffer. Its content can be reviewed using dmesg command, however the output can tedious and is best to use dmesg | less, use arrow keys to scroll verticle and Q to exit dmesg. Bear in mind that this buffer has limited capacity and when new messages come in the oldest ones could be removed. Once all partitions are mounted one of init scripts will write content of kernel buffer to a logfile, normally /var/log/messages so that diagnostic messages are available when needed.