View source for Linuc

=2.01: System Boot and Linux Kernel=
==BIOS and UEFI Fundamentals==
The BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) are firmware interfaces responsible for initializing hardware during system startup and loading the operating system. BIOS, the older standard, relies on the Master Boot Record (MBR) partitioning scheme, which supports up to four primary partitions and boot drives up to 2.2 TB. In contrast, UEFI uses the GUID Partition Table (GPT), allowing up to 128 partitions and boot drives exceeding 9 zettabytes. UEFI also introduces the EFI System Partition (ESP), a FAT-formatted partition storing bootloaders, kernel images, and UEFI applications like efibootmgr. The ESP is critical for UEFI systems, as it hosts the grubx64.efi bootloader and enables Secure Boot to verify firmware integrity.

==Boot Loader Configuration and Shell Usage==
Modifying boot options varies by firmware type. In UEFI systems, efibootmgr manages boot entries, allowing users to adjust boot order, set active/inactive entries, and create new boot options via commands like efibootmgr -o 0001,0002. For Windows, bcdedit /default {GUID} changes the default OS entry. In BIOS-based systems, GRUB’s command-line interface provides direct control using commands such as kernel /vmlinuz root=/dev/sda1 to specify the kernel and initrd /initramfs.img to load the initial RAM disk. GRUB’s shell also supports disk exploration with ls (hd0,1)/ and boot troubleshooting via grub-install.

==GRUB Boot Menu Generation==
The GRUB boot menu is regenerated using grub2-mkconfig, which synthesizes configuration files from /etc/default/grub and scripts in /etc/grub.d/. Customizations like timeout adjustments or theme changes are added to /etc/default/grub, and executing grub2-mkconfig -o /boot/grub2/grub.cfg applies these changes. For UEFI systems, the configuration resides in /boot/efi/EFI/[distro]/grub.cfg, while BIOS systems use /boot/grub2/grub.cfg.

==Kernel Module Loading with initrd/initramfs==
The initrd (initial RAM disk) or initramfs (initial RAM filesystem) preloads essential kernel modules and drivers before the root filesystem is mounted. Modules like storage controllers or filesystem drivers are included by editing /etc/initramfs-tools/modules and rebuilding with update-initramfs -u. For example, adding netconsole to initrd involves creating a hook script in /etc/initramfs-tools/hooks/ to ensure the module is included during initramfs generation.

==Hardware Initialization and Filesystem Mounting==
During boot, the kernel initializes hardware via udev, which dynamically loads kernel modules based on detected devices. After module loading, the kernel mounts the root filesystem specified by the root= parameter in the bootloader. If the root filesystem is encrypted or on a RAID array, initrd handles decryption or assembly before passing control to the OS.

==Service Initialization with systemd==
Post-filesystem mount, systemd initializes services defined in systemd.unit files. The default target (e.g., multi-user.target or graphical.target) is set using systemctl set-default, while systemctl enable [service] configures services to start at boot. Systemd also manages dependencies, ensuring services like networking or logging start in the correct order.

==Boot Loader Installation and Filesystem Structure==
The grub-install or grub2-install command installs GRUB to the MBR (for BIOS) or ESP (for UEFI). Key directories include:
*/boot/: Contains the kernel (vmlinuz) and initramfs.
*/boot/grub2/: Stores GRUB configuration files (e.g., grub.cfg) on BIOS systems.
*/boot/efi/: Houses UEFI bootloaders and the ESP partition contents.

For UEFI installations, grub-install copies the grubx64.efi bootloader to /boot/efi/EFI/[distro]/, ensuring compatibility with firmware expectations.


=What is Systemd?=
Systemd is a modern system and service manager for Linux, designed to replace traditional init systems like SysV. As the first process started during boot (PID 1), it initializes hardware, mounts filesystems, and manages services through unit files-configuration files defining resources like services, sockets, and targets. Unlike SysV, systemd enables parallel service startup, reducing boot times, and integrates logging via journalctl for troubleshooting.

