Booting Process
When you turn on or restart a computer, the Linux booting process begins. The key steps in this process are:
- BIOS/UEFI: The computer’s firmware (BIOS or UEFI) runs a power-on self-test (POST) and initializes hardware components.
- Bootloader: The bootloader (commonly GRUB) is loaded, presenting a menu if multiple operating systems are installed.
- Kernel Loading: The bootloader loads the Linux kernel (vmlinuz) into memory.
01. BIOS / UEFI
BIOS and UEFI are firmware interfaces that computers use to boot up the operating system (OS).
02. BOOT LOADER
The boot loader is a small program that loads the operating system
03. KERNEL
After going through BIOS or UEFI, POST, and using a boot loader to initiate the kernel.
04. SYSTEMD
The parent of all Linux processes is Systemd.
05. RUN LEVELS
In Linux, the run level stands for the current state of the operating system.
01. BIOS / UEFI
First, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) program kicks in once the system powers up. Usually, the BIOS contains all the code to gain initial access to the main machine devices:
- keyboard
- display screen
- disk drives
- serial communications
However, most of these devices will have dedicated device drivers taking over once the system boots fully.
BIOS and UEFI are firmware interfaces that computers use to boot up the operating system (OS). Yet, the two programs differ in how they store metadata on and about the drive:
- BIOS uses the Master Boot Record (MBR)
- UEFI uses the GUID Partition Table (GPT)
Next, the BIOS or UEFI runs the power-on self-test (POST). The POST does a series of tasks:
- verify the hardware components and peripherals
- carry out tests to ensure that the computer is in proper working condition
Further, if this test finds any error, it commonly shows an error message on the screen. In case the test fails to detect the RAM, POST triggers a beeping sound.
Finally, if the system passes the POST, it signals the start-up process to the next stage.
Here are some commands to check whether your Linux Debian system is running in BIOS or UEFI mode, you can use various methods, including checking the partition scheme, examining system logs, or using command-line utilities.
02. Boot Loader
The boot loader is a small program that loads the operating system. The main job of the boot loader is to perform three actions with the kernel: locate on the disk, insert into memory, and execute with the supplied options.
The following are some of the available boot loaders for a Linux system:
- LILO
- SYSILINUX
- GRUB2
Above are some fundamental aspects of Linux and its system startup process. The specific commands and procedures may vary slightly depending on the Linux distribution you’re using, but these principles apply broadly to most Linux systems. Learning these basics is essential for effective Linux administration and usage.
To check which boot loader is currently being used on your Debian Linux system, you can use various commands and methods. Here are some common ways to do it:
02.1 LILO
Initially, LILO (Linux Loader) was one of the most widely used Linux boot loaders. However, it has lost favor because it has no support for multi-boot environments and for UEFI. Also, it has limited support for new filesystems. Officially, the developers of LILO halted its development and support in December 2015. Hence, the Linux Loader is old and mostly obsolete.
02.2 SYSLINUX
Equally, SYSLINUX is a boot loader for the Linux operating system, which runs on a FAT filesystem, typical for a Windows system. In short, its goal is to ease the process of installing Linux for the first time.
Further, SYSLINUX supports several major filesystems:
- FAT
- ext2
- ext3
- ext4
In addition, SYSLINUX can support Btrfs and XFS filesystems with some constraints.
02.3 GRUB2
Despite the many choices, almost all (non-embedded) modern Linux distributions use GRUB (GRand Unified Boot Loader) because it’s very feature-rich:
- ability to boot multiple operating systems
- boots both a graphical and a text-based interface
- allows ease of use over a serial cable
- strong command line interface for interactive configuration
- network-based diskless booting
Presently, GRUB2 has replaced its past version (GRUB), which is now known as GRUB Legacy. Importantly, we can check for the GRUB version in our system using the following command:
Initially, GRUB Legacy had three stages in the boot process:
- Stage 1
- Stage 1.5
- Stage 2
However, with GRUB2, these stages don’t exist anymore. Instead, it contains various *.img files that serve similar functions.
At this point, GRUB2 inserts the kernel into memory and turns control of the system over to the kernel.
03. Kernel
After going through BIOS or UEFI, POST, and using a boot loader to initiate the kernel, the operating system now controls access to our computer resources.
Here, the Linux kernel follows a predefined procedure:
- decompress itself in place
- perform hardware checks
- gain access to vital peripheral hardware
- run the init process
Next, the init process continues the system startup by running init scripts for the parent process. Also, the init process inserts more kernel modules (like device drivers).
04. Systemd
To reiterate, the kernel initiates the init process, which starts the parent process. Here, the parent of all Linux processes is Systemd, which replaces the old SysVinit process. Following the booting steps, Systemd performs a range of tasks:
- probe all remaining hardware
- mount filesystems
- initiate and terminate services
- manage essential system processes like user login
- run a desktop environment
Indeed, these and other tasks allow users to interact with the system. Lastly, Systemd uses the /etc/systemd/system/default.target file to decide the state or target the Linux system boots into.
SystemD, is a recent initialization system that aims to replace SysVInit. In fact, most Linux distributions such as Debian and Red Hat are already using SystemD as their init system out of the box. In contrast to SysVInit, SystemD continues to run as a daemon process after the initialization is completed. Additionally, they are also actively tracking the services through their cgroups. The systemctl command is the entry point for users to interact and configures the SystemD.
To check the status and information about systemd in Debian, you can use various commands and tools. Here are some common ways to check systemd:
05. Run Levels
In Linux, the run level stands for the current state of the operating system. Run levels define which system services are running. Previously, SysVinit identified run levels by number. However, .target files now replace run levels in Systemd.
Further, Systemd activates the default.target unit by default when the system boots. Let’s check our default target:
root@ipxpy:~# journalctl -xe
Sep 19 10:13:50 ipxpy systemd[1]: session-3.scope: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit session-3.scope has successfully entered the 'dead' state.
Sep 19 10:13:50 ipxpy systemd-logind[380]: Session 3 logged out. Waiting for processes to exit.
Sep 19 10:13:50 ipxpy systemd-logind[380]: Removed session 3.
-- Subject: Session 3 has been terminated
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A session with the ID 3 has been terminated.
Sep 19 10:15:53 ipxpy sshd[602]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.102 user=root
Sep 19 10:15:55 ipxpy sshd[602]: Failed password for root from 192.168.0.102 port 63420 ssh2
Sep 19 10:16:33 ipxpy sshd[602]: Accepted password for root from 192.168.0.102 port 63420 ssh2
Sep 19 10:16:33 ipxpy sshd[602]: pam_unix(sshd:session): session opened for user root by (uid=0)
Sep 19 10:16:33 ipxpy systemd-logind[380]: New session 4 of user root.
-- Subject: A new session 4 has been created for user root
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A new session with the ID 4 has been created for the user root.
--
-- The leading process of the session is 602.
Sep 19 10:16:33 ipxpy systemd[1]: Started Session 4 of user root.
-- Subject: A start job for unit session-4.scope has finished successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit session-4.scope has finished successfully.
--
-- The job identifier is 390.
Sep 19 10:17:01 ipxpy CRON[780]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 19 10:17:01 ipxpy CRON[781]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 19 10:17:01 ipxpy CRON[780]: pam_unix(cron:session): session closed for user root
Sep 19 11:17:01 ipxpy CRON[806]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 19 11:17:01 ipxpy CRON[807]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 19 11:17:01 ipxpy CRON[806]: pam_unix(cron:session): session closed for user root
Sep 19 12:17:01 ipxpy CRON[828]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 19 12:17:01 ipxpy CRON[829]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 19 12:17:01 ipxpy CRON[828]: pam_unix(cron:session): session closed for user root
root@ipxpy:~#