Linuc ja

2.01: System Boot and Linux Kernel（システムの起動（ブート）とLinuxカーネル）

BIOS and UEFI Fundamentals（BIOS及びUEFIの基礎）

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.

---

BIOSとUEFIって何？

パソコンの電源を入れると、最初に動くのが「BIOS」や「UEFI」と呼ばれる仕組みです。 これは、パソコンの部品（ハードウェア）をチェックして、OS（WindowsやLinuxなど）を起動するための準備をする役割を持っています。

---

BIOS（バイオス）とは？

- 昔から使われている仕組みです。 - 「MBR（マスターブートレコード）」という方式でハードディスクを管理します。 - 2.2TB（テラバイト）までの大きさのハードディスクしか使えません。 - パーティション（ハードディスクの仕切り）は最大4つまでしか作れません。

---

UEFI（ユーイーエフアイ）とは？

- 新しいパソコンで使われている仕組みです。 - 「GPT（GUIDパーティションテーブル）」という新しい方式でハードディスクを管理します。 - とても大きなハードディスク（9ゼタバイト以上、ほぼ無制限）も使えます。 - パーティションは最大128個まで作れます。 - 「ESP（EFIシステムパーティション）」という特別な場所に、パソコンを起動するための大事なファイル（ブートローダーなど）を保存します。 - 「セキュアブート」という機能で、ウイルスなどの不正なプログラムが勝手に起動しないように守ってくれます。

---

まとめ
- **BIOS**は昔の仕組みで、使えるハードディスクやパーティションの数に制限があります。 - **UEFI**は新しい仕組みで、大きなハードディスクやたくさんのパーティションが使え、セキュリティも強化されています。

---

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.

---

ブートオプション（パソコンが起動するときに使う設定）の変更方法は、パソコンのファームウェア（BIOSやUEFIなど）によって違います。

• UEFIを使っている場合
  

「efibootmgr」というコマンドを使って、どの順番で起動するか（ブート順序）を変えたり、起動項目を追加・無効にしたりできます。

例:
efibootmgr -o 0001,0002 でブート順序を「0001」→「0002」に変更できます。

• Windowsの場合
  

「bcdedit /default {GUID}」というコマンドで、最初に起動するOS（Windowsなど）を選べます。

• BIOSを使っている場合
  

「GRUB」という起動プログラムのコマンドラインで、直接カーネル（OSの中核部分）や初期RAMディスク（起動時に使うファイル）を指定できます。

例:
kernel /vmlinuz root=/dev/sda1 でカーネルを指定
initrd /initramfs.img で初期RAMディスクを読み込む

GRUBのシェルでは、ls (hd0,1)/ でディスクの中身を見たり、grub-install でブートのトラブルを直したりもできます。

---

GRUB Boot Menu Generation（GRUBブートメニュー生成）

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.

---

GRUBのブートメニューは「grub2-mkconfig」というコマンドで作り直します。

• このコマンドは、/etc/default/grub という設定ファイルと、/etc/grub.d/ フォルダの中のスクリプトを元にして、ブートメニューの内容を自動で作ります。

• メニューを表示する時間を変えたり、見た目（テーマ）を変えたりしたいときは、/etc/default/grub ファイルを書き換えます。

• 設定を実際に反映するには、「grub2-mkconfig -o /boot/grub2/grub.cfg」とコマンドを打ちます。

• UEFIを使っているパソコンの場合、設定ファイルは「/boot/efi/EFI/[ディストリ名]/grub.cfg」にあります。

• BIOSを使っているパソコンの場合、設定ファイルは「/boot/grub2/grub.cfg」です。

まとめ
設定を変えたらコマンドを実行して、ブートメニューを更新しましょう。 パソコンの種類（UEFIかBIOSか）によって、設定ファイルの場所が違うので注意してください。

---

Kernel Module Loading with initrd/initramfs（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.

---

initrd（初期RAMディスク）やinitramfs（初期RAMファイルシステム）は、パソコンが起動するとき、OSの「根っこ」（ルートファイルシステム）を読み込む前に、まず必要なカーネルモジュールやドライバを準備するための仕組みです。