==Paths and Their Roles==
#'''/usr/lib/systemd/'''
##This directory stores default unit files provided by installed packages (e.g., nginx.service, sshd.socket). These files are managed by the system and should not be modified directly. For example, the sshd.service unit here defines how the SSH daemon starts, including dependencies and environment variables
#'''/etc/systemd/'''
##Administrators place custom unit files and overrides here. When you modify a service (e.g., adding Restart=always to ensure a service auto-recovery), create a subdirectory like /etc/systemd/system/nginx.service.d/override.conf. These configurations take precedence over /usr/lib/systemd/, allowing tailored behavior without altering package defaults.
#'''/run/systemd/'''
##Runtime configurations reside here, generated dynamically during system operation. For instance, temporary service states or transient units (e.g., systemd-tmpfiles-clean.service) are stored here and cleared on reboot. This directory reflects the current system state, unlike /etc/ or /usr/lib/, which persist across reboots.

==systemctl Commands==
*'''systemctl status [unit]''': Displays the current state of a service, including active/inactive status, recent logs, and dependencies. For example, systemctl status apache2 reveals if the web server is running, its uptime, and error messages.

*'''systemctl list-units''': Lists all loaded units (services, mounts, devices). Adding --type=service --state=failed filters to show only failed services, aiding quick diagnostics.

*'''systemctl start/stop [unit]''': Directly controls service execution. For instance, systemctl stop mysql halts the database, while systemctl start nginx activates the web server.

*'''systemctl enable/disable [unit]''': Configures autostart behavior. enable creates symlinks in /etc/systemd/system/[target].wants/, ensuring the service starts at boot. Conversely, disable removes these links.

*'''systemctl mask/unmask [unit]''': Prevents accidental activation. Masking (e.g., systemctl mask bluetooth) links the service to /dev/null, blocking all start attempts. Unmasking restores the original configuration.

==systemd-delta: Managing Configuration Overrides==
This tool identifies conflicts between unit file layers (e.g., /usr/lib/ vs. /etc/). Running systemd-delta highlights modified files, showing where administrators have overridden defaults. For example, if you’ve customized nginx.service in /etc/, it flags this as an "overridden" unit, ensuring transparency in configuration management.

'''Workflow Example: Customizing a Service'''
To increase the file handle limit for Nginx:
*Create an override:
<pre>sudo mkdir -p /etc/systemd/system/nginx.service.d/  echo -e '[Service]\nLimitNOFILE=65536' | sudo tee /etc/systemd/system/nginx.service.d/override.conf  </pre>
*Reload systemd:<pre>sudo systemctl daemon-reload</pre> 
*Restart Nginx: <pre>sudo systemctl restart nginx</pre>

This ensures Nginx can handle more concurrent connections without altering the original package file in '''/usr/lib/systemd/'''.

==Rescue and Emergency Modes==
*'''Rescue Mode''': Boots to a minimal root shell with critical services. Use systemctl rescue or append systemd.unit=rescue.target to the kernel command line. Ideal for fixing broken packages or misconfigured network settings[^prev^].

*'''Emergency Mode''': Provides a bare-bones environment without mounting most filesystems. Trigger via systemctl emergency or systemd.unit=emergency.target. Required for repairing corrupted /etc/fstab or root filesystem errors[^prev^].

==Integration with Journalctl==
Systemd’s logging tool, journalctl, centralizes log collection. For example, journalctl -u nginx --since "1 hour ago" filters logs for Nginx in the past hour, while journalctl -b shows all boot-related messages.

