Linux Basics : Demystifying the CentOS 7.x Boot Process

Introduction

Hello readers, the world of CentOS 7.x, it might seem like a another level of digital chaos. The BIOS kicks in – it's the system's wakeup call. MBR? That's the machine's heartbeat, a mere 512 bytes defining its existence. GRUB2 steps up, the gatekeeper dealing with /boot/grub2 – tweaking parameters is its game.

Now, initramfs is the real avant-garde, loading modules before the party starts. Dracut? It's the artist behind the scenes, crafting the connection between kernels and consciousness.

Kernel, is the maestro, firing up systemd – it's the grand organizer. Host names, networks, SELinux – all in a meticulous chaos of logic.

So, here we are, CentOS 7.x.

BIOS or Firmware phase:

Let's delve into the BIOS or Firmware phase – the initial steps in the symphony of CentOS 7.x booting.

The BIOS, or Basic Input/Output System, takes center stage, performing the crucial Power On Self Test (POST). This isn't a mere warm-up; it's a meticulous examination where the BIOS meticulously detects, tests, and initializes every hardware component in the system.

Once the hardware orchestra is tuned and ready, the BIOS proceeds to load the Master Boot Record (MBR).

Master Boot Record:

MBR, the first 512 bytes of the boot drive, stores the partition table and a small boot loader code. Within its confines, the MBR encapsulates essential information about the boot drive, including the partition table in the following 64 bytes. The last two bytes act as a checksum – a 'Magic Number' ensuring the integrity of the loaded data.

In the intricate dance of boot initiation, the MBR assumes the role of a detective. Its mission? Discover the bootable device, a crucial step in the system's quest for self-awareness. Having identified the protagonist, it gracefully passes the baton to the Grand Unified Bootloader (GRUB2), an adept conductor in this digital orchestra.

GRUB2 takes its place in memory, seizing control of the narrative.

GRUB2 Bootloader:

The default bootloader program used on RHEL 7 is GRUB 2. GRUB2 is the intermediary, bridging the hardware and the impending kernel.

The GRUB 2 configuration file, residing at /boot/grub2/grub.cfg, is the maestro's score, dictating the rhythm of the system's boot performance.

Note : It's a sacred. Direct edits are to be made when you absolutely know what you are doing as as it holds the critical instructions for the system's startup.

Where does GRUB 2 gather its instructions, then? The playbook is sourced from /etc/default/grub, a file housing menu-configuration settings. This backstage document influences the decisions GRUB 2 makes when generating the essential grub.cfg. It's akin to a blueprint, detailing parameters such as timeouts and default boot options.

Sample /etc/default/grub file:

# GRUB_TIMEOUT=5GRUB_DEFAULT=saved
# GRUB_DISABLE_SUBMENU=true
# GRUB_TERMINAL_OUTPUT="console"
# GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto rd.lvm.lv=rhel/root rhgb quiet net.ifnames=0"
# GRUB_DISABLE_RECOVERY="true"        

In the technical context of CentOS 7.x booting, understanding the dynamics of these files is key. So, remember to approach /boot/grub2/grub.cfg with care, and acknowledge the influence of /etc/default/grub in shaping GRUB2's performance.

Now, if/when adjustments are made to parameters in /etc/default/grub, a crucial step follows. To ensure these modifications take effect, you must execute 'grub2-mkconfig.'

[root@localhost~]# grub2-mkconfig –o /boot/grub2/grub.cfg        

This command serves as the conductor, orchestrating the regeneration of the /boot/grub2/grub.cfg file. In essence, it updates the system's boot configuration based on the modified settings, ensuring that every tweak is seamlessly integrated into the CentOS 7.x boot sequence.

Firstly, GRUB2 conducts a search in the /boot directory for the compressed kernel image file, commonly known as 'vmlinuz.' This file, holding the kernel's essential code, is a prerequisite for the system's continuation.

Once located, GRUB2 proceeds to load the vmlinuz kernel image file into memory. This involves injecting vital instructions into the system's core. Following this, GRUB2 extracts the contents of the initramfs image file, establishing a temporary, memory-based file system known as tmpfs.

Initramfs