• なぜ必要？
  

たとえば、HDDやSSDなどのストレージや、ファイルシステムのドライバなどは、OSの根っこを読み込むために必要ですが、その根っこ自体を読み込む前に必要になる場合があります。そのため、initrdやinitramfsで先に必要なものをメモリ上に用意しておきます。

• どうやって必要なモジュールを追加するの？

1. /etc/initramfs-tools/modules というファイルに、必要なモジュール名（例：netconsole）を書きます。
2. その後、update-initramfs -u コマンドを実行します。これで、initramfsが新しくなり、書いたモジュールが含まれます。

• さらに細かく追加したい場合
  

たとえばnetconsoleというモジュール（ネットワーク経由でコンソールを使うためのもの）をinitrdに確実に追加したい場合は、/etc/initramfs-tools/hooks/ という場所に専用のスクリプトを作ります。すると、initramfsを作るときにそのモジュールも自動的に含まれます。

まとめ
initrdやinitramfsは、OSが起動する前に必要なドライバや機能を準備する「前準備」の仕組みです。必要なものを追加したいときは、設定ファイルやスクリプトを用意して、コマンドで再構築します。

---

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.

---

パソコンが起動するとき、カーネル（OSの中心部分）は「udev（ユーデブ）」という仕組みを使って、パソコンのハードウェア（HDDやUSBなど）を準備します。udevは、パソコンにつながっているデバイスを自動で見つけて、それに合ったドライバ（カーネルモジュール）を読み込みます。

• ドライバの準備が終わったら、カーネルは「root=」という設定で指定された場所（通常はHDDやSSDの中の一部）を「ルートファイルシステム」として使えるようにします（マウントします）。

• もしルートファイルシステムが暗号化されている場合や、複数のディスクをまとめて使うRAIDの場合は、initrd（初期RAMディスク）が暗号の解除やRAIDの準備をしてくれます。

• initrdがこれらの準備を終えると、OS本体が動き始めます。

まとめ
起動時には、パソコンのハードウェアやドライバの準備、暗号化やRAIDの処理などが自動で行われ、その後にOSがしっかり動き始めます。

---

Service Initialization with systemd（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.

---

パソコンの起動でファイルシステム（データの整理場所）が準備できた後、systemd（システィムディー）が、設定ファイルで決められたさまざまなサービス（ネットワークやログなど）を自動で動かし始めます。

• 「systemctl set-default」コマンドで、起動後にどの画面を使うか（たとえば文字だけか、グラフィカルな画面かなど）を選べます。

• 「systemctl enable [サービス名]」コマンドを使うと、そのサービスがパソコンの電源を入れたとき自動で起動するようになります。

• systemdは、サービス同士の「どれを先に動かすか」も自動で調整してくれるので、ネットワークやログなどのサービスが正しい順番で動きます。

まとめ
systemdは、パソコンの起動後に必要なサービスを自動で準備し、順番や自動起動も簡単に管理できます。

---

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.

---

「grub-install」や「grub2-install」というコマンドを使うと、GRUBというブートローダーをパソコンにインストールできます。

• BIOSを使うパソコンの場合

GRUBはディスクの先頭（MBRと呼ばれる場所）にインストールされます。

• UEFIを使うパソコンの場合

GRUBはEFIシステムパーティション（ESP）という特別な場所にインストールされます。

主なフォルダと役割

• /boot/

カーネル（vmlinuz）や初期RAMディスク（initramfs）など、起動に必要なファイルが入っています。

• /boot/grub2/

BIOSを使うパソコンの場合、GRUBの設定ファイル（例：grub.cfg）がここに保存されます。

• /boot/efi/

UEFIを使うパソコンの場合、ブートローダーやESPパーティションの中身がここに置かれます。

UEFIの場合のインストールの流れ

• grub-installコマンドは、grubx64.efiというファイル（UEFI用のブートローダー）を「/boot/efi/EFI/[ディストリ名]/」という場所にコピーします。

