A Linux system that will not boot needs diagnosis before repair. A missing boot menu, an emergency shell and a black screen after login point to different failures. Reinstalling GRUB for all three is rather like replacing a front door because the kitchen light stopped working.
Start by protecting your files, identify the last successful stage of startup, then make the smallest reversible change. This guide covers desktop recovery using an older kernel, recovery mode or live USB, with separate paths for graphics, storage, filesystem and bootloader problems. For restoring saved files or system images, use the parent guide to backing up and restoring your Linux desktop.
Protect Your Data Before Attempting Repairs
If the drive clicks, repeatedly disappears or produces input/output errors, stop ordinary software repair attempts. A filesystem repair changes data structures on disk; it is not a treatment for failing hardware. The GNU ddrescue safety guidance recommends copying a failing drive and attempting repairs on the copy rather than the original.
With irreplaceable files and suspected physical damage, consider professional recovery before powering the drive up again. Repeated boot attempts, long diagnostics and enthusiastic repair buttons can consume time the device does not have.
If the storage appears stable, record what happened immediately before the failure. Useful clues include a kernel update, interrupted upgrade, graphics driver installation, edited mount configuration, firmware reset or newly attached drive. Photograph the error screen before restarting.
Keep an external backup drive separate from any USB stick you intend to overwrite with installation media. Also locate encryption passphrases and recovery keys before making changes. A working rescue environment does not remove the need to unlock encrypted storage.
Do not format partitions, create a new partition table or accept an installer’s erase option while investigating. Those actions belong to a deliberate reinstall, after verified backups, not the diagnostic stage.
Identify Where Startup Stops
Describe the failure by what appears on screen, rather than calling every unsuccessful startup a bootloader problem. The following distinctions help choose the next test.
| What you see | Area to investigate | First useful check |
|---|---|---|
| No manufacturer logo or firmware screen | Power, display or hardware startup | Check power, monitor input and hardware diagnostics |
| “No bootable device” or firmware setup | Drive detection, boot order or boot entry | Check whether firmware detects the internal drive |
| A GRUB prompt instead of the normal menu | Bootloader files or configuration | Prepare matching rescue media |
| A kernel panic or early recovery shell | Kernel, early startup image or root storage | Try the previous working kernel |
| Emergency mode with a failed mount | Filesystem, device availability or mount configuration | Read the named failure and identify its device |
| Black screen or repeated login screen | Graphics, desktop session or account state | Try a text console |
Treat these as starting points, not verdicts. A black screen alone does not establish whether Linux loaded, and an error mentioning a disk does not establish that the disk is physically damaged.
If no live USB will start either, widen the investigation beyond the installed system. Check the image, USB stick, firmware compatibility and hardware. The guide to checking Linux hardware compatibility helps separate hardware support questions from damage to an existing installation.
Try Reversible Recovery Options First
Boot the previous working kernel
If the failure began after a kernel update, select the previously working kernel from the boot menu. On systems using GRUB, older entries may appear directly or inside an advanced options submenu. Select the normal entry for that version, rather than its recovery entry, for the first test. This is also the starting approach in Rocky Linux’s kernel panic recovery procedure.
If that kernel boots, back up important files before investigating further. Record which version works and which fails. The comparison narrows the problem, but does not prove that the new kernel itself is defective: its accompanying startup image or external driver modules may differ too.
Keep the working kernel installed until the repaired replacement has booted successfully. Avoid removing several kernel versions at once simply to make the menu tidier.
Use recovery mode when available
On Ubuntu systems using GRUB, recovery mode provides a route into a smaller startup environment. Menu availability and labels can vary, but the usual sequence is:
- Open the GRUB menu during startup. Holding Shift commonly applies to BIOS startup; pressing Esc commonly applies to UEFI startup.
- Select Advanced options for Ubuntu.
- Choose an entry ending in recovery mode.
- Select the diagnostic option you need, or the root shell when following a documented repair procedure.
The root filesystem initially being read only is expected in this recovery path. A failed attempt to save a configuration file does not automatically mean the drive has failed. Check the filesystem state before changing it, following the Ubuntu recovery mode procedure.
Do not assume another distribution has the same menu. A bootloader recovery entry, systemd emergency mode and an installer’s rescue environment are different tools, even when all three lead to a plain text screen.
Use a Live USB When the Installed System Is Inaccessible
Create rescue media on another computer using an official distribution image. Prefer the installed distribution’s release and architecture when available, particularly for bootloader or package repairs. Follow the instructions for creating a bootable Linux USB drive, taking care to select the USB device rather than a backup disk.
Use the computer’s temporary boot menu to select the USB. Choose a live session or rescue option, not installation. Debian’s installer, for example, has a separate rescue mode that detects hardware and provides access to the installed system without performing a normal installation; the entry process is covered in the Debian installer recovery instructions.
Before mounting anything, identify the internal drive by its model, capacity and partition layout. Do not assume that the first drive listed is the correct one. Adding USB storage can change the order in which devices appear.
Identify the Linux root filesystem, any separate home or boot filesystem, and the EFI System Partition if present. Encrypted storage, LVM and software RAID add layers between a physical partition and the filesystem you need. The overview of Linux filesystems and directory structure explains why these locations have different roles.
For apparently healthy storage, copy irreplaceable files to a different physical device before making repairs. Include hidden folders where needed: application profiles, SSH configuration, password manager databases and local project settings may not appear in a default file manager view. Open a selection of copied files from the destination to check the result.
Use a rescue environment’s read only inspection option when appropriate. Do not assume that opening a partition in a desktop file manager leaves it unchanged. If the drive shows hardware errors, return to the imaging or professional recovery path rather than browsing it repeatedly.
Read the Installed System’s Logs, Not the USB’s Logs
Once you have access through an older kernel, recovery environment or live session, collect evidence before changing packages. On systems using systemd, journalctl can select recorded boots and read journal files from another directory or mounted system. These capabilities are documented in the systemd journalctl manual.
The distinction matters. From a live USB, an ordinary log viewer may show the USB session’s successful startup, not the installed system’s failure. Select the installed system’s saved journal and identify the failed attempt by its timestamp or boot identifier.
If you booted successfully using an older kernel, the failed attempt may be the previous recorded boot. After several rescue attempts, that assumption becomes less useful. Check dates rather than repeatedly asking for “the previous boot.” Saved logs may also be absent if the installation did not retain them or failed before they could be written.
Look for the first actionable failure and its context: a missing device, failed mount, rejected driver, package error or exhausted filesystem. Later messages may be consequences. The last line on a frozen screen is not automatically the culprit.
For filtering messages and investigating a named service, use the guide to troubleshooting Linux services with journalctl. Save relevant output somewhere other than the affected filesystem, and remove secrets before sharing it publicly.
Repair the Failure You Actually Have
Black screen after the boot menu
Try switching to a text console with Ctrl + Alt + F3. Some laptops also need Fn; the available console number can vary. If a login prompt appears and accepts your account, Linux has progressed beyond the bootloader and early storage stages. Concentrate on the graphical login service, graphics driver and desktop session.
Check whether the problem began with a graphics driver or kernel update. An external driver module may need to match the running kernel. Secure Boot introduces a separate trust check: Ubuntu validates loadable kernel modules before accepting them, as covered in its UEFI Secure Boot documentation.
Do not disable Secure Boot as a reflex. First establish whether the failure involves a missing module, an unsuccessful build or a signing and enrollment problem. These require different repairs. A previous working kernel or a documented temporary graphics recovery option can provide access without turning a diagnostic workaround into permanent configuration.
Keep driver work within the distribution’s supported packaging route. The guide to installing and troubleshooting NVIDIA and AMD graphics drivers covers that repair path without mixing it into bootloader recovery.
If the login screen appears but returns immediately after authentication, also check free space and account ownership. Avoid blanket permission changes across a home directory or the entire system. Use the guide to Linux file permissions and ownership to investigate the affected files instead.
Kernel panic or an initramfs shell
The initramfs is an early userspace environment used before the normal root filesystem takes over. Its role is covered in the Linux kernel documentation on rootfs and initramfs. An early shell therefore does not, by itself, mean your personal files are gone.
Read the error before choosing a repair. “Cannot find root device,” a failed encryption unlock and a filesystem requiring attention describe different situations. Check whether the expected drive is present, whether encrypted storage has been unlocked, and whether the boot configuration points to the correct filesystem identifier.
Recent changes help narrow the search. After cloning or repartitioning, compare configured identifiers with the devices that now exist. After a kernel update, check whether the kernel, its modules and its generated early startup image were installed successfully.
If the previous kernel works but the replacement consistently fails, repair the replacement’s packages and regenerate its startup image using that distribution’s documented tools. Do not borrow an initramfs image from another computer or distribution.
Preserve the working boot entry throughout. Rebuilding every installed startup image at once removes a useful fallback and makes the next failure harder to isolate.
Emergency mode after a failed mount
A required mount can block normal startup even when the root filesystem is usable. Check the named mount against /etc/fstab and the available devices. On systemd installations, entries in that file become mount units; the systemd mount documentation also defines how optional mounts can avoid becoming startup requirements.
A practical example is a desktop with an internal data drive that was removed or replaced. Its old identifier remains in the mount configuration, so startup waits for a device that no longer exists. Reinstalling the bootloader will not correct that entry.
Back up the configuration file before editing it. Correct the stale identifier or review whether a genuinely optional data drive should be required during startup. Do not make the root filesystem, essential system storage or an unresolved failing drive “optional” simply to suppress an error.
After correcting a mount, confirm that the expected files are actually present. A successfully started desktop is not enough if an application now writes into an empty directory where another filesystem should have been mounted.
Interrupted update or a full filesystem
If startup failed after an interrupted upgrade, inspect the package manager’s recorded state and available storage before repeating the operation. Check separate filesystems individually: free space in the home directory does not establish that the root or boot filesystem has room.
Use the installed distribution’s package repair workflow to complete unfinished configuration or restore affected packages. Review proposed removals before accepting them. A recovery operation that unexpectedly proposes removing the desktop, bootloader or most of the kernel packages deserves a pause, not a faster press of Enter.
Do not manually delete arbitrary files from the boot directory to make room. Remove obsolete kernels through the package manager while retaining the running kernel and a working fallback. The guide to APT, DNF and Pacman explains why package records must remain consistent with the files on disk.
Also avoid deleting package lock files just because an error mentions one. Establish whether an update process is still running and follow the distribution’s recovery instructions. A lock message is evidence to inspect, not a request to remove the nearest file.
Filesystem errors requiring offline repair
Before checking a filesystem, identify its type and the device that actually contains it. For encrypted storage or LVM, that may be an unlocked mapped device or logical volume rather than the physical partition. Do not direct a filesystem repair at an encrypted container, an LVM physical volume or the whole disk by guesswork.
For ext2, ext3 and ext4, e2fsck is the relevant checker. Repair should take place with the target filesystem unmounted; the e2fsck manual supplied by Debian warns against checking mounted filesystems and explains that even certain nonwriting checks produce invalid results while mounted.
A live environment is useful because the installed root filesystem need not be in use. Close file manager windows and confirm the target is unmounted before proceeding. Being in “recovery mode” does not establish this automatically.
Btrfs needs a different approach. Its checker is not an invitation to enable repair mode whenever startup fails. The Btrfs filesystem checker documentation explicitly warns against repair without advice from a developer or experienced user. XFS also has its own checking and repair workflow.
If the device reports hardware read errors, stop here. Filesystem repair belongs after data preservation and storage assessment, not before.
No bootable device or a broken bootloader
Start in firmware setup. Does it detect the internal drive? Is the expected Linux boot entry available in the temporary boot menu? Did a firmware reset change the startup mode or boot order? Restore only settings you know were changed; do not cycle through storage controller modes hoping one works.
If selecting the Linux entry starts the system, investigate the default boot selection before reinstalling anything. On machines sharing Windows and Linux, the guide to dual booting Linux and Windows provides the wider boot arrangement.
Have the Windows recovery key available before altering security settings on a BitLocker protected machine. Secure Boot changes can trigger recovery, and resetting its trust settings can create another startup failure; these cases appear in Microsoft’s Secure Boot troubleshooting guidance.
If bootloader repair is necessary, match the installed distribution, actual bootloader and firmware mode. UEFI and legacy BIOS procedures are not interchangeable. Nor does every Linux installation use GRUB.
Fedora provides a useful warning against generic recipes: its UEFI recovery procedure reinstalls the relevant bootloader packages rather than using the BIOS style installation approach. Follow the Fedora GRUB recovery instructions for that system instead of adapting unrelated commands.
Identify the existing EFI System Partition before repairing a UEFI installation. Do not format it to “start fresh,” especially on a shared machine. Repairing Linux should not become an accidental removal of another operating system’s boot files.
When Repairs Need the Installed System’s Environment
A package operation performed in a live desktop normally acts on that live environment, not automatically on the installation mounted beneath it. Some repairs therefore require a rescue shell rooted in the installed filesystem, often using chroot. Red Hat distinguishes the temporary rescue root from the installed root in its installation rescue documentation.
Before entering that environment, identify and mount the correct root filesystem, along with any separate boot and EFI filesystems required by the repair. Encrypted volumes, LVM and Btrfs subvolumes make a copied generic recipe particularly risky.
A chroot is not a virtual machine and does not boot the installed kernel. Follow the distribution’s procedure for the supporting mounts and tools it requires. If you cannot confidently identify the storage layout, stop and obtain help rather than installing a bootloader to whichever device happens to appear first.
Choose Between Rollback, Restoration and Reinstallation
If the distribution offers a documented previous deployment or bootable system snapshot, consider that route before manually replacing packages. Check what the rollback includes. Do not assume it also restores personal files, a separate boot partition or every later configuration change.
Use a verified system backup when it offers a clearer route than repairing a badly inconsistent installation. Recover newer personal files before restoring an older image, and confirm the destination disk carefully.
A clean installation becomes reasonable when the operating system is badly damaged but the hardware is sound and important files are safely copied elsewhere. Follow the guide to installing Linux on your computer, checking every partition and formatting choice.
Do not rely on an installer preserving a home directory without an independent backup. Preservation options do not protect against selecting the wrong partition. Reinstalling also does not repair a failing SSD or hard drive.
Verify the Repair Before Removing Your Fallback
After Linux starts, confirm that expected filesystems are mounted, personal files are accessible and applications open normally. Check the logs for repeated storage errors or failed services. If a service still needs attention, use the guide to managing Linux services with systemd rather than disabling unrelated units.
Restart once more using the intended default boot entry. A successful boot selected manually from a recovery menu does not establish that the next unattended startup will work.
Keep the working kernel, rescue USB and recovery notes until the replacement has proved usable. If you temporarily selected an older kernel, plan a return to a supported working update rather than freezing the machine indefinitely. The guide to managing Linux security updates covers that maintenance work.
Record the original error and the change that fixed it. The useful outcome is not just a desktop that appears again: it is a system with its data intact, a known cause addressed and a recovery route ready for the next failure.