The initramfs, serving as the initial RAM disk, becomes the precursor to the authentic root file system. It's a preliminary platform, mounted before the primary root file system, ensuring that essential components are prepared before the final phase of the boot process.

The primary responsibility of the initramfs is to preload block device modules essential for the system's functionality. This includes modules for IDE, SCSI, or RAID – critical components that pave the way for the subsequent stages of the boot process. By doing so, the initramfs ensures a smooth transition to the root file system, where these modules traditionally reside, allowing for seamless access and mounting.

Functioning as a crucial link, the initramfs is intricately bound to the kernel. In a two-stage boot process, the kernel takes charge of mounting this initial RAM disk, solidifying its role as a transitional element between the hardware initialization and the system's core functionality.

To craft this vital initramfs, we turn to the dracut utility. Whenever a new kernel is installed, dracut works diligently behind the scenes, generating the initramfs tailored to the specific configuration. It's a meticulous process ensuring that the system is well-equipped

To inspect the contents of the initramfs meticulously crafted by dracut, the 'lsinitrd' command serves as a valuable tool.

[root@localhost~]# lsinitrd | less        

The machine is now in a state where the kernel is poised to initiate the systemd process, setting the stage for system initialization tasks such as setting the hostname, initializing the network, mounting file systems, and other essential activities in the CentOS 7.x operating system.

Kernel

At this point in the CentOS 7.x boot sequence, the kernel has initiated the systemd process with a Process ID (PID) of 1. In the Linux operating system, the systemd process serves as the ancestor of all other processes, marking the beginning of the user space.

root 1 ?0 0 02:10 ? 00:00:02?/usr/lib/systemd/systemd?--switched-root --system --deserialize 23        

Systemd, as the first process, assumes a critical role in managing and coordinating various system initialization tasks.

This stage is pivotal in transitioning from the kernel's low-level interactions with the hardware to the higher-level functionalities of the CentOS 7.x system, marking the commencement of the user space and the system's readiness for user interactions and services.

Systemd

Systemd takes center stage as the parent, or ancestor, of all processes in the system. Its primary responsibility is orchestrating the system initialization tasks that pave the way for the operating system's full functionality.

Systemd's initial move involves reading the file specified by the symbolic link at /etc/systemd/system/default.target. This file, exemplified by /usr/lib/systemd/system/multi-user.target, defines the default system target, serving as the equivalent of traditional run levels. The chosen target file outlines the services that systemd is tasked with initiating.

Upon determining the default system target, systemd efficiently executes a series of system initialization tasks. This includes essential activities such as setting the hostname, initializing the network, configuring SELinux based on its predetermined specifications, displaying a welcome banner, initializing system hardware based on kernel boot arguments, and mounting file systems. Notably, systemd ensures the orderly cleanup of directories in /var and initiates the swapping process.

In essence, systemd brings the CentOS 7.x system to a defined state, seamlessly integrating and managing these foundational tasks to establish a fully operational environment for user interactions and services.

Conclusion

The CentOS 7.x boot journey—from BIOS to systemd—culminates in a fully operational state. With systemd at the helm, system tasks are executed, setting the stage for user interactions. This exploration equips users for effective troubleshooting and optimization, laying the foundation for efficient resource management.

Want more ? STATS FOR NERDS !

GRUB2 Configuration Details

The /etc/default/grub file is a crucial component in configuring the GRUB2 bootloader. It contains various options that dictate the boot sequence, timeout settings, and kernel command line arguments. Here's an explanation of some key options:

• GRUB_TIMEOUT: This option defines the number of seconds GRUB2 waits before automatically booting the default entry. The default value is usually 5 seconds.
• GRUB_DEFAULT: This option specifies the default entry that GRUB2 boots automatically if no user interaction occurs during the timeout period. It can be set to an index number (e.g., 0 for the first entry) or a specific entry name defined in /boot/grub2/grub.cfg.
• GRUB_DISABLE_SUBMENU: This option disables the display of submenus if multiple operating systems or kernel versions are detected. Setting it to true simplifies the boot menu, while false shows submenus for each detected entry.
• GRUB_TERMINAL_OUTPUT: This option determines where the GRUB2 menu and messages are displayed. By default, it's set to "console," which means they appear on the physical console screen. Other options include "serial" for serial console output or "gfxterminal" for displaying them in a graphical framebuffer.
• GRUB_CMDLINE_LINUX: This option allows you to specify additional kernel command line arguments to be passed to the kernel during boot. These arguments can be used to fine-tune the kernel behavior or troubleshoot specific issues.

