Red Hat Enterprise Linux boot failures are rarely solved by memorizing one rescue command. A reliable administrator works from the boot path outward: firmware and bootloader, kernel and initramfs, systemd targets, storage discovery, filesystem mounts, and finally the services that depend on those mounts. The goal is to identify the first layer that is not behaving as expected and change only what that evidence supports.
The current EX200 objectives still require administrators to configure boot behavior, modify the bootloader, create and mount filesystems, extend logical volumes, and diagnose permission problems. Those tasks belong together operationally because a storage or mount error can stop a machine during boot even when the kernel itself is healthy. The evidence-first approach in Linux troubleshooting is therefore more useful than treating boot repair as a collection of disconnected commands.
Map the boot sequence before changing anything
On a modern RHEL system, troubleshooting begins by knowing which component owns each phase. Firmware selects the boot device, GRUB loads the selected kernel and initramfs, the initramfs discovers early storage and assembles the root filesystem, and systemd then takes over userspace startup. A symptom that appears on the console may originate several stages earlier, so the visible error is a clue rather than proof of root cause.
First determine whether the machine reaches GRUB, whether the kernel starts, whether the initramfs can locate the root device, and whether systemd reaches the configured target. That sequence narrows the search dramatically. The concepts behind Linux boot commands are most useful when they are tied to a specific stage instead of run randomly.
Capture the exact error, the last successful stage, and any recent change such as a kernel update, new storage, an edited /etc/fstab, or an LVM resize. A short chronology often reveals more than a long command transcript because boot failures are frequently change-related.
Use GRUB and kernel parameters as diagnostic tools
GRUB is not only a menu; it is a controlled place to test boot parameters without immediately making permanent configuration changes. Editing a boot entry for one startup lets an administrator try a different target, interrupt normal startup, or adjust a kernel argument while preserving the known configuration on disk.
If a system boots successfully with a temporary parameter, record that evidence before editing persistent bootloader settings. Permanent changes should be generated using the supported RHEL tooling and then verified after reboot. This avoids a common failure mode in which a manual edit appears to fix one boot but leaves the generated configuration inconsistent.
The distinction between boot selection and service startup is also important. The article on boot versus startup behavior provides useful context: a machine can load a kernel successfully yet fail later because userspace dependencies, mounts, or targets are broken.
Treat emergency and rescue modes as controlled workspaces
Emergency and rescue modes reduce the number of active services so the administrator can repair a system with fewer moving parts. They are valuable when a normal multi-user target cannot be reached, but they should not become an excuse to make broad changes without understanding dependencies.
In emergency mode, the root filesystem may be mounted read-only or only a minimal environment may be available. Confirm mount state before attempting edits. If necessary, remount the filesystem safely, make the smallest correction, and then return to the normal boot path to verify that the repair survives a clean restart.
Rescue work should preserve forensic value. Copy important configuration files before changing them, note timestamps, and avoid deleting logs that may explain why the system failed. A successful reboot is useful, but a documented root cause is what prevents recurrence across the rest of a fleet.
Diagnose fstab failures with device identity in mind
An incorrect /etc/fstab entry is one of the fastest ways to turn an otherwise healthy host into a boot problem. Misspelled mount points, wrong filesystem types, stale UUIDs, unavailable network filesystems, and inappropriate mount options can all block dependencies or force the system into emergency mode.
Prefer stable identifiers such as UUIDs or well-managed logical-volume paths rather than volatile device names that may change after hardware or enumeration changes. Compare blkid, lsblk -f, and the actual fstab entry before editing anything. If the device exists but the UUID differs, determine whether the filesystem was recreated, cloned, or replaced.
Use mount -a after an fstab change to test configuration before rebooting. That simple validation catches syntax and availability problems while the current session is still usable. For network mounts or optional devices, select options that express the real availability requirement rather than making every mount a hard boot dependency.
Separate filesystem corruption from mount and permission problems
A filesystem that will not mount is not automatically corrupt. The device may be absent, already mounted, using the wrong filesystem type, or referenced with an invalid option. Check kernel messages and mount output before reaching for repair utilities.
If corruption is suspected, use the repair tool appropriate to the filesystem and follow its operating requirements. XFS repair and ext-family checks have different procedures, and repair normally requires the filesystem to be unmounted. Running a destructive repair command against the wrong device can convert a recoverable incident into data loss.
Permission failures are a different class of problem. EX200 explicitly includes diagnosing file-permission issues, so verify ownership, mode bits, ACLs, mount options, and SELinux context before blaming the filesystem. The broader Linux device-management workflow is useful because storage devices, filesystems, permissions, and services intersect during real incidents.
Understand LVM dependencies during boot
Logical volumes add flexibility, but they also add discovery dependencies. A missing physical volume, inactive volume group, or renamed logical volume can prevent required filesystems from appearing even though the underlying disk is visible.
Use pvs, vgs, lvs, and lsblk together. The important question is not simply whether a disk exists, but whether the expected physical-volume metadata, volume group, and logical volume have been assembled. If a volume group is incomplete, do not force writes until you understand which member is missing and whether redundancy exists.
When extending storage, preserve the dependency order: add or enlarge the block device, extend the physical volume when required, grow the logical volume, and then grow the filesystem with the correct filesystem-specific tool. Verify free space at every layer so a successful LVM command is not mistaken for a successfully enlarged filesystem.
Read systemd failures as dependency information
Once the kernel and root filesystem are available, systemd becomes the best map of userspace startup. systemctl --failed, unit status, and the journal show which unit failed and which dependent units were affected. A failed mount unit can cascade into application failures that look unrelated at first glance.
Use the journal around the current boot and the failing unit rather than reading thousands of lines without a hypothesis. Look for timeouts, dependency failures, permission errors, missing paths, and repeated restart attempts. Compare the unit file and its drop-ins with the actual runtime environment.
A target that does not become active is often a dependency problem rather than a target problem. Trace the dependency chain and fix the earliest failed prerequisite. That method is faster than restarting every service that appears red in the status output.
Validate recovery with more than one reboot
A machine that boots once after manual intervention may still be fragile. Temporary GRUB edits, runtime-only mounts, manually activated volumes, or one-time service starts can hide the fact that persistent configuration remains wrong.
After repair, confirm the default systemd target, bootloader configuration, fstab entries, active volume groups, mount persistence, and required service enablement. Then reboot in a controlled window and verify both the boot path and the application path. If the incident involved storage, confirm that filesystems are mounted from the intended devices and that capacity matches expectations.
For critical systems, test the documented recovery procedure periodically. Backups of data are not enough if administrators cannot restore boot configuration, reconstruct storage mappings, or identify the correct root device under pressure.
Build a repeatable boot-troubleshooting decision tree
A good runbook begins with observable checkpoints: Is GRUB available? Does the kernel start? Does initramfs find the root device? Does the root filesystem mount? Does systemd reach the expected target? Are required application mounts and services active? Each answer sends the administrator to a smaller set of causes.
Include safe commands, expected outputs, escalation points, and rollback notes. The runbook should distinguish read-only inspection from commands that modify metadata. That distinction matters during incidents when a tired operator can easily turn diagnosis into unintended change.
Within Red Hat certifications, boot and filesystem troubleshooting is valuable precisely because it combines storage, services, permissions, and persistence. The durable skill is not memorizing rescue syntax; it is restoring the system while preserving evidence and making the repaired state reproducible.
When the root filesystem uses LVM on top of multipath, encrypted storage, or network-backed devices, the early-boot chain has additional dependencies. Troubleshooting must confirm that each layer becomes available in the expected order. A logical volume can be perfectly healthy yet invisible because the device mapper layer never received the underlying path. Record the storage stack for critical hosts before an incident so recovery does not depend on reconstructing it from memory.
Initramfs problems deserve separate attention after hardware or storage configuration changes. The initramfs contains drivers and early userspace logic required before the real root filesystem is mounted. If a storage driver, encryption configuration, or root-device reference is missing from the image, the normal system files on disk may be correct while boot still fails. Rebuild the initramfs only after identifying why the existing image cannot assemble the root path, and retain an older known-good kernel entry when possible.
Kernel updates can expose bootloader or initramfs issues that older entries did not trigger. When a newly installed kernel fails but the previous kernel boots, compare the generated boot entries, initramfs files, installed modules, and recent package transaction. Do not immediately remove the new kernel; use the working entry to restore service and investigate safely. Keeping more than one bootable kernel is an operational safety feature, not wasted disk space.
Filesystem capacity incidents can also surface during boot. A full root filesystem or exhausted inode pool can prevent services from creating runtime files, rotating logs, or updating state. Verify both bytes and inodes with tools such as df, then identify growth with directory-level inspection. Deleting arbitrary files from /var during an outage is risky; determine ownership and retention policy before reclaiming space.
For XFS, remember that shrinking is not supported in the same way as extending. Capacity planning and LVM design should leave room for growth without assuming every operation is reversible. Before manipulating filesystems, confirm backups and the direction of supported resize operations. A command that is valid for ext4 may be wrong for XFS, so filesystem identification is part of the repair procedure.
Network filesystems introduce another boot dependency. If an NFS server is unavailable, a rigid mount definition can delay boot or drop the machine into recovery unnecessarily. Use mount options and automount behavior that reflect whether the remote filesystem is essential at startup. Then test the failure mode deliberately so the host behavior is known before the remote service experiences a real outage.
SELinux context can complicate apparent filesystem failures after files are restored, copied, or mounted in new locations. Correct Unix ownership and permissions do not guarantee that confined services can read the content. If an application fails after storage recovery, inspect audit messages and file contexts before changing mode bits broadly. Restoring the expected labels is safer than weakening mandatory access control.
Finally, include out-of-band access in the recovery plan. A boot failure may remove SSH and normal monitoring at the same moment administrators need them most. Console access through virtualization, server management hardware, or cloud serial console capabilities should be tested in advance. Recovery procedures that assume the networked operating system is already healthy are incomplete.
Boot repair should also account for firmware and virtual-machine settings. A disk presented through a different controller, changed boot order, or switched firmware mode can make the operating system appear broken even though its files are intact. Compare hypervisor or hardware configuration with the last known-good state before rebuilding Linux components that may not be responsible.
After a storage incident, review monitoring coverage for free space, inode exhaustion, failed mounts, degraded volume groups, and filesystem errors. These indicators often show deterioration before a reboot exposes the problem. Prevention is cheaper when the platform can alert while the host is still reachable and fully operational.
Keep recovery media and documentation aligned with the deployed RHEL major version. Rescue procedures, bootloader locations, filesystem capabilities, and package tooling evolve. A runbook copied from an older release can create confusion precisely when administrators have the least time to verify assumptions.
A practical post-incident review should capture the earliest failed boot checkpoint, the configuration change that caused it, the recovery command sequence, and the preventive control added afterward. That turns one successful rescue into reusable operational knowledge.
After recovery, close the loop by identifying why the bad state was possible. Configuration management, peer review, staged storage changes, and boot validation after kernel or fstab modifications reduce the chance that the same class of outage reaches production again.
Keep the repair narrow and measurable: one failing dependency, one evidence-backed change, one validation cycle. That discipline scales from an EX200 lab to a large RHEL estate.