The Linux boot process, from power button to login

Steps 1 to 8 only read information. Step 9 needs one reboot of ubu01, so close anything you have open on it first. Keep the VirtualBox console window for both VMs handy, because you’ll want to watch them boot.

1Did this VM boot with UEFI or BIOS?

Run this on both VMs:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

You should see this on rocky01:

UEFI

The kernel creates /sys/firmware/efi only when the firmware started it in UEFI mode. rocky01 was built with EFI enabled. ubu01 prints UEFI or BIOS depending on whether “Enable EFI” was ticked in VirtualBox when you created it, and both are fine for this course.

✅ Checkpoint: You know the boot mode of each VM.

2Read the firmware’s boot entries

Run this on rocky01 (install it with sudo dnf install -y efibootmgr if it’s missing):

sudo efibootmgr

You should see something like this:

BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0){auto_created_boot_option}
Boot0002* UEFI VBOX HARDDISK VB5f3e9a21-7c8d4b16 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0){auto_created_boot_option}
Boot0003* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Rocky Linux	HD(1,GPT,3f2a6c1e-9b7d-4e21-8c5a-0d4f6b2e9a17,0x800,0x12c000)/\EFI\rocky\shimx64.efi

BootCurrent says which entry started this boot (0004), and BootOrder is the order the firmware tries them. Entry 0004 points at partition 1 of the GPT disk and the file \EFI\rocky\shimx64.efi, which is /boot/efi/EFI/rocky/shimx64.efi once Linux is running. The other entries are VirtualBox’s own menu, the CD drive, the raw disk and the EFI shell.

On a BIOS VM, the same command gives:

EFI variables are not supported on this system.

✅ Checkpoint: You found the Rocky Linux entry and its shimx64.efi path.

3What did GRUB pass to the kernel?

Run this on both VMs:

cat /proc/cmdline

You should see something like this on rocky01:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64 root=/dev/mapper/rl-root ro crashkernel=2G-64G:256M,64G-:512M resume=/dev/mapper/rl-swap rd.lvm.lv=rl/root rd.lvm.lv=rl/swap rhgb quiet

And on ubu01:

BOOT_IMAGE=/vmlinuz-7.0.0-15-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro

BOOT_IMAGE is the kernel file GRUB loaded, root= is the file system that becomes / after the initramfs, and ro mounts it read-only at first so it can be checked (systemd remounts it read-write later). The rd.lvm.lv= entries tell Rocky’s initramfs which LVM volumes to switch on, crashkernel= reserves memory for kdump (Rocky picks the value, so yours may differ), and rhgb quiet hide most boot messages behind a progress screen.

✅ Checkpoint: You can point at the root= value on each VM.

4Look inside the initramfs

Run this on rocky01:

ls -lh /boot/vmlinuz-$(uname -r) /boot/initramfs-$(uname -r).img
sudo lsinitrd -m

You should see something like this (shortened):

-rw-------. 1 root root 38M Oct 27 09:58 /boot/initramfs-6.12.0-211.16.1.el10_2.0.1.x86_64.img
-rwxr-xr-x. 1 root root 15M Oct 20 18:20 /boot/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64

Image: /boot/initramfs-6.12.0-211.16.1.el10_2.0.1.x86_64.img: 38M
========================================================================
Early CPIO image
========================================================================
(a few lines of CPU microcode files)
========================================================================
Version: dracut-107-4.el10

dracut modules:
systemd
systemd-initrd
systemd-udevd
i18n
lvm
dm
kernel-modules
rootfs-block
udev-rules
dracut-systemd
usrmount
base
fs-lib
shutdown
========================================================================

The kernel file is about 15 MB and its initramfs about 38 MB. The dracut modules list shows what the initramfs can do: lvm and dm are why it can find rl-root, and the systemd modules are why systemd is already running before your real disk is mounted. The early CPIO part holds CPU microcode that the kernel loads first.

On ubu01 (26.04 builds its initramfs with dracut too):

ls -lh /boot/initrd.img-$(uname -r)
sudo lsinitrd -m | head -n 20

The name differs (initrd.img-7.0.0-15-generic) but the tool and the layout are the same. On Ubuntu 24.04 and older you’d use lsinitramfs /boot/initrd.img-$(uname -r) from initramfs-tools instead.

✅ Checkpoint: lsinitrd listed lvm among the dracut modules on rocky01.

5Who is PID 1?

Run this:

ps -p 1 -o pid,comm
ls -l /sbin/init

