Troubleshooting a server that won’t boot — a scenario the IPMI guide covered from the remote-access angle — is considerably easier when you actually understand what’s supposed to happen at each stage between pressing power and reaching a login prompt. The Linux boot process involves several distinct stages, and knowing which stage is failing narrows down troubleshooting dramatically compared to vague “it won’t boot” uncertainty.
Stage 1: Firmware (UEFI or Legacy BIOS)
The very first thing that runs is your motherboard’s firmware — modern systems use UEFI, while older systems use legacy BIOS. This stage initializes basic hardware, runs power-on self-tests, and locates a bootable device based on configured boot order, before handing control to a bootloader found on that device.
UEFI systems specifically look for an EFI System Partition containing bootloader files in a standardized location, while legacy BIOS systems instead read a Master Boot Record from the beginning of the boot disk — a distinction relevant to the P2V and VMware migration guides covered earlier, where boot mode mismatches between source and destination were flagged as a common migration pitfall.
Stage 2: The Bootloader (GRUB)
GRUB (GRand Unified Bootloader) is the near-universal bootloader across mainstream Linux distributions, responsible for presenting the boot menu (where you’d select a specific kernel version, relevant to the earlier LTS vs latest kernel guide) and ultimately loading the selected Linux kernel into memory.
Viewing and Editing GRUB Configuration
The main configuration file consumed at boot is auto-generated and shouldn’t be edited directly:
/boot/grub/grub.cfgInstead, edit the source configuration and regenerate:
sudo nano /etc/default/grub
sudo update-grubThis is the same file modified in the earlier IOMMU/GPU passthrough guide when enabling virtualization kernel parameters — a practical example of interacting with this boot stage directly.
Stage 3: The Linux Kernel
Once GRUB hands off control, the Linux kernel itself takes over — initializing hardware drivers, mounting the root filesystem, and ultimately starting the very first userspace process. This is the stage where the LTS vs latest kernel choice () actually matters, and where issues like missing drivers for newer hardware would surface as boot failures or missing functionality.
Stage 4: Init (systemd)
The kernel starts PID 1 — on most modern distributions, this is systemd (covered extensively in earlier guides), which then proceeds to start every other system service according to defined dependencies and targets, eventually reaching a fully booted, usable system.
Boot Targets: Understanding What “Fully Booted” Means
systemd organizes boot completion around targets, roughly analogous to old-style runlevels:
systemctl get-defaultFor a typical headless server, this should show multi-user.target (a full multi-user system without a graphical interface) rather than graphical.target, which expects a desktop environment most homelab servers don’t need or want running.
Diagnosing Boot Failures by Stage
- System won’t power on or show any output at all – hardware or firmware-level issue, before Linux is even involved
- Reaches firmware/BIOS screen but no boot menu appears – bootloader (GRUB) issue, possibly a corrupted or missing GRUB installation
- GRUB menu appears but selected kernel fails to load – kernel-level issue, possibly a bad kernel update or missing initramfs
- Kernel loads but boot hangs before reaching a login prompt – likely a systemd service failing to start correctly, or an fstab issue () causing boot to hang waiting for a mount that isn’t available
Using IPMI or a Console to Diagnose Boot Issues
Since SSH access requires the system to have already fully booted, diagnosing boot failures specifically requires the IPMI virtual console () or physical console access — exactly the scenario that guide specifically highlighted as IPMI’s most valuable use case.
Booting into Rescue or Single-User Mode
For systemd-based systems experiencing boot problems, selecting a rescue or emergency target from the GRUB menu (often by editing boot parameters temporarily, adding systemd.unit=rescue.target) provides a minimal environment for troubleshooting without needing every service to successfully start first.
Recovering from a Bad fstab Entry
Connecting directly to the fstab guide covered earlier: a boot hang specifically caused by an unavailable mount is one of the most common self-inflicted boot failures, exactly why that guide recommended the nofail option for non-critical mounts and testing with mount -a before rebooting.
Final Thoughts
Understanding the Linux boot process — firmware, GRUB, kernel, then systemd — transforms a vague “server won’t boot” panic into a structured diagnostic process, identifying exactly which stage is failing and applying the right troubleshooting approach for that specific stage. Combined with IPMI’s remote console access , this understanding turns boot failures from a scenario requiring physical presence into one you can genuinely diagnose and often resolve remotely.
Leave a Reply