Remember: Modifying /etc/default/grub requires regenerating the actual boot configuration file using the grub2-mkconfig -o /boot/grub2/grub.cfg command for the changes to take effect.

This explanation provides a basic understanding of some critical GRUB2 configuration options and highlights the importance of careful editing due to its impact on the boot process. For a complete list and detailed information on all available options, you can refer to the official GRUB2 documentation: https://www.gnu.org/software/grub/manual/grub/html_node/Configuration.html

More details on initramfs

The initramfs (initial RAM filesystem) serves a critical role in the early stages of the boot process by providing essential components before the main root filesystem is mounted. It typically holds various types of modules that enable the system to access and utilize hardware and software resources during boot. Here's a breakdown of some common types of content found in an initramfs:

1. Filesystem Drivers:

• These modules allow the kernel to understand and interact with different filesystem types used for data storage, such as ext4, XFS, NTFS, and Btrfs. Without these drivers, the system would be unable to access data stored on disks or partitions formatted with these filesystems.

2. Hardware Drivers:

• This category encompasses modules for various hardware components like network adapters, storage controllers, graphics cards, and input devices (keyboard, mouse). These drivers enable the kernel to communicate and utilize the functionalities of these hardware components at boot time.

3. Block Device Modules:

• These modules manage interactions with block devices, including hard disk drives, solid-state drives, and CD-ROM drives. They provide functionalities such as partitioning, formatting, and reading/writing data from these devices.

4. Additional Utilities:

• The initramfs may also include various essential utilities and tools required for early system setup tasks. These can include tools for:Mounting filesystems: Tools like mount and fsck are used to mount the root filesystem and perform filesystem checks if necessary.Network configuration: Tools like ip and net can be used to configure network interfaces for initial network connectivity.Environment variables: Scripts might be included to set up essential environment variables needed by the system during boot.

The specific content of an initramfs can vary depending on the system configuration and specific requirements. However, understanding these different types of modules provides a general idea of what the initramfs typically encompasses and its role in facilitating a smooth boot process.

systemd Targets Explained

systemd, the system and service manager in CentOS 7.x, utilizes the concept of targets to define different operational states the system can be in. These targets act like checkpoints, specifying which services and components should be running for a particular system state. Understanding the different types of targets clarifies how systemd manages the boot process and controls the overall system behavior.

Here's an overview of some common systemd targets:

1. multi-user.target: This is the default target in most CentOS 7.x systems. It represents a multi-user environment with basic functionalities like network access, logging, and the ability to run user applications. This target is suitable for most server or workstation use cases.

2. graphical.target: This target initiates a graphical user interface (GUI) environment in addition to the functionalities provided by multi-user.target. This target is typically used on desktop systems.

3. rescue.target: This target brings the system up in a minimal rescue mode, primarily used for troubleshooting and system recovery purposes. It allows access to essential tools and commands for diagnosing and fixing system issues.

4. poweroff.target: This target initiates a system shutdown and prepares the hardware for power off.

5. reboot.target: This target initiates a system reboot, similar to poweroff.target but followed by a restart without complete power off.

6. Network Targets: systemd also offers various network-related targets like network.target and net.target. These targets manage the network interface initialization process at different stages of the boot sequence.

These are just a few examples, and the specific available targets can vary depending on the system configuration and installed packages. Additionally, systemd allows creating custom targets by combining existing ones, providing flexibility in managing complex system states.

Understanding systemd targets is crucial for:

• Troubleshooting boot issues: Identifying the last successfully reached target can help pinpoint where the boot process might have failed.
• Managing system startup and shutdown: Choosing the appropriate target during boot or initiating shutdown/reboot through specific targets.
• Configuring system services: Specifying which services to run under different targets allows for fine-grained control over system behavior.