• これで、パソコンのファームウェア（UEFI）がGRUBを正しく認識し、OSが起動できるようになります。

まとめ
GRUBのインストール場所や必要なフォルダの役割を知っておくと、パソコンの起動やトラブル対応がしやすくなります。 他にも知りたいことがあれば、どうぞご質問ください。

---

What is Systemd? - Systemd boot customization（Systemdとは何か？ – 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

1. /usr/lib/systemd/
   1. 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
2. /etc/systemd/
   1. 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.
3. /run/systemd/
   1. 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:

sudo mkdir -p /etc/systemd/system/nginx.service.d/  echo -e '[Service]\nLimitNOFILE=65536' | sudo tee /etc/systemd/system/nginx.service.d/override.conf  

• Reload systemd:

  sudo systemctl daemon-reload

• Restart Nginx:

  sudo systemctl restart nginx

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:

1. Setup Code: A small assembly stub (loaded below 1 MB in memory) responsible for decompressing the kernel and transitioning to protected mode.
2. 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 Specifications: 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:

#include <linux/module.h>  
MODULE_LICENSE("GPL");  
static int __init hello_init(void) { printk("Hello, kernel\n"); return 0; }  
module_init(hello_init);  

Compilation requires a Makefile referencing the kernel’s build directory:

obj-m += hello-1.o  
all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules  

• 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:

tar xvf linux-5.15.0.tar.xz -C /usr/src/

• Configure:

cd /usr/src/linux-5.15.0  
make menuconfig  # Enable/disable kernel features via TUI  

• Compile:

make -j$(nproc)  # Build kernel and modules  
make modules_install  # Install modules to /lib/modules/5.15.0/  

• Install:

cp arch/x86/boot/bzImage /boot/vmlinuz-5.15.0  
update-grub  # Update bootloader entries  

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:

cp /boot/config-$(uname -r) /usr/src/linux/.config  

• 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:

make -j$(nproc)  # Parallel build using all CPU cores

This generates vmlinux (uncompressed kernel) and arch/x86/boot/bzImage (bootable image).

• Build Modules:

make modules  # Compiles loadable modules (*.ko files)

Installing the Kernel and Modules

• Install Modules:

sudo make modules_install  # Copies modules to /lib/modules/<version>/

• Install Kernel:

sudo make install  # Copies bzImage to /boot/vmlinuz-<version> and updates GRUB

• Update Module Dependencies:

sudo depmod -a  # Generates /lib/modules/<version>/modules.dep[^prev^]

Bootloader Configuration

After installation, update the bootloader to recognize the new kernel:

• GRUB (most distributions):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

• 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:

sudo dkms add -m nvidia -v 470.141.03

• Build and Install:

sudo dkms build -m nvidia -v 470.141.03  
sudo dkms install -m nvidia -v 470.141.03[7]

• Verify Status:

dkms status  # Shows installed modules and kernel compatibility[7]

Initrd Configuration

Initial RAM Disk (initrd) loads critical modules before the root filesystem mounts:

• Generate with Dracut:

sudo dracut --force /boot/initramfs-<version>.img <version>

• Generate with mkinitramfs:

sudo mkinitramfs -o /boot/initrd.img-<version> <version>

• Troubleshoot: Use lsinitrd /boot/initramfs-<version>.img to verify included drivers[^prev^].

Version-Specific Considerations

• Kernel 2.6.x: Uses make oldconfig for backward compatibility.
• Kernel 5.x: Supports make menuconfig with modern features like CONFIG_KASAN for memory sanitization.
• Compression: Use CONFIG_KERNEL_XZ for xz compression (smaller size) or CONFIG_KERNEL_GZIP for faster decompression[^prev^].

Workflow Example

• Download and Extract:

wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.0.7.tar.xz  
tar xvf linux-6.0.7.tar.xz -C /usr/src/

• Configure:

cd /usr/src/linux-6.0.7  
make menuconfig  

• Compile and Install:

make -j$(nproc) && sudo make modules_install && sudo make install

• Update Bootloader:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Management and troubleshooting during kernel execution

To obtain details about the currently running Linux kernel and its modules, several command-line utilities are available. The uname command is the most direct way to check the kernel version. Executing uname -r outputs the kernel release, while uname -a provides additional information such as the kernel name, version, and machine architecture. Another method is to inspect /proc/version, which contains the kernel build details. The /lib/modules/$(uname -r)/modules.dep file lists module dependencies for the current kernel version

For kernel modules, utilities like depmod and modinfo are essential. depmod generates a list of module dependencies, which is crucial for module management. modinfo displays information about a specific kernel module, including its parameters, author, and description.

Loading and Unloading Kernel Modules

Kernel modules can be managed manually using several utilities. insmod inserts a module into the kernel, but it does not resolve dependencies. modprobe is more advanced, as it automatically loads any dependencies required by the module. To view all loaded modules, lsmod lists them along with their sizes and usage counts. If you need to remove a module, rmmod unloads it from the kernel. modprobe -r can also be used to remove modules, handling dependencies as necessary.

Determining When a Module Can Be Unloaded

A kernel module can be unloaded only if it is not in use by any processes or other modules. The lsmod command displays a usage count for each loaded module. If the usage count is zero, the module can typically be unloaded safely. Attempting to remove a module with active dependencies or usage will result in an error, preventing potential system instability.

Determining Module Parameters

Modules often accept parameters at load time, which can be viewed using the modinfo command. This utility lists all parameters a module can receive. Additionally, configuration files in /etc/modprobe.d/ can be used to set persistent module parameters. These files allow administrators to specify options that are applied whenever a module is loaded.

Checking the Kernel Version

The kernel version is most commonly checked using the uname -r command, which prints the release number of the running kernel . More detailed information, including the build time and compiler version, is available with uname -a or by reading /proc/version. The /lib/modules/kernel-version/modules.dep file is also tied to the specific kernel version and contains information about module dependencies.

Loading Modules with Different Names

Linux allows the system to load modules using aliases or alternative names instead of the actual file names. This is configured in files under /etc/modprobe.d/, where alias directives can map a device or module name to a specific module file. This mechanism is useful for hardware abstraction and compatibility with different naming conventions.

The /proc File System

The /proc file system provides a virtual interface to kernel data structures. The /proc/sys/kernel/ directory contains tunable kernel parameters. These parameters can be modified at runtime using the sysctl utility or by editing /etc/sysctl.conf and files in /etc/sysctl.d/. Changes can be applied immediately with /sbin/sysctl.

Configuring initrd

The initial RAM disk (initrd) is a temporary root file system loaded into memory during the boot process. Tools such as dracut, mkinitrd, and mkinitramfs are used to generate or update the initrd image. This image contains necessary drivers and modules required for booting, especially on systems with complex storage configurations.

The /sys File System (sysfs)

The /sys file system, or sysfs, is a virtual file system that exposes kernel objects, device information, and module data to user space. It is typically mounted at /sys and provides detailed information about devices, drivers, and kernel subsystems. Unlike /dev, which provides device nodes for direct access, /sys is primarily for viewing and managing device attributes and relationships.

Contents of /boot and /lib/modules

The /boot directory contains files required for the system to boot, such as the kernel image (vmlinuz), initial RAM disk images (initrd or initramfs), and bootloader configuration files. The /lib/modules/$(uname -r)/ directory stores all kernel modules for the current kernel version, along with dependency files and module configuration data.

Tools for Hardware Information

Several command-line tools are available to analyze hardware information. dmesg prints kernel ring buffer messages, which include hardware initialization logs. lspci lists PCI devices, lsusb shows USB devices, and lsdev displays information about system devices. journalctl can be used to view system logs, including kernel and hardware events.

udev Rules and Module Configuration

