Concepts·LPIC-1

Boot, firmware, and what the kernel was told

Objectives 101.1 and 101.2 cover firmware, the boot sequence and the bootloader. This guide determines which firmware this machine has from the filesystem rather than from memory, reads the kernel command line the bootloader passed it, and breaks the boot into its four measured phases - which is also how you find the service that is making a machine slow to start.

101: System Architecture Guide 4 of 33 Beginner

OSUbuntu 26.04 LTS
Kernel7.0.0-30-generic
systemd259
TimeAbout 18 min

One Debian-family host. Every command reads firmware, kernel or systemd state - nothing is configured, enabled or changed.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB

This guide includes

Use this for the firmware and boot objectives. This matters because all of it can be answered from a running machine - firmware, kernel parameters and where the boot time went, with no reboot.

answering UEFI or BIOS from a directory
reading the parameters the bootloader actually passed
measuring where the boot time went, across four phases

Before you start

UEFI or BIOS, answered by a directory
You do not need to reboot to find out.
bash Example session
```
$ls /sys/firmware/efi >/dev/null 2>&1 && echo "UEFI" || echo "BIOS (no /sys/firmware/efi)"BIOS (no /sys/firmware/efi)$sudo -n dmesg | head -3; echo "--- the kernel's own boot messages, oldest first"[    0.000000] Linux version 7.0.0-30-generic (buildd@lcy02-amd64-048) (x86_64-linux-gnu-gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.46) #30-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 31 18:22:54 UTC 2026 (Ubuntu 7.0.0-30.30-generic 7.0.12)[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M[    0.000000] KERNEL supported cpus:--- the kernel's own boot messages, oldest first$sudo -n dmesg -l err,warn 2>/dev/null | head -4; echo "--- filtered by priority, same as journalctl"[    0.068239] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge[    0.071379] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,               * this clock source is slow. Consider trying other clock sources[    1.117510] psmouse serio1: trackpoint: failed to get extended button data, assuming 3 buttons--- filtered by priority, same as journalctl
```
Note
/sys/firmware/efi exists only when the machine booted via UEFI. The kernel creates it from what the firmware handed over, so its presence is evidence rather than configuration. This is the reliable test, and it is the one worth memorising - a machine with a GPT disk may still have booted in legacy BIOS mode, so partition table style proves nothing.

Which matters because the bootloader differs. UEFI reads .efi binaries from an EFI System Partition, usually mounted at /boot/efi. BIOS executes code from the MBR. Installing GRUB for the wrong one produces a machine that does not boot and an error that does not explain itself.

dmesg is the kernel ring buffer, not a file. It holds a fixed amount and the oldest entries are overwritten, so on a long-running machine the earliest boot messages may be gone - journalctl -k -b reads the same messages from the journal, which persists.

dmesg -l err,warn takes the same priority names as journalctl because it is the same syslog scale. On a machine that will not boot cleanly, that filter is the fastest route to the cause.

Reading dmesg needs privilege on these machines. kernel.dmesg_restrict defaults to 1 on Ubuntu, because the ring buffer leaks kernel addresses useful to an attacker.

Expected resultThe firmware verdict, then the kernel's earliest boot messages, then the same log filtered to warnings and errors.

Success conditionYou can identify a machine's firmware and read its boot log.
The parameters the bootloader passed
/proc/cmdline is what the kernel actually received.
bash Example session
```
$cat /proc/cmdline; echo "--- the parameters the bootloader passed"BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M--- the parameters the bootloader passed$ls /boot/grub/grub.cfg 2>/dev/null; ls /etc/default/grub; grep -E '^GRUB_(TIMEOUT|CMDLINE_LINUX_DEFAULT)=' /etc/default/grub/boot/grub/grub.cfg/etc/default/grubGRUB_TIMEOUT=0GRUB_CMDLINE_LINUX_DEFAULT=""
```
Note
/proc/cmdline is the truth; /etc/default/grub is the intention. They differ whenever someone edited the config and did not regenerate, which is the commonest reason a parameter "was set" and had no effect.