=Linux Kernel Distribution Format=
bzImage and xz Compression
The '''bzImage''' (big zImage) is a compressed Linux kernel executable format used in x86 and x86-64 architectures. Despite its name, it does not use bzip2 compression. Instead, it employs '''gzip''' by default for compressing the kernel image, though modern systems may use '''xz''' (LZMA2 algorithm) for higher compression ratios. The bzImage structure splits the kernel into two parts:
#'''Setup Code''': A small assembly stub (loaded below 1 MB in memory) responsible for decompressing the kernel and transitioning to protected mode.
#'''Compressed Kernel''': The main kernel code compressed with gzip/xz, decompressed into high memory (above 1 GB on 64-bit systems).
The xz compression reduces kernel size significantly, improving boot times on systems with slow storage (e.g., embedded devices). For example, a 10 MB uncompressed kernel might shrink to 4 MB with xz, compared to 6 MB with gzip[^prev^]

==Kernel Modules and Documentation==
===/usr/src/linux/===
This directory traditionally contains kernel source code, including:
*'''Source Files''': Core kernel code (e.g., kernel/sched.c for task scheduling).
*'''Header Files''': Architecture-specific headers (e.g., arch/x86/include/asm/io.h for x86 I/O operations).
*'''Build System''': Makefiles and Kconfig files for compiling modules or custom kernels.On modern distributions, this is often a symbolic link to /usr/src/linux-[version] (e.g., /usr/src/linux-5.15.0). Administrators use this to compile kernel modules or apply patches.

===/usr/src/linux/Documentation/===
A repository of kernel documentation, including:
*'''Process Guides''': Files like process/howto.rst explain kernel development workflows.
*'''Driver Documentation''': Instructions for device drivers (e.g., Documentation/networking/device_drivers/ethernet/intel/e1000e.rst).
*'''ABI Specification'''s: Stability guarantees for sysfs/procfs interfaces (e.g., Documentation/ABI/stable/sysfs-class-net).
*'''Security''': Guidelines like Documentation/security/credentials.rst detail kernel security models.This directory is critical for developers debugging hardware interactions or implementing kernel features[^prev^].

==Kernel Module Management==
Kernel modules are dynamically loaded components that extend kernel functionality (e.g., device drivers, filesystems). Key concepts include:
*'''Compilation''': Modules are built using the kernel’s build system. A trivial module hello-1.ko might include:
<pre>#include <linux/module.h>  
MODULE_LICENSE("GPL");  
static int __init hello_init(void) { printk("Hello, kernel\n"); return 0; }  
module_init(hello_init);  
</pre>

Compilation requires a Makefile referencing the kernel’s build directory:
<pre>obj-m += hello-1.o  
all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules  
</pre>

*'''Loading''': Use insmod hello-1.ko or modprobe hello-1 (which resolves dependencies).
*'''Inspection''': modinfo hello-1 displays module metadata (license, version), while lsmod lists loaded modules.
==Versioning and Distribution==
*'''Kernel Versioning''': Follows x.y.z format (e.g., 5.15.0), where x is the major version, y the minor, and z the patch. Stable releases receive incremental patches (e.g., 5.15.1), while -rc suffixes denote release candidates (e.g., 5.16-rc3).

*'''Distributions''': Ship customized kernels (e.g., Red Hat’s kernel-3.10.0-1160.el7.x86_64) with backported fixes and vendor-specific drivers. The uname -r command reveals the running kernel version.

==Practical Workflow Example==
*'''Extract Kernel Sources:'''
<pre>tar xvf linux-5.15.0.tar.xz -C /usr/src/</pre>

*'''Configure:'''
<pre>cd /usr/src/linux-5.15.0  
make menuconfig  # Enable/disable kernel features via TUI  </pre>

*'''Compile:'''
<pre>make -j$(nproc)  # Build kernel and modules  
make modules_install  # Install modules to /lib/modules/5.15.0/  
</pre>
*'''Install:'''
<pre>cp arch/x86/boot/bzImage /boot/vmlinuz-5.15.0  
update-grub  # Update bootloader entries  
</pre>

This structure ensures modularity, enabling efficient updates and hardware support across diverse systems

