Boot Process and Systemd

The Linux boot process is a sequence of events that starts with the hardware powering on and ends with the operating system ready for use. Understanding this sequence is critical for LPIC-1 because you will need to troubleshoot problems that occur at each stage.

The first step is the Power-On Self-Test (POST). When you press the power button, the computer’s firmware—either Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI)—runs a quick check on hardware components like RAM, the CPU, and storage devices. If everything passes, the firmware looks for a boot device, typically a hard drive or SSD, to load the next stage.

The firmware then loads the boot loader from the Master Boot Record (MBR) or GUID Partition Table (GPT) on the storage device. The most common Linux boot loader is GRUB (Grand Unified Bootloader). GRUB presents a menu of operating systems or kernel versions to boot. If you do not select anything, GRUB loads the default option after a timeout. GRUB knows where the kernel is located on the disk and loads the kernel image into memory, along with the initial RAM disk (initrd or initramfs).

The kernel is the core of the operating system. It manages hardware, memory, and processes. Once the kernel is loaded, it decompresses itself and begins initialising essential subsystems. At this point, the kernel hands over control to the first userspace process, which is the init system.

On modern Linux distributions, the init system is systemd. Systemd is responsible for starting all other processes in the correct order, based on dependencies. It uses unit files to define services, sockets, and other resources. The first unit systemd starts is typically 'systemd-sysinit.service', which handles basic system setup like mounting filesystems and setting the hostname. Then systemd activates 'basic.target' and 'multi-user.target', which sequentially start all the services needed for a fully operational system.

Systemd is not the only init system that ever existed. Older Linux distributions used SysV init, which was a collection of shell scripts that ran in a numbered sequence. SysV init was simple but slow because scripts ran one after the other with no parallel execution or dependency checking. Systemd introduced parallelism, on-demand service activation, and centralised logging via journald. It also introduced the concept of targets, which are groups of units that represent system states. For example, 'graphical.target' includes everything in 'multi-user.target' plus the display manager.

To manage services with systemd, the main command is 'systemctl'. With 'systemctl', you can start, stop, restart, enable, disable, and check the status of services. For example, 'systemctl start sshd' starts the SSH daemon. 'systemctl enable sshd' configures it to start automatically on boot. 'systemctl status sshd' shows whether the service is running, its process ID, and recent log entries. Understanding these commands is essential for LPIC-1 because exam questions will present scenarios where you must determine the correct command to control a service.

Systemd also includes tools like 'journalctl' for viewing logs, 'systemd-analyze' for profiling boot performance, and 'systemctl list-units' for listing all active units. The boot process now includes systemd's own sequence of targets: 'default.target' is the target that the system boots into, usually linked to 'graphical.target' or 'multi-user.target'. The boot sequence can be customised by changing this target or by masking or disabling services.

It is important to know that the boot process can fail at various points. Common failures include a damaged boot loader, a missing kernel, a corrupted initramfs, or a systemd unit that fails to start. You can troubleshoot these issues by booting into single-user mode or rescue mode, editing GRUB parameters at boot time, or using a live CD to repair the system. The LPIC-1 exam expects you to understand the order of the boot process and the role of each component so that you can diagnose and fix problems.

An IT professional at a small company manages a Linux web server that hosts the company’s public website. One morning, users report that the site is unreachable. The IT pro opens a terminal and uses SSH to connect to the server, but the connection fails. They then use a remote console provided by the hosting provider to gain direct access to the machine.

The server has booted but the login prompt is not appearing. The IT pro suspects a boot failure. They reboot the server and watch the console output. The boot process stops at a message saying 'A start job is running for Network Manager' and then a timeout occurs. The systemd service for networking is hanging.

The IT pro needs to fix this. They cannot run normal commands because the system is in a degraded state. They reboot again and during the GRUB menu, they press 'e' to edit the boot parameters. They add 'systemd.unit=rescue.target' to the kernel command line. This tells systemd to boot into a minimal environment without network services. The system boots successfully into rescue mode.

Now the IT pro can use systemctl commands to diagnose the problem:

In another scenario, the IT pro is deploying a new application server. They need to ensure that a custom service called 'webapp' starts automatically after the database service. They create a systemd unit file called 'webapp.service' with a line 'After=postgresql.service' and 'Requires=postgresql.service'. Then they run:

The IT pro then monitors the service using 'systemctl status webapp.service' and 'journalctl -fu webapp.service' to follow logs in real time. This is a routine part of managing modern Linux servers.