I spent all day yesterday further reviewing the bootloader process and got lost in it. I still don’t understand all of it, but I suspect that if I move on in my studies, things will become more clear.
I’ve decided that updating the website every day is too daunting, and it’s probably best left to the weekends. I’ll write my entries as I go along, but uploading everything daily is simply too time-consuming for my studies.
I’m also pasting this here so I can review it later, because Shevek made it easy to memorize:
Firmware (BIOS/UEFI)
└─ logs to firmware interfaces
Bootloader (GRUB)
└─ logs to screen / serial
└─ LOADS kernel + initramfs
└─ JUMPS to kernel entry point
← bootloader logging ENDS here
Kernel (early init)
└─ logs via early printk
└─ initializes memory, scheduler, drivers
└─ mounts initramfs as temporary root
initramfs (/init)
└─ logs via kernel facilities
└─ prepares real root filesystem
systemd (PID 1)
└─ logs to journaldThere. Hopefully I can reference this whenever I’m feeling lost.
I download and begin the root_directory_explorer and I’m totally unimpressed. But I proceed anyway for the mental discipline. I answer the questions to make sure my own knowledge is on par—which is always lacking. I paste important notes to remember here. The first question asks me to name 10 top-level directories and their contents. I’ll copy and paste it here for memorization, and I’ll be making flash cards so it’s etched into my mind:
| Directory | Purpose |
|---|---|
/bin | Essential user command binaries required for basic system operation and recovery. |
/sbin | Critical system administration binaries used for booting, repair, and maintenance. |
/etc | System-wide configuration files and service configuration directories. |
/usr | Userland applications, libraries, and shared read-only resources. |
/var | Variable data that changes during runtime (logs, caches, spools, databases). |
/home | Personal directories for non-root users and their data. |
/root | Home directory for the root user, isolated from /home. |
/boot | Kernel images, bootloader files, and initramfs needed to start the system. |
/dev | Device nodes representing hardware and virtual devices as files. |
/proc | Virtual filesystem exposing live kernel and process information. |
/sys | Virtual filesystem exposing kernel objects, drivers, and device attributes. |
/tmp | Temporary files intended for short-term use; often cleared on reboot. |
/run | Volatile runtime state (PID files, sockets) available early in the boot process. |
I move on to the next mission. It requests that I compare my real directory to the virtual one. I attempt to do so, but the lab comes to a screeching halt when I can’t even look at the virtual directory contents of /proc. I take screenshots and send them to Shevek. He provides a less-than-elaborate explanation.
OK. What are the questions Shevek asks? I can at least take direction from those:
/proc and /sys are called “virtual” filesystems/dev represents/run exists and why it is typically tmpfsI’ll copy and paste my answers here for my own personal review:
Why /proc and /sys are called “virtual” filesystems
/proc and /sys are called virtual filesystems because they are not backed by data stored on disk. Instead:
/proc
/proc/<pid>)ps, top, free)/sys
In both cases: the filesystem is an interface, not storage.
What /dev represents
/dev contains device nodes, which are special files that act as interfaces to hardware and virtual devices.
Examples:
/dev/sda → a disk device/dev/tty → a terminal/dev/null → a data sinkModern systems typically manage /dev dynamically using udev, so device files appear and disappear as hardware changes.
Why /run exists and why it is typically tmpfs
/run exists to store volatile runtime state that must be available early in the boot process. It contains:
Why not /var/run?
/var may reside on disk that is not mounted yetWhy tmpfs?
tmpfs lives in RAMTherefore: /run is typically mounted as tmpfs to provide early, clean, volatile runtime storage.
One-line exam answers
/proc and /sys: Virtual filesystems exposing live kernel data, not stored files./dev: File-based interfaces to hardware and virtual devices via kernel drivers./run: Early-boot, volatile runtime state storage, usually backed by tmpfs.The lab Shevek made me is dry and uninteresting compared to what I had hoped for. But I know enough to know the real value of the lab lies in the questions it asks.
Section three asks:
/etc (and why they are usually text)/var (and why they change frequently)I have no idea. I ask Shevek to elaborate:
What kinds of things live in /etc (and why they are usually text)
/etc contains system-wide configuration files that define how the system and its services are supposed to behave. These include:
They are usually plain text because:
In short: /etc describes system intent and policy, not runtime state.
What kinds of things live in /var (and why they change frequently)
/var contains variable data that is created and modified as the system runs. These include:
They change frequently because:
In short: /var records what the system is doing and has done.
Two examples you saw on your machine
/etc/fstab: A text configuration file that defines how filesystems are mounted at boot./var/log: A directory containing log files that grow and rotate as services and the system run.One-line exam contrast: /etc holds static, human-readable configuration, while /var holds dynamic data that changes during normal system operation.
I could go back and have Shevek make me another interactive sandbox, but that would distract from the reality of what needs to happen. I need to know what questions I should be asking.
In mission four it asks:
Why /usr is not “user home” (historical meaning)
/usr historically meant “Unix System Resources,” not “user.” Originally:
/usr was a separate filesystemUser home directories were never intended to live there; they were placed in /home. In short: /usr holds system-provided software, not user data.
Practical difference between /bin and /usr/bin on modern systems
Historically:
/bin → essential binaries needed early in boot/usr/bin → non-essential user commandsOn modern distros using merged-usr:
/bin is a symlink to /usr/binThe distinction remains for compatibility, documentation, and bootstrapping concepts. Exam-safe phrasing: On merged-usr systems, /bin and /usr/bin reference the same binaries.
What sbin is for
sbin contains system administration binaries intended primarily for the root user. Historically:
/sbin → essential admin tools/usr/sbin → non-essential admin toolsOn merged-usr systems, /sbin is typically a symlink to /usr/sbin.
Where shared libraries typically live
Shared libraries live under /lib* and /usr/lib*, depending on architecture:
/lib or /lib64 → essential shared libraries for early boot/usr/lib or /usr/lib64 → most shared librariesOn merged-usr systems, /lib* are symlinks into /usr/lib*. In short: libraries live alongside the binaries that depend on them, primarily under /usr/lib*.
Mission five states:
In notes/mission5_special.txt, explain:
/tmp vs /var/tmp (lifetime expectations)/opt is appropriate/mnt and /media are typically used for/srv is intended forAgain, I have no context for answering any of these, but their answers are invaluable as a compass for what to focus on:
/tmp vs /var/tmp (lifetime expectations)
/tmp: short-lived temporary files; may be deleted at boot; often backed by tmpfs (RAM). Expectation: do not assume persistence./var/tmp: temporary files that should survive reboots; stored on disk; cleaned less aggressively. Expectation: persists unless explicitly removed.When /opt is appropriate
/opt is intended for optional, third-party, or vendor-supplied software that does not integrate cleanly into the system package layout (e.g., /opt/vendor/app/).
What /mnt and /media are typically used for
/mnt: temporary mount points for manual mounts (often used for troubleshooting or recovery)./media: automatic mount points for removable media (USB drives, external disks), typically managed by the desktop environment or udev.What /srv is intended for
/srv holds data served by system services (e.g., /srv/www). Configuration stays in /etc; logs go in /var.
As I revisit this information, I have the sudden realization that I will probably be doing this over and over again. I cannot expect to completely understand the system just yet, no matter how hard I try, because there is no context for the information. I will forever be going back and forth.
It is incredibly frustrating to have that realization, but with it comes the fortitude to persist.
The next lab is process_top_ps_proc_sandbox.zip. I have high hopes for it, because Shevek’s sandboxes for commands are often helpful in understanding the tool—even if they don’t always work as intended or hoped.
/etcFiles fade by design, Others speak while never stored— Kernel answers now.