=Compiling the Linux Kernel: Core Components and Workflow=
===/usr/src/linux/ Directory Structure===
The /usr/src/linux/ directory typically contains the kernel source code, configuration files, and build artifacts. The .config file within this directory stores the kernel’s build configuration, including enabled features, drivers, and hardware support. This file is generated during the configuration phase (e.g., via make menuconfig) and defines compilation parameters such as processor architecture, filesystem support, and security settings.

==Kernel Makefile and Targets==
The '''Kernel Makefile''' orchestrates the compilation process. Key targets include:

*all: Compiles the kernel (vmlinux) and modules (*.ko).
*config/menuconfig/xconfig: Configure kernel options via text/TUI/GUI interfaces.
*oldconfig: Updates an existing .config file to include new options while retaining user choices.
*mrproper: Cleans the source tree, including .config and generated files.
*bzImage: Generates a compressed kernel image for x86/x86_64 systems.
*modules/modules_install: Builds and installs loadable modules to /lib/modules/<version>/.
*rpm-pkg/deb-pkg: Creates distribution-specific packages for easy deployment.

==Customizing Kernel Configuration==
To modify the kernel configuration:
*'''Copy the Current Config''':
<pre>cp /boot/config-$(uname -r) /usr/src/linux/.config  
</pre>
*'''Launch Configuration Tools''':
**make menuconfig for an ncurses-based interface.
**make xconfig for a Qt GUI (requires qt5-devel).
*'''Adjust Settings''':Enable/disable features like CONFIG_DEBUG_KERNEL for debugging or CONFIG_NET_VENDOR_INTEL for Intel NIC drivers.

==Building the Kernel and Modules==
*'''Compile the Kernel''':
<pre>make -j$(nproc)  # Parallel build using all CPU cores[8]</pre>
This generates vmlinux (uncompressed kernel) and arch/x86/boot/bzImage (bootable image).
* '''Build Modules''':
<pre>make modules  # Compiles loadable modules (*.ko files)[9]</pre>

==Installing the Kernel and Modules==
*'''Install Modules''':
<pre>sudo make modules_install  # Copies modules to /lib/modules/<version>/[1][5]</pre>
*'''Install Kernel''':
<pre>sudo make install  # Copies bzImage to /boot/vmlinuz-<version> and updates GRUB[1]</pre>
*'''Update Module Dependencies''':
<pre>sudo depmod -a  # Generates /lib/modules/<version>/modules.dep[^prev^]</pre>

==Bootloader Configuration==
After installation, update the bootloader to recognize the new kernel:
*'''GRUB''' (most distributions):
<pre>sudo grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
*'''systemd-boot (UEFI systems)''':
Add a new entry in /boot/efi/loader/entries/ referencing the kernel and initrd[^prev^].

==Module Configuration Files==
Module behavior is defined in:
*/etc/modprobe.d/: Contains override files (e.g., blacklist.conf to block problematic modules).
*/etc/modules-load.d/: Lists modules to load at boot (e.g., vfio.conf for virtualization)[^prev^].

==DKMS for Kernel Modules==
'''Dynamic Kernel Module Support (DKMS)''' automates module rebuilding for new kernels:
*Add a Module:
<pre>sudo dkms add -m nvidia -v 470.141.03</pre>
*'''Build and Install''':
<pre>sudo dkms build -m nvidia -v 470.141.03  
sudo dkms install -m nvidia -v 470.141.03[7]</pre>
*'''Verify Status''':
<pre>dkms status  # Shows installed modules and kernel compatibility[7]</pre>
==Initrd Configuration==
'''Initial RAM Disk (initrd)''' loads critical modules before the root filesystem mounts:
*'''Generate with Dracut''':
<pre>sudo dracut --force /boot/initramfs-<version>.img <version></pre>
*'''Generate with mkinitramfs''':
<pre>sudo mkinitramfs -o /boot/initrd.img-<version> <version></pre>
*'''Troubleshoot''':
Use lsinitrd /boot/initramfs-<version>.img to verify included drivers[^prev^].