[custom-header-login]
During this LPI objective, we are going to look at Booting Linux x86 systems, 32 bit and 64 bit. Understanding the Linux boot process becomes useful in troubleshooting boot issues and become very practical as well as an exam objective. The boot process can be broken down into smaller steps. During the system startup, we can observe these steps listed in the follwing:
- POST
- Load MBR
- Boot Loader
- Kernel Load
- init start
Power on Self Test
The POST ( Power On Self Test ) phase of a computer involves a lot of flashing and beeping that you will observe the device making during the early boot phase. This is controlled by the computer BIOS ( Basic Input Output System ), the hardware is checked, the disks the RAM (Random Access Memory), keyboard, etc. The output may be in the form of text messages displayed on the screen or my decoding the number of beeps. As the hardware is checked the BIOS will indicate the boot device, the disk to stat up from. This is usually the first hard disk but could be the Network Card, DVD, USB etc. If we are booting Linux from the primary hard disk in the device we will connect to the disk and locate the Master Boot Record.
Master Boot Record
The MBR of a disk is the first 512 bytes of the disk, this has areas reserved for different purposes. Up to 446 bytes of the MBR can be used by the boot loader. 16 bytes can be used for each primary partition allowing there be a maximum of 4 primary partitions per disk. Once we have located the MBR we are able to load the bootloader into memory. This is used to specify the location of the Linux Kernel.
Boot Loader
The boot loader in Linux is typically GRUB. This has been used by many distributions for many years now. The Grand Unified Boot Loaded is often referred to now as legacy GRUB as more recently there has been an update to this GRUB2. For the exam you will be expected to be able to configure legacy GRUB and GRUB2; see objective 102.2 for more details on installing and managing the bootloader.
As with most software in Linux, you have a choice of bootloader. We are not limited to one and we can choose from common bootloasers listed here.
- LILO
- ELILO
- GRUB
- GRUB2
- PXELINUX
- SYSLINUX
- ISOLINUX
- EXTLINUX
Kernel and Initrd
The bootloader will point to a kernel, often stored in the /boot directory of the filesystem. The kernel is the Linux operating system and often is loaded in conjunction with an initrd file( initialization ram disk ). The initrd is loaded to give the kernel access to the root filesystem and the /lib directory. This is where the kernel modules or drivers are located. The kernel is often named vmlinuz followed by the version number:
If, as in the case of the above screenshot ,where you have more than one kernel on the system, you can verify the currently loaded kernel using the command uname -r or by listing the contents of the file /proc/version .
While we are still in the /proc directory we can use the file /proc/cmdline to show any command line options passed to the kernel at boot time.
The init Daemon and System
Once the kernel loads the first process that it will start is init, (/sbin/init). This is PID or Process ID 1 on CentOS 6.5 and earlier systems. On CentOS 7 systems and other newer distributions, PID 1 will be systemd. Process ID 1 is responsible for starting all other services on the host. We can display processes on a Linux system using the ps command or the process hierarchy with pstree.
The configuration file that controls the behavior of the init daemon is the /etc/inittab file. If the boot loader configuration does not specify a runlevel then the initdefault is used. This setting defines the default runlevel that the system should enter; this is typically 3 for text only server and 5 for the GUI environment. Runlevels are covered in more details in objective 101.3. If you are using a later Linux distribution then runlevels are replaced with targets but hold the same purpose.
The initdefault setting in the /etc/inittab defines the default runlevel that a Linux host should enter if it is not specified at boot time, here we default to the GUI runlevel 5.
Reporting on the boot process
During the boot process the we can view the boot process on the console but additionally it is logged to the file /var/log/boot.msg . This file is cleared at system shutdown so the contents of the file are always fresh on a new boot. On my system I see 561 lines currently produced during the boot process. This would vary on the amount of processes that are starting during the boot phase and drivers that need to load. Instead of trying to follow the output on the screen during boot we can look at the file after the boot process has completed to help us determine and resolve boot issues.
Similarly to the boot.msg file the command /bin/dmesg can be used to display the contents of the kernel ring buffer, (reserved memory for the kernel). This mainly relates to loading of drivers as hardware is activated, much of the activity related to booting a system, but additionally can show activity after the boot process has finished, such as when a new USB stick is added, or may be if the NIC fails ( Network card ) and the drivers reports no link activity detected on the network.
As we saw with the boot.msg file, logs files are classed as variable in size so are located in the /var structure, /var/log. The file /var/log/boot.msg show activity during the system startup but most activity is logged to the file /var/log/messages . Unlike the boot.msg file this log is not rotated for each new boot so holds historical information and is not restricted to just the boot process. When fault finding on a system the messages file is often a good place to start in trying to diagnose what is or isn’t happening on the system. Using the command /usr/bin/tail you can list the end of the file which will have the most recent entries.