udev is the device manager for the Linux kernel, handling dynamic device node creation. Tools like udevmonitor and udevadm monitor allow real-time monitoring of device events. udev rules, stored in /etc/udev/, define how devices are named, what permissions they have, and which modules or scripts are triggered on device events. Module configuration files in /etc can specify options or aliases for modules, integrating with udev actions

Obtaining a Kernel Dump

To capture a kernel dump for debugging, utilities such as kdump and kexec are used. kdump sets up a crash kernel and captures memory dumps when a kernel panic occurs. kexec allows booting into a new kernel directly from the running system, which is often used in conjunction with kdump for crash analysis. These tools help diagnose critical kernel failures by preserving system state at the time of a crash.

Filesystem setup and mount

The /etc/fstab file, known as the file system table, is a critical configuration file in Linux systems. It defines how and where disk partitions, block devices, and remote file systems should be mounted, particularly during system boot. Each line in /etc/fstab represents a single file system and includes six fields: the device identifier (such as a device file, UUID, or label), the mount point, the file system type, mount options, a dump flag for backups, and the fsck order for file system checks at boot. Using UUIDs or PARTUUIDs to identify devices is recommended, as device names like /dev/sda1 can change between boots, leading to potential mounting errors

Mounting and Unmounting Filesystems

To manually mount a file system, the mount command is used. It attaches the specified device to a directory in the file system hierarchy, known as the mount point. For example, mount /dev/sdb1 /mnt/data mounts the device /dev/sdb1 at /mnt/data. To detach, the umount command is used, specifying either the device or the mount point. If a file system is busy, unmounting will fail unless the -l (lazy) or -f (force) options are used. The current mount status can be checked with /etc/mtab or /proc/mounts, which list all active mounts. On modern systems, systemd also manages mounts and can influence the mount order, which is important for ensuring that dependencies between file systems are respected during boot.

Managing Swap Partitions and Files

Swap space can be provided either by a dedicated partition or a swap file. The mkswap command is used to initialize a swap area on a device or file. To enable swap, the swapon command activates it, while swapoff deactivates it. Swap entries can also be defined in /etc/fstab to ensure they are automatically enabled at boot. Proper management of swap is crucial for system performance, especially on systems with limited RAM.

Using UUIDs to Identify and Mount Filesystems

UUIDs (Universally Unique Identifiers) provide a stable and unique way to identify storage devices and partitions. They are generated when a file system is created and are not affected by device name changes. Tools like blkid and lsblk can display UUIDs and other file system metadata. For example, blkid /dev/sda1 or lsblk -f will show the UUID, file system type, and label for the specified device. Using UUIDs in /etc/fstab ensures reliable mounting regardless of how the kernel assigns device names during boot.

The /etc/fstab file automates and standardizes the mounting of file systems and swap areas on Linux systems. Manual mounting and unmounting are performed with mount and umount, and the status of mounts can be checked with /etc/mtab and /proc/mounts. Swap management is handled with mkswap, swapon, and swapoff. To avoid issues with changing device names, UUIDs should be used to reference devices, which can be obtained with blkid and lsblk. This approach ensures a good and reliable storage configuration across reboots and hardware changes

Filesystem managment

This section will help explain what tools are available for filesystem management

Tools for Manipulating Filesystems mkfs and fsck

The mkfs (make filesystem) utility is used to create a new filesystem on a storage device or partition. It acts as a front-end to filesystem-specific commands such as mkfs.ext4, mkfs.xfs, or mkfs.vfat. For example, if you want to format a partition as ext4, you would run:

sudo mkfs.ext4 /dev/sdb1

This command erases all data on /dev/sdb1 and creates a fresh ext4 filesystem. Similarly, to create an XFS filesystem, you would use:

sudo mkfs.xfs /dev/sdb2

Once filesystems are in use, the fsck (filesystem check) tool helps maintain their integrity. fsck scans the filesystem for inconsistencies and can repair many types of corruption. The command automatically detects the filesystem type, but you can also use filesystem-specific versions like fsck.ext4 or fsck.xfs. For example, to check and repair an ext4 filesystem, you might run:

sudo fsck.ext4 -y /dev/sdb1

The -y flag automatically answers "yes" to any prompts, allowing the tool to fix issues without user intervention.

Tools for Operating ext4: tune2fs, dumpe2fs, dump, restore

For ext4 filesystems, several specialized tools exist for maintenance and management. The tune2fs command allows you to adjust filesystem parameters after creation. For instance, you can change the maximum mount count before a forced check is required:

sudo tune2fs -c 30 /dev/sdb1

This sets the maximum mount count to 30, meaning the filesystem will be checked after every 30 mounts.

To examine detailed information about an ext4 filesystem, dumpe2fs is invaluable. It prints out superblock details, block group information, and more. For example:

sudo dumpe2fs /dev/sdb1 | less

This command provides a scrollable view of the filesystem’s internal structure.

For backup and recovery, the dump and restore utilities are used. dump creates a backup archive of a filesystem, while restore can extract files or entire filesystems from that archive. A typical backup command might be:

sudo dump -0uf /backup/sdb1.dump /dev/sdb1

This performs a level-0 (full) backup of /dev/sdb1 to /backup/sdb1.dump. To restore from this backup, you would use:

cd /mnt/restorepoint
sudo restore -rf /backup/sdb1.dump

cd /mnt/restorepoint sudo restore -rf /backup/sdb1.dump

This command restores the contents of the dump archive to the specified directory.

Tools for Manipulating XFS: xfs_info, xfs_check, xfs_repair, xfsdump, xfsrestore

XFS filesystems have their own suite of management tools. xfs_info displays detailed information about an XFS filesystem, such as its geometry and configuration. For example:

sudo xfs_info /mnt/data

If you suspect corruption, xfs_check (now deprecated in favor of xfs_repair) and xfs_repair are used to verify and fix filesystem problems. Always unmount the filesystem before running these tools. For example:

sudo umount /mnt/data
sudo xfs_repair /dev/sdb2

For backup and restore, xfsdump and xfsrestore are used. xfsdump creates a backup of the filesystem, while xfsrestore restores it. For instance:

sudo xfsdump -l 0 -f /backup/xfs.dump /mnt/data
sudo xfsrestore -f /backup/xfs.dump /mnt/restore

This sequence backs up the /mnt/data filesystem and restores it to /mnt/restore.

Tools to Manipulate Basic Btrfs: Subvolumes and Snapshots

Btrfs is a modern filesystem that supports advanced features like subvolumes and snapshots. Subvolumes are separate, mountable parts of the filesystem, while snapshots are read-only or read-write copies of subvolumes at a point in time. To create a subvolume, use:

sudo btrfs subvolume create /mnt/data/subvol1

To create a snapshot of this subvolume:

sudo btrfs subvolume snapshot /mnt/data/subvol1 /mnt/data/snapshots/subvol1_snap

These features are useful for backups, testing, and system rollbacks.

Convert and Manipulate ext4 Filesystems to Btrfs: btrfs, btrfs-convert

If you wish to convert an existing ext2, ext3, or ext4 filesystem to Btrfs without losing data, the btrfs-convert tool is available. It preserves the original data and allows you to roll back if needed. For example:

sudo btrfs-convert /dev/sdb1

After conversion, you can use the btrfs command suite to manage the filesystem, create subvolumes, take snapshots, and more.

Monitoring the Health of HDD and SSD: smartd, smartctl

SMART (Self-Monitoring, Analysis, and Reporting Technology) tools help you monitor and predict hardware failures in storage devices. The smartctl command provides detailed information about a disk’s health, including temperature, error logs, and test results. For example:

sudo smartctl -a /dev/sda

This outputs all available SMART data for the device. To run a long self-test:

sudo smartctl -t long /dev/sda

For continuous monitoring, the smartd daemon can be enabled. It regularly checks all configured drives and can send notifications if problems are detected. To enable it, edit /etc/smartd.conf as needed and start the service:

sudo systemctl enable --now smartd

This proactive monitoring helps you catch disk failures before they lead to data loss.