Chapter 15
The Boot Process
In this chapter, you learn about making tasks into services that run as your system starts and making them into services you can start and stop by hand. You also learn about the entire boot process.
After you turn on the power switch, the boot process begins with the computer executing code stored in a chip called the BIOS, or basic input/output system; this process occurs no matter what operating system you have installed. The Linux boot process begins when the code known as the boot loader starts loading the Linux kernel and ends when the login prompt appears.
As a system administrator, you will use the skills you learn in this chapter to control your system’s services and manage runlevels on your computer. Understanding the management of the system services and states is essential to understanding how Linux works (especially in a multiuser environment) and helps untangle the mysteries of a few of your Ubuntu system’s configuration files. Furthermore, a good knowledge of the cron daemon that handles task scheduling is essential for administrators at all skill levels, so you will want to combine this knowledge with what you learned in Chapter 14, “Automating Tasks and Shell Scripting.”
Running Services at Boot
Although most people consider a computer to be either on or off, in Ubuntu and Linux in general, there are a number of states in between. Known as runlevels, they define what system services are started upon boot. These services are simply applications running in the background that provide some needed function to a system, such as getting information from the mouse and sending it to the display; or a service could monitor the partitions to see whether they have enough free space left on them. Services are typically loaded and run (also referred to as being started) during the boot process, in the same way as Microsoft Windows services are. For a while, Ubuntu used a system known as Upstart instead of the classic and venerable SysVinit; Upstart had a special backward-compatibility layer that could use runlevels in the way that Linux veterans are accustomed to doing for services not otherwise handled by Upstart. Starting in 2015, Ubuntu switched to another system called systemd. You’ll learn more about runlevels, Upstart, and systemd later in this chapter.
Init Systems
There are many ways to describe init systems, but this quote from a thread at Reddit.com is hard to beat (capitalization and spelling errors are from the original):
“To understand the fuss, there are 3 init systems that you should be aware of: sysvinit, upstart and systemd. SysVinit is really old, outdated and only allows for a sequential startup of services, that is, all services started by init must wait for the previous service to have completed their startup process before the next can startup. Both upstart and systemd are designed to tackle the limitations of init, and allows for concurrent service initialization, that is, multiple services can startup at the same time, as long as they are not dependent on each other, and allows taking advantage of multi core processing. They also allow for services to startup and shutdown for specific events, such as a network connection going up or another service has started. Upstart was developed by Canonical was initially released in 2006 and was used in Ubuntu, Debian, Fedora, RHEL, CentOS, and many others. Systemd is a much younger system that was initially released in 2011, however, most major distros has already migrated to using systemd by default.
“Both Upstart and Systemd are event based, however their architecture and configuration setup are very different and this is where the worrying comes from. If the configurations aren’t ported correctly then systems are going to behave differently to what’s expected and this can lead to issues for many users.”
—hitsujiTMO in www.reddit.com/r/Ubuntu/comments/2yeyyi/grab_your_pitchforks_ubuntu_to_switch_to_systemd/cp92iro
You can manage nearly every aspect of your computer and how it behaves after booting via configuring and ordering boot scripts and by using various system administration utilities included with Ubuntu. In this chapter, you learn how to work with these boot scripts and system administration utilities. This chapter also offers advice for troubleshooting and fixing problems that might arise with software configuration or the introduction or removal of various types of hardware from your system.
Beginning the Boot Loading Process
Although the actual boot loading mechanism for Linux varies on different hardware platforms (such as SPARC, Alpha, and PowerPC systems), Intel-based PCs running Ubuntu most often use the same mechanism throughout product lines. This process is traditionally accomplished through a BIOS. The BIOS is an application stored in a chip on the motherboard that initializes the hardware on the motherboard (and often the hardware that’s attached to the motherboard). The BIOS gets the system ready to load and run the software that we recognize as the operating system.
As a last step, the BIOS code looks for a special program known as the boot loader or boot code. The instructions in this little bit of code tell the BIOS where the Linux kernel is located, how it should be loaded into memory, and how it should be started.
If all goes well, the BIOS looks for a bootable volume such as a CD-ROM, hard drive, RAM disk, USB drive, or other media. The bootable volume contains a special hexadecimal value written to the volume by the boot loader application (such as Ubuntu’s default, GRUB2) when the boot loader code was first installed in the system’s drives. The BIOS searches volumes in the order established by the BIOS settings (for example, USB first, followed by a DVD-ROM, and then a hard drive) and then boots from the first bootable volume it finds. Modern BIOSs allow considerable flexibility in choosing the device used for booting the system.
Note
If the BIOS detects a hardware problem, the boot process fails, and the BIOS generates a few beeps from the system speaker. These “beep codes” indicate the nature of the problem the BIOS has encountered. The codes vary among manufacturers, and the diagnosis of problems occurring during this phase of the boot process is beyond the scope of this book and does not involve Linux. If you encounter a problem, consult the motherboard manual or contact the manufacturer of the motherboard. Another good source for learning about beep codes is www.computerhope.com/beep.htm.
Next, the BIOS looks on the bootable volume for boot code in the partition boot sector, also known as the master boot record (MBR), of the first hard disk. The MBR contains the boot loader code and the partition table; you can think of it as an index for a book, plus a few comments on how to start reading the book. If the BIOS finds a boot loader, it loads the boot loader code into memory. At that point, the BIOS’s job is completed, and it passes control of the system to the boot loader.
As computing evolved, the BIOS began to be a limiting factor because some of its limitations were not easy to overcome. Intel was the first company to notice this as it developed its Itanium systems in the late 1990s. That work eventually became the foundation for the Unified Extensible Firmware Interface (UEFI).
UEFI serves a similar role to BIOS and has replaced BIOS in most modern systems. For most end users, the difference is negligible, except that if you have a UEFI computer, you may need to do some research to install Ubuntu. UEFI firmware often has a BIOS mode that allows the firmware to work like a traditional BIOS and that is more easily compatible, especially if you are installing Ubuntu as the sole operating system on the computer rather than as a dual-boot. There were some significant problems early on, but they seem to have lessened as the Linux community has learned more about UEFI and made things more easily compatible. To learn more, especially if you are having trouble, see https://help.ubuntu.com/community/UEFI.
One interesting aspect of using UEFI involves hard disk partitioning. When UEFI is used with Windows 8.x or 10, often the partitioning is set up using GPT (GUID Partition Table) rather than the existing MBR standard. You can use GPT with Ubuntu, but if only Ubuntu is to be installed on the drive, reformatting the hard disk to use MBR is often easier. As with BIOS and UEFI, most people do not need to know or care whether they are using MBR or GPT. To learn more, see www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive/. If the system has a UEFI BIOS, GRUB is stored as an EFI application on the EFI system partition and not the MBR/GPT.
The boot loader locates the Linux kernel on the disk and loads it into memory. After that task is completed, the boot loader passes control of the system to the Linux kernel. You can see how one process builds on another in an approach that enables many different operating systems to work with the same hardware.
Note
Linux is very flexible and can be booted from multiple images on a CD-ROM, over a network using PXE (pronounced “pixie”) or NetBoot, or on a headless server with the console display sent over a serial or network connection. Work is even under way at www.coreboot.org to create a special Linux BIOS that will expedite the boot process because Linux does not need many of the services offered by the typical BIOS.
This kind of flexibility enables Linux to be used in a variety of ways, such as for remote servers or diskless workstations, which are not generally seen in personal home use.
Loading the Linux Kernel
In a general sense, the kernel manages the system resources. As the user, you do not often interact with the kernel, but instead you interact with the applications you are using. Linux refers to each application as a process, and the kernel assigns each process a number called a process ID (PID). Traditionally, the Linux kernel loads and runs a process named init, which is also known as the “ancestor of all processes” because it starts every subsequent process. The traditional init system was SysVinit. It has been replaced by newer options. One of these options was Upstart, which was written by Ubuntu developers and made available for any distribution to use. Upstart was replaced by systemd as of Ubuntu 15.04. This chapter walks through the traditional SysVinit method first and then provides details on Upstart and systemd.
The next step of the boot process traditionally begins with a message that the Linux kernel is loading and a series of messages that are printed to the screen, giving the status of each command. A failure should display an error message. The quiet option may be passed to the kernel at boot time to suppress many of these messages. Ubuntu does not display these messages by default but instead uses a boot process created by the Fedora/Red Hat developers called Plymouth that is fast and incorporates a beautiful boot screen.
If the boot process were halted at this point, the system would just sit idle, and the screen would be blank. To make the system useful for users, you need to start the system services. Those services are some of the applications that enable you to interact with the system.
Starting and Stopping Services with systemd
Ubuntu uses systemd as a modern replacement for init. It was created by Red Hat and has seen near-universal adoption across Linux distributions. The job of systemd is to manage services that run on the system and is comprised of a set of basic building blocks.
systemd is the mother of all processes and is responsible for bringing the Linux kernel up to a state where work can be done. To do this, it starts by mounting the file systems that are defined in /etc/fstab, including swap files or partitions.
From here, the configuration files in /etc are available and are loaded, starting with the configuration file for systemd itself at /etc/systemd/system/default.target, which is actually just a symbolic link to the actual .target file, which depends on how the system is set up.
For a typical desktop system, that symlink will point to the graphical.target file. For a server, it will likely point to multi-user.target, which is command line only. There are other target files, which loosely correspond to SystemV runlevels, as shown in Table 15.1.
Table 15.1 Systemd Targets and How They Relate to SystemV Runlevels
|
|
SystemV Runlevel |
Description |
|---|---|---|---|
|
|
|
This is a symlink to whichever of the following targets is set to load by default. |
|
|
5 |
For a desktop system, this is the default and loads a multiuser system with a GUI. |
|
|
3 |
This will load and run all services for a multiuser system but is command line only. This is typical for a server. |
|
|
S |
Loads single-user mode with no running services, no mounted file systems, and only an emergency shell. |
|
|
1 |
Loads a base system with basic services running, mounted file systems, and a rescue shell. |
|
|
|
Halts the system without powering down. |
|
|
0 |
Halts the system and powers down. |
|
|
6 |
Reboots the system. |
|
|
2 |
Boots a multiuser system with all non-GUI services running except NFS (network file system). |
|
|
4 |
Unused by systemd. |
Using these targets and target aliases, you can change the running mode similar to how in the past we would change runlevels using SystemV init commands. When systemd is engaged during the boot process, it uses the set target to discover and load expected dependencies, the services required to run the Linux system at the expected level of functionality.
To change the system state using target files, use the following commands (see Table 15.2):
Table 15.2 systemd State-Related Commands
Command |
Description |
|---|---|
|
Lists the currently set default target |
|
Changes the default to a different target; for example, replace |
|
Changes to a different target; this is like changing runlevel in SystemV. |
|
Lists the dependencies of a specific target, which is a good idea before you run an |
After the base services are loaded and running, systemd will also load any user-defined services. All of these services are called units. To list every available unit file on your system, use
$ systemctl list-unit-files
A word of warning: The output will include hundreds of unit files in the listing. On the positive side, it will tell you whether each one is enabled, disabled, or in some other state. States include
▸ disabled, which means it is not currently available.
▸ enabled, which means it is currently available.
▸ masked, which means the unit file has been marked as unstartable and is linked to /dev/null. This prevents a unit file from being started, either automatically or manually, until it is unmarked.
▸ static, which means the unit file does not include an “install” section, which is necessary to enable a unit; these are usually not meant to be run by users and generally perform a one-time action in the startup process or work as a dependency of another unit and are not intended to be run alone. To interact with systemd, you typically use the systemctl command. The main interactions you are likely to have with systemd involve starting and stopping services. Table 15.3 shows commands related to services.
Table 15.3 systemd Service-Related Commands
Command |
Description |
|---|---|
|
List running services |
|
Start a service |
|
Stop a service |
|
Restart a service |
|
Reload a service (this only tells the service to reload its configuration files, rather than restart the entire service; typically, restarting is a safer option) |
|
Show the status of a service |
|
Restart a service if it is already running |
|
Enable a service at startup |
|
Disable a service at startup (typically to remove a service from the list of those starting automatically at boot) |
|
Make a service unavailable for use |
|
Make a service available for use again |
A few standard commands are replaced in systemd, including the ones listed in Table 15.4.
Table 15.4 Other systemd Commands
Command |
Description |
|---|---|
|
Halt the system |
|
Reboot the system |
|
Display the unit file for a service |
|
Display the dependencies for a service |
|
Display the low-level properties of a service, anything that is set using a key=value format |
|
Temporarily edit a service file just in memory |
|
Permanently edit a service file; to remove any changes you have made, delete the unit’s |
|
Follow the system log file; replaces |
Services are defined in systemd unit files, which end with .service. Many examples of these are found in /lib/systemd/system.
There is much more to learn about systemd than is appropriate for a book with such a wide range of topics to cover—especially as few people need to know more than is covered here. See the official documentation listed in “References” section to learn more if you find yourself in need.
Controlling Services at Boot with Administrative Tools
You can configure what services run at startup with Startup Applications Preferences (shown in Figure 15.1). Here Ubuntu lists all the services that you can have automatically start at boot time. Checked programs are enabled by default, but you can uncheck the ones you don’t want. Disabling services randomly “to make things go faster” is not recommended. Some services might be vital for the continuing operation of your computer, such as the graphical login manager and the system communication bus.
FIGURE 15-1 You can enable and disable Ubuntu’s boot services by toggling the check boxes in the Startup Applications Preferences dialog box.
Troubleshooting Runlevel Problems
Reordering or changing system services is rarely necessary when using Ubuntu unless some disaster occurs, but system administrators should have a basic understanding of how Linux boots and how services are controlled to perform troubleshooting or diagnose problems. By using utilities such as the dmesg | less command to read kernel output after booting or by examining system logging with cat /var/log/syslog | less, it is possible to gain a bit more detail about what is going on when faced with troublesome drivers or service failure.
Boot-Repair
Sometimes, such as when you install both Windows and Ubuntu on the same hard drive, boot problems can develop. Boot-Repair is a simple GUI tool you can use to fix such problems. Typically, it just reinstalls GRUB2, but using Boot-Repair is a much easier solution for many users. The program is not yet in the Ubuntu repositories, although plans for including it have been discussed. In the meanwhile, should you need it, take a look at https://help.ubuntu.com/community/Boot-Repair or the official documentation at https://sourceforge.net/projects/boot-repair/.
References
▸ /usr/src/linux/init/main.c—A file that appears on your computer after you install the kernel source code, which is the best place to learn about how Linux boots
▸ https://help.ubuntu.com/community/Grub2—Ubuntu community documentation for GRUB2
▸ https://wiki.freedesktop.org/www/Software/systemd/—The official system documentation