Never edit /boot/grub/grub.cfg directly. It is generated, and the next kernel update overwrites it without asking. Edit /etc/default/grub, then run update-grub on Debian or grub2-mkconfig -o on the RPM family - two names for the same job, and the exam asks for both.

ro and quiet are worth recognising. Root is mounted read-only at first so a filesystem check can run safely; quiet suppresses most kernel messages. Removing quiet is the first thing to do when a machine hangs during boot with nothing on screen.

Parameters can be edited for ONE boot from the GRUB menu, by pressing e. That is how you add systemd.unit=rescue.target or init=/bin/bash to recover a machine you cannot log into - and it is why physical access to a bootloader without a password is equivalent to root.

GRUB_TIMEOUT=0 means the menu never appears, which is tidy until the day you need it.

Expected resultThe live kernel command line, then the generated grub.cfg and the /etc/default/grub you are supposed to edit instead.

Success conditionYou know where a boot parameter comes from and where to change it.
Where the boot time went
Four phases, measured, and the slowest units named.
bash Example session
```
$systemctl is-system-running; echo "--- one word for the whole machine"running--- one word for the whole machine$systemctl --failed --no-pager | head -4  UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.$systemd-analyze; echo "---"; systemd-analyze blame --no-pager 2>/dev/null | head -4Startup finished in 604ms (kernel) + 1.248s (initrd) + 1.760s (userspace) = 3.614sgraphical.target reached after 1.758s in userspace.---2.854s apt-daily.service2.050s xfs_scrub_all.service1.605s sys-devices-virtual-misc-rfkill.device1.605s dev-rfkill.device
```
Note
systemctl is-system-running is one word for the whole machine. running is healthy; degraded means something failed and everything else started - which is the state that matters, because the machine looks fine and is not. systemctl --failed is then the list.

Three phases, and they have different causes. Kernel time is firmware and hardware detection. initrd is the temporary root that loads drivers needed to reach the real one. Userspace is systemd starting units - and it is nearly always the one you can actually shorten.

blame sorts by unit duration and is honest about being misleading. apt-daily.service at 2.854s is longer than the entire boot, because units run in parallel - a slow unit that nothing waits for costs nothing. systemd-analyze critical-chain shows the chain that actually delayed the target, which is the question you meant to ask.

graphical.target reached after 1.758s is the number to quote. That is when the machine was usable, and it is a better measure than total elapsed time.

Zero failed units on a machine nobody has touched is worth checking rather than assuming. A failed unit that nothing depends on sits there indefinitely, and --failed is a one-line health check worth running on any machine you inherit.

Expected resultrunning, 0 failed units, and 604ms (kernel) + 1.248s (initrd) + 1.760s (userspace) = 3.614s with apt-daily.service slowest at 2.854s.

Success conditionYou can say where a slow boot is spending its time.

Troubleshooting

A kernel parameter was added to the bootloader configuration and has no effect.

Why: The running kernel was given something else - the generated config was not regenerated, or the entry edited was not the one that booted.

Fix:cat /proc/cmdline is authoritative: it is what the bootloader actually passed. Compare it with GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and regenerate with update-grub if they disagree.
You need to know whether a machine is UEFI or BIOS without rebooting.

Why: Nothing in the running system announces it, and the bootloader's location differs between the two.

Fix:ls -d /sys/firmware/efi - the directory exists only under UEFI. That decides whether grub-install targets a disk or an EFI system partition.
Boot appears slow but disabling the slowest unit changes nothing.

Why: systemd-analyze blame sorts units by their own duration, including units that started late and that nothing waited for.

Fix:systemd-analyze critical-chain shows what actually delayed the boot, and systemd-analyze alone splits the total into kernel, initrd and userspace so you attack the right phase.

Official sources

← All LPIC-1 guides

Boot, firmware, and what the kernel was told

This guide includes

Before you start

UEFI or BIOS, answered by a directory

The parameters the bootloader passed

Where the boot time went

Troubleshooting

Official sources