When Linux starts slowly or reaches the wrong operating state, effective recovery depends on knowing where to look before changing anything. This hands-on course connects kernel messages, boot storage, GRUB configuration, systemd targets, boot timing, and kernel modules into a practical troubleshooting workflow.
You will inspect a live system, make controlled runtime changes, and preserve evidence in report files. The final recovery scenario asks you to capture the kernel command line, document a test module, remove it from the running kernel, and isolate the system into text-based multi-user mode.
What You Will Learn
- Read early kernel messages with
dmesgand identify the active boot command line - Determine how
/bootis stored and inspect generated GRUB menu configuration safely - Interpret kernel boot parameters such as
ro,rw, andinit=/bin/bash - Inspect systemd targets and switch the running system with
systemctl isolate - Schedule, verify, and cancel a delayed reboot without allowing it to occur
- Measure boot time and compare
systemd-analyze blamewithcritical-chain - Inspect, dry-run, load, verify, and unload a safe test kernel module
Who This Course Is For
This intermediate course is for Linux administrators, DevOps learners, support engineers, and developers who need a structured introduction to boot diagnosis and controlled recovery actions. It is useful when investigating slow startup, unexpected boot state, bootloader parameters, or a suspect kernel module.
Prerequisites: Comfortable use of the Linux terminal, pipes and redirection, file inspection, and sudo. Basic familiarity with services and systemd is helpful.
Learning environment: A systemd-based LabEx Linux terminal with generated GRUB configuration, boot diagnostics, and permission to perform controlled target and dummy kernel-module changes.
Frequently Asked Questions
Will I reboot the machine or edit GRUB configuration directly?
No. You schedule a reboot for ten minutes later, verify its tracked state, and cancel it. You read grub.cfg and identify its kernel line, but do not edit the generated file or reboot into a rescue shell.
What is the difference between systemd-analyze blame and critical-chain?
blame ranks units by their individual activation duration, while critical-chain shows dependency order and which timings lie on the boot path. A slow unit is not necessarily the unit that blocked startup, so the course uses both views.
Are the kernel-module exercises safe for the lab system?
They use the dummy network-device module specifically as a controlled test. You preview the action with modprobe -n -v, load and verify the module, and remove it again; the final challenge also documents the module before unloading it.
