Linux: its fundamental pieces and their uses.
In this article, we'll talk about the four (four!?!?) fundamental pieces of Linux.
People often talk about the essential commands or an oversimplification of the boot process. Personally, I don't think this is the correct way to do it. We gotta go DEEP!
First of all: Linux is not an operating system. It is a bodiless brain, an engine without a car. It is nothing more than that. Without the body or the rest of the car, it is quite useless.
It depends on other pieces. And these pieces, when combined, are more often than not called the operating system. In most cases, its GNU's operating system (although others, like musl, exist!), which is a combination of tools, binaries and coreutils that work hand to hand with the kernel. But there are four other parts which Linux (mostly) relies on:
We'll talk about each one in depth, explaining what it does and its purpose.
Element one: kernel – Linux initialization.
The kernel is booted when the UEFI firmware finds the EFI partition, which is found using the aforementioned firmware and keeping in consideration that this partition is. more often than not, a FAT32 partition; it too can find it via the UUID or universally unique identifier. When the partition is located, the firmware executes a file usually called "BOOTX64.EFI". Depending on the amount of EFI partitions that it finds, it stores them as OS entries in the NVRAM (a portion of the UEFI's ROM).
*Note: don't be mistaken. When I speak about the NVRAM, I am not talking about the NVBM/non-volatile BIOS memory.
When the BOOTX64.EFI file is executed, in many cases the bootloader starts up. The behaviour the file has will depend greatly on the user configuration and the kernel compilation flags, due to the fact that a modern kernel does not require a bootloader. The main two cases are: BOOTX64.EFI is the GRUB Bootloader, or the BOOTX64.EFI is the Linux kernel, turned into an EFISTUB (check kernel compilation flag CONFIG_EFI_STUB).
*Note: this is why I don't mention the bootloader as a fundamental part of the system. It isn't needed.
After that, the kernel initializes the RAM, CPU registries... in short: it starts the hardware.
Element two: initramfs – system bootstraping.
The initramfs, usually called ramfs or ramdisk, it's a kind of limbo between the kernelspace and the userspace. Before this, there is no userspace. You get a black screen, perhaps a fan running. But nothing more. The objective of the initramfs is simple: to mount the real system root. It has other uses, like allowing a rescue shell in case of a fuckup, like toying around with the fstab, renaming device blocks, etcetera.
*A Linux system can exist and reach userspace without an initramfs present. Nevertheless, this is a very niche thing to do, because not having it might make the entire troubleshooting process more tedious. As mentioned previously: if your fstab is misconfigured, or if you rename something you shouldn't have renamed and you don't have an initramfs with a rescue shell... good luck. Go grab a live CD!
The kernel prepares a memory space called rootfs, which can be an instance of ramfs or tmpfs. In this moment, the magical proces of bootstrapping starts.
*Note: the difference between the ramfs and the tmpfs depends on the usage of swapfiles or partition swaps (an special kind of file/partiton that works as memory).
The boostrap (or bootstrapping process) refers to the configuration of the hardware stack, partition decryption (LUKS or others), device node copying, stdin, stdout, stderr redirection, kernel module insertion (drivers), fsck execution (if needed) plus other tasks. We won't talk about early userspace, because it will change based on distro, init system, etcetera.
Recommended by LinkedIn
Element three: init – userspace initialization.
When the initramfs does its job, it's the moment to run the init script/binary.
There isn't just one init, due to the fact that it depends on:
An init can be vary basic. Let's see this example that uses the BusyBox suite of tools to mount the real root and chroot into it, which also implies that we start using the disk and freeing the RAM.
#!/bin/busybox sh
# Mount the /proc and /sys filesystems.
mount -t proc none /proc
mount -t sysfs none /sys
# Do your stuff here.
echo "This script just mounts and boots the rootfs, nothing else!"
# Mount the root filesystem.
mount -o ro /dev/sda1 /mnt/root
# Clean up.
umount /proc
umount /sys
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
*This example was taken from the Gentoo wiki
This script mounts the essential filesystems /proc and /sys, which are used for:
Then it mounts /dev/sda1 to /mnt/root, meaning that the sda1 partition is the root of the system.
Previous to the final change, the init must unmount /proc and /sys.
Finally it executes switch_root. This command changes the current system root to the specified one. It's here where we leave the RAM and move into the disk. After that, the other init begins, which can be systemd-init, openrc, sysv, etcetera. This is the first process, the PID 1. Father of all other processes.
Element four: coreutils – userspace.
From here on out, many applications and pieces of software start running. Kworkers, getty (stty) are some of them. The GNU coreutils start to shine here. Ever used a Linux system without programs like ls, touch, cat head, tail, ln, shaXsum, su, whoam, wc? Exactly. Without the coreutils. there isn't much that one can do.
Imagine a world without su or chmod. These are impossible to live without!
Now with our terminal we can execute xinit, Wayland-based desktop environments, terminal emulators and more.
Close up.
After reading this, I hope the reader keeps on learning more and more about what makes Linux the kernel it is today and how it operates.
Analista Ciberseguridad | Analista Jr Bi | Google SecOps | BlueTeam | HackingEthico | CheckPoint |
2moInteresante