boot(7)

🌸 NAME 🌸

boot — the whole system bootup process, the UNIX System V Release 4 way, bestie 💖

---

✨ DESCRIPTION ✨

okay so listen. the bootup process (everyone calls it the "boot sequence" and honestly slay) has a lot of little details that change from system to system, but you can roughly chop it into phases, and each phase is run by one of these components:

1. hardware
2. operating system (OS) loader
3. kernel
4. root user-space process (init(8) and inittab(5))
5. boot scripts

and we're gonna walk through every single one of them, no skipping, periodt 💅

🎀 Hardware 🎀

so after you power-on or do a hard reset, control gets handed to a program that lives in read-only memory (normally PROM). and because of some historical personal-computer lore, this program is often just called "the BIOS". iconic name, honestly.

this program usually does a lil basic self-test of the machine and then goes and reads nonvolatile memory to grab more parameters. on a PC that memory is battery-backed CMOS memory, so everyone calls it "the CMOS". outside the PC world it's usually called "the NVRAM" (nonvolatile RAM). two names, same vibe.

what's stored in the NVRAM varies between systems, but at minimum it has to say which device can supply an OS loader — or at least which devices are allowed to be probed for one. that device is known as "the boot device" 🫶. then the hardware boot stage loads the OS loader from a fixed position on the boot device and transfers control to it. bye, hardware era.

Note: the device the OS loader gets read from might be attached over a network! in that case the booting details are further specified by protocols like DHCP, TFTP, PXE, Etherboot, etc. networking era fr fr 🌐

🦋 OS loader 🦋

the main character job of the OS loader is: find the kernel on some device, load it, run it. that's it, that's the task ✨

most OS loaders let you use them interactively, so you can point at an alternative kernel (maybe a backup, in case the one you last compiled is not functioning 😭) and pass optional parameters to the kernel.

in a traditional PC, the OS loader lives in the initial 512-byte block of the boot device. that block is known as "the MBR" (Master Boot Record) 👑

in most systems the OS loader is very limited because of various constraints. even on non-PC systems there are limits on the size and complexity of this loader, but the PC MBR size limit (512 bytes, including the partition table) makes it basically impossible to squeeze much functionality in there. it's giving cramped 💀

so most systems split the loading job between a primary OS loader and a secondary OS loader. the secondary one can live in a bigger chunk of persistent storage, like a disk partition.

in Linux, the OS loader is often grub(8) (and an alternative is lilo(8)).

⭐ Kernel ⭐

once the kernel is loaded, it initializes various components of the computer and the operating system. each piece of software responsible for one of those tasks is usually considered "a driver" for the applicable component. the kernel also starts the virtual memory swapper (it's a kernel process, called "kswapd" in a modern Linux kernel), and it mounts some filesystem at the root path, /.

some of the parameters you can pass to the kernel relate to these activities (for example, the default root filesystem can be overridden). for more on Linux kernel parameters, go read bootparam(7). iykyk 📖

and only then does the kernel create the initial user-space process, which gets the number 1 as its PID (process ID). traditionally this process executes the program /sbin/init, and everything that wasn't already handled by the kernel gets passed to it as parameters. passing the baton 🏃‍♀️

💜 Root user-space process 💜

Note: the description below applies to an OS based on UNIX System V Release 4. but a number of widely used systems have adopted a related-but-fundamentally-different approach known as systemd(1), and for that one the bootup process is detailed in its associated bootup(7). different lore, different page 🌈

when /sbin/init starts, it reads /etc/inittab for further instructions. this file defines what should be run when the /sbin/init program is told to enter a particular run level, which gives the administrator an easy way to set up an environment for some usage. each run level is associated with a set of services — for example, run level S is single-user mode, and run level 2 entails running most network services.

the administrator can change the current run level via init(1), and query the current run level via runlevel(8).

but since managing individual services by editing this file is not convenient, /etc/inittab only bootstraps a set of scripts that actually start/stop the individual services. it's a middle manager, not the whole team 💅

🌈 Boot scripts 🌈

Note: the description below applies to an OS based on UNIX System V Release 4. but a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD) have a somewhat different scheme for boot scripts. not everything is the same bestie 🙈

for each managed service (mail, nfs server, cron, etc.), there is a single startup script living in a specific directory (/etc/init.d in most versions of Linux). each of these scripts accepts one single argument: the word "start" (which makes it start the service) or the word "stop" (which makes it stop the service). the script may optionally accept other convenience parameters too (e.g., "restart" to stop and then start, "status" to display the service status, etc.). and if you run the script with no parameters at all, it displays the possible arguments. helpful queen 🫶

🧚 Sequencing directories 🧚

so to make specific scripts start/stop at specific run levels and in a specific order, there are sequencing directories, normally of the form /etc/rc[0-6S].d. in each of these directories there are links (usually symbolic) pointing to the scripts in the /etc/init.d directory.

a primary script (usually /etc/rc) is called from inittab(5). this primary script calls each service's script via a link in the relevant sequencing directory. every link whose name begins with 'S' is called with the argument "start" (thereby starting the service). every link whose name begins with 'K' is called with the argument "stop" (thereby stopping the service). S for start, K for kill, it's giving alphabet energy ✨

to define the starting or stopping order within the same run level, the name of a link contains an order-number. also, for clarity, the name of a link usually ends with the name of the service it refers to. for example, the link /etc/rc2.d/S80sendmail starts the sendmail(8) service on run level 2. this happens after /etc/rc2.d/S12syslog is run but before /etc/rc2.d/S90xfs is run. order matters, no cap 🔥

to manage these links is to manage the boot order and run levels. under many systems there are tools to help you with this task (e.g., chkconfig(8)). use the tools, bestie, don't do it by hand 😭

🎀 Boot configuration 🎀

a program that provides a service is often called a "daemon". usually a daemon can receive various command-line options and parameters. so that a system administrator can change these inputs without editing an entire boot script, some separate configuration file is used, and it lives in a specific directory where an associated boot script can find it (/etc/sysconfig on older Red Hat systems).

in older UNIX systems, such a file contained the actual command line options for a daemon. but in modern Linux systems (and also in HP-UX), it just contains shell variables. a boot script in /etc/init.d reads and includes its configuration file (that is, it "sources" its configuration file) and then uses the variable values. sourcing is the moment, periodt 🌸

---

💖 FILES 💖

• /etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/

---

🌟 SEE ALSO 🌟

init(1), systemd(1), inittab(5), bootparam(7), bootup(7), runlevel(8), shutdown(8)

---

and that's the whole page, bestie 🎀 this was Linux man-pages 6.20, dated 2025-09-21, for boot(7). go forth and boot responsibly 👑💖