Demystifying Linux Boot: From Kernel Loading to User Login
This article walks through the Linux boot sequence on Debian, covering kernel loading, the init process, runlevel selection, startup script linking, various login methods, and the handling of login and non‑login shells with concrete command examples.
Loading the Kernel
After the BIOS hands control to the operating system, the kernel image located in /boot is read. On a typical Debian system the /boot directory contains files such as vmlinuz-3.2.0‑amd64, initrd.img‑3.2.0‑amd64, config-3.2.0‑amd64, and the grub directory.
$ ls /boot
config-3.2.0‑amd64
initrd.img‑3.2.0‑amd64
vmlinuz-3.2.0‑amd64
System.map‑3.2.0‑amd64
...Starting the Init Process
Once the kernel is loaded, it executes the first user‑space program /sbin/init, which becomes process ID 1. All other processes are descendants of this init process.
Determining the Runlevel
Init reads /etc/inittab to obtain the default runlevel (e.g., id:2:initdefault: means runlevel 2). Runlevels 0‑6 correspond to shutdown, single‑user mode, and multi‑user modes; Debian treats 2‑5 as the same multi‑user mode.
Loading Startup Programs
Each runlevel has a directory /etc/rcN.d (where N is the runlevel). The directory contains symbolic links to scripts in /etc/init.d. Files prefixed with S start services, while K files stop them when changing runlevels. The two‑digit number after the prefix determines the order.
$ ls /etc/rc2.d
README
S01motd -> ../init.d/motd
S13rpcbind -> ../init.d/rpcbind
S14nfs-common -> ../init.d/nfs-common
S16rsyslog -> ../init.d/rsyslog
S16sudo -> ../init.d/sudo
S17apache2 -> ../init.d/apache2
...To restart a service, invoke the script directly, e.g., sudo /etc/init.d/apache2 restart.
$ sudo /etc/init.d/apache2 restartUser Login
After startup programs finish, the system presents a login interface. Three common login methods are:
Console login (getty → login)
SSH login (sshd)
Graphical login (display manager such as gdm)
Login Shell
The login shell reads /etc/profile (global) and then one of the user‑specific files: ~/.bash_profile, ~/.bash_login, or ~/.profile. Only the first existing file is sourced.
~/.bash_profile
~/.bash_login
~/.profileFor SSH login the same files are used; for graphical login only /etc/profile and ~/.profile are read.
Non‑login Shell
When a user opens a terminal after logging in, a non‑login shell starts. It does not read the login files but sources ~/.bashrc. Debian ensures ~/.bashrc is executed by adding the following snippet to ~/.profile (or ~/.bash_profile if it exists):
if [ -n "$BASH_VERSION" ]; then
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fiIf ~/.bash_profile exists, it should source ~/.profile to guarantee .bashrc runs:
if [ -f ~/.profile ]; then
. ~/.profile
fiThis arrangement makes the configuration consistent across login and non‑login shells.
In summary, the Debian boot process proceeds from BIOS to kernel loading, init, runlevel‑based service start‑up, and finally user authentication via console, SSH, or graphical login, with careful handling of login and non‑login shell initialization files.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITPUB
Official ITPUB account sharing technical insights, community news, and exciting events.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