You should see something like this on rocky01:

    PID COMMAND
      1 systemd
lrwxrwxrwx. 1 root root 22 Oct 20 18:31 /sbin/init -> ../lib/systemd/systemd

The kernel starts /sbin/init as process 1, and on both distributions that’s a link to systemd. PID 1 is special: if it dies, the kernel panics, and every orphaned process gets adopted by it.

✅ Checkpoint: ps shows systemd as PID 1.

6Which target does each VM boot into?

Run this on both VMs:

systemctl get-default

You should see this on rocky01:

multi-user.target

And on ubu01:

graphical.target

The Rocky installer set multi-user.target because you chose a server with no desktop. Ubuntu Server leaves systemd’s own default, graphical.target, but with no display manager installed it reaches the same state as multi-user. Both answers are normal, and this is the first thing to check when a server boots into the wrong mode.

✅ Checkpoint: You know the default target of both VMs.

7How long did the boot take?

Run this on both VMs:

systemd-analyze

You should see something like this on rocky01:

Startup finished in 1.912s (firmware) + 5.618s (loader) + 1.104s (kernel) + 2.867s (initrd) + 5.918s (userspace) = 17.419s
multi-user.target reached after 5.902s in userspace.

And on ubu01:

Startup finished in 1.734s (kernel) + 2.912s (initrd) + 7.388s (userspace) = 12.034s
graphical.target reached after 7.351s in userspace.

Each part maps to a runner in the relay. On rocky01, “loader” is mostly the 5-second GRUB menu, which is why a 17-second boot feels slow in a VM. If your output has no (firmware) and (loader) parts, as on ubu01 here, the boot loader didn’t report its timings to systemd, which is normal with BIOS VMs and with Ubuntu’s GRUB.

✅ Checkpoint: You can say which stage took the longest on each VM.

8Which units were slow, and which ones mattered?

Run this on rocky01:

systemd-analyze blame | head -n 8
systemd-analyze critical-chain

You should see something like this:

2.481s tuned.service
1.204s NetworkManager-wait-online.service
 933ms dracut-initqueue.service
 705ms firewalld.service
 612ms lvm2-monitor.service
 377ms initrd-switch-root.service
 208ms polkit.service
 186ms chronyd.service

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @5.902s
└─tuned.service @3.418s +2.481s
  └─network.target @3.410s
    └─NetworkManager.service @3.322s +86ms
      └─network-pre.target @3.318s
        └─firewalld.service @2.611s +705ms
          └─polkit.service @2.398s +208ms
            └─basic.target @2.380s
              └─dbus-broker.service @2.342s +36ms
                └─dbus.socket @2.329s
                  └─sysinit.target @2.321s

blame lists units by how long they took to start, but many of them ran in parallel, so the top of blame isn’t always the reason the boot was slow. critical-chain shows the chain that the target waited for: here multi-user.target waited for tuned, which waited for the network, which waited for firewalld. NetworkManager-wait-online took 1.2 seconds but isn’t on the chain, so it didn’t delay the login prompt.

✅ Checkpoint: You found the slowest unit on your critical chain.

9Read the logs of the previous boot

Reboot ubu01, log in again, then run:

journalctl --list-boots
journalctl -b -1 -n 4 --no-pager

You should see something like this:

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 8d41f0c2a7b94e6d9c35b1e27a0f6d58 Tue 2026-10-27 10:01:12 IST Tue 2026-10-27 11:20:45 IST
  0 b27e5c9a14d84f6aa0c3e8d1f9b65a72 Tue 2026-10-27 11:21:03 IST Tue 2026-10-27 11:26:40 IST

Oct 27 11:20:44 ubu01 systemd[1]: Reached target reboot.target - System Reboot.
Oct 27 11:20:44 ubu01 systemd[1]: Shutting down.
Oct 27 11:20:45 ubu01 systemd-shutdown[1]: Syncing filesystems and block devices.
Oct 27 11:20:45 ubu01 kernel: reboot: Restarting system

Index 0 is the current boot and -1 the one before. -b -1 with -n 4 shows the last four lines of the previous boot, which is where you look when a server rebooted on its own: a clean shutdown ends like this, while a crash or power cut ends mid-sentence. Ubuntu keeps the journal on disk in /var/log/journal, which is why this works on ubu01. Try it on rocky01 in the Break-It part.

✅ Checkpoint: You can see two boots in the list and the shutdown lines of the previous one.