A Fedora workstation dropped me to a GRUB prompt two months ago because a partial DNF upgrade left the kernel updated but the initramfs unregenerated. I rebuilt the initramfs in eight minutes from rescue mode and did not have to reinstall. The same approach works for broken GRUB, lost root passwords, fstab disasters, and failed updates on Ubuntu, Fedora, and Arch. The trick is to triage the failure before you pick a recovery path.
What follows is the order I use, the commands I run, and the one decision that costs more time than anything else when a Linux box will not boot.
What actually failed: name the failure before you touch anything
The first reflex when a system will not boot is to reach for a live USB. Resist that reflex for a moment. The right first question is: where in the boot chain did the system stop? Each failure has a different signature, and the recovery path follows from the signature, not from the distribution.
- GRUB appears but no menu shows. The bootloader is intact but cannot find a bootable kernel. This is the easy case: edit the entry, point at the right kernel, boot, then fix the bootloader config.
- GRUB does not appear at all. The bootloader is missing or the EFI partition is corrupted. You need an external environment to repair it. This is the case where the live USB earns its keep.
- GRUB appears and the menu loads, but the kernel panics or drops to an emergency shell. The bootloader is fine, the kernel and root filesystem are not. You are looking at a filesystem error, a missing initramfs, a misconfigured fstab, or a failed update.
- The system boots but the root password is lost. The kernel and root filesystem are both fine. You just need a path to a root shell to run passwd.
The triage answer changes the command set. Naming the failure up front saves the twenty minutes you would otherwise spend trying the wrong recovery path on the wrong problem.
How systemd decides what mounts when you boot
Most modern Linux distributions are systemd-based, and the recovery options all flow from one decision: which systemd target (a named collection of services and mount points that systemd brings online together) does the kernel enter. The default is graphical.target, which loads the display manager and the full desktop stack. When that chain breaks, you can drop down to a thinner target and still have a usable system.
- multi-user.target (a network-capable multi-user system with no graphical desktop): boots a multi-user system without a graphical desktop. Useful for headless servers that you want running with networking.
- rescue.target (a single-user root shell with local filesystems mounted): mounts the local filesystems and gives you a working single-user root shell. This is the target you want 90 percent of the time.
- emergency.target (a minimal shell with only the root filesystem read-only): mounts the root filesystem read-only and gives you a bare shell. This is the target you want when the regular rescue path itself fails, usually because fstab is broken.
You can see what you are currently booting into with systemctl get-default. The recovery trick is to interrupt GRUB, edit the kernel command line, and append systemd.unit=rescue.target (or emergency.target for the deeper case). On Ubuntu’s curated Recovery Menu the (recovery mode) entry does this for you.
The live USB only when you actually need it
If your failure is in the kernel or root filesystem, you can usually recover from inside rescue mode without an external drive. The kernel boots, the root filesystem mounts, and you have access to the package manager and the standard repair tools.
The live USB becomes necessary in two situations. The first is when GRUB itself is corrupted or missing, because the system cannot reach the menu. The second is when the root filesystem is so broken that rescue mode cannot mount it. In both cases the pattern is the same: boot the live environment, mount the broken root at /mnt, bind the pseudo-filesystems into it, and chroot in to get a working shell that thinks it is running on the broken install. From there you can run the package manager, regenerate the initramfs (the small initial filesystem the kernel loads into RAM before the real root is available, used as a stepping stone to bring up block devices and drivers), reinstall the bootloader, or fix fstab.
For most cases, mount the root and bind the system directories. Skip the bind mounts and your chroot will not see /dev, /proc, or /sys, and every package manager command will fail in confusing ways.
The four recoveries I actually run
Rebuild a missing initramfs
This is the case I hit on Fedora. The kernel image is there, but the initramfs got deleted or was never regenerated after a kernel update. From rescue mode:
dracut --force
The --force flag regenerates the initramfs for the running kernel without asking. Reboot and you should be back in business. On Ubuntu, the equivalent is update-initramfs -u -k all. On Arch, run mkinitcpio -P.
Reset a lost root password
From the GRUB menu, edit the kernel entry and append init=/bin/bash instead of systemd.unit=rescue.target. This drops you straight into a root shell without a password prompt. From there, mount the root filesystem read-write and run passwd:
mount -o remount,rw /
passwd root
The mount -o remount,rw step is the part most guides skip. Without it, the password change silently fails because the filesystem is read-only, and you reboot to find the same lost password waiting for you.
Repair a broken fstab
The failure mode here is a typo in /etc/fstab that points at a UUID (Universally Unique Identifier, the persistent label the system uses to find a specific partition regardless of which physical disk it lives on) that does not exist, or a filesystem that is not yet ready. The system drops to emergency.target because rescue.target itself fails to mount everything. Boot into emergency.target, fix the fstab entry, and either run mount -a to test the corrected table or systemctl daemon-reload followed by systemctl default to resume normal boot.
The safer fix is to comment out the suspect entry, reboot to a working system, and verify the correct UUID with blkid before re-enabling the line.
Reinstall a missing GRUB
When GRUB is gone, boot from the live USB, mount the root partition at /mnt, bind the system directories, chroot in, and reinstall. On Ubuntu and Debian, the command is grub-install /dev/sda followed by update-grub. On Fedora, use grub2-install /dev/sda followed by grub2-mkconfig -o /boot/grub2/grub.cfg. On Arch, grub-install /dev/sda followed by grub-mkconfig -o /boot/grub/grub.cfg.
The detail that bites is the target device. grub-install /dev/sda writes the bootloader to the disk’s MBR (Master Boot Record, the first sector of a legacy BIOS disk that holds the bootloader pointer) or to the disk’s EFI System Partition. grub-install /dev/sda1 writes to a partition and is almost always wrong unless you know exactly why you want it. The error message is unhelpful, and a misdirected install can leave the disk in a state where the EFI firmware does not see any bootloader at all.
Trade-offs
The recovery mode in this article assumes you can still see a GRUB menu. If the firmware itself does not hand off to the bootloader, none of this helps and you are looking at a hardware problem, not a Linux problem. The recovery also assumes your root filesystem is a standard Linux filesystem (ext4, btrfs, xfs). If you are on ZFS or an LVM-on-LUKS (Linux Unified Key Setup, the Linux disk-encryption framework) stack, the mount commands change and you need a chroot environment that can see the underlying volumes. The live USB pattern still works, but the bind-mount list grows.
A full reinstall is sometimes the cleanest path, especially if the system was already in a half-broken state and you do not trust the package database. The decision is emotional more than technical: if you have good backups, reinstalling takes 30 minutes and the system comes up clean. If you do not have backups, the recovery dance above is the only way to avoid losing data.
If you have any one piece of advice I can leave you with, it is to make the live USB before you need it. A working live USB on the shelf is the difference between an eight-minute recovery and a weekend reinstall.
What I would tell past me
If I could send a message back to the version of me that sat staring at that GRUB prompt two months ago, I would say three things.
- Triage before you reach for the live USB. Naming the failure up front tells you whether you even need the external environment.
- Verify the root is mounted read-write before you run passwd. The silent failure mode is the worst kind, because you reboot to find nothing changed.
- Make a fresh live USB every six months. The one you made two years ago will not boot the new UEFI firmware, and you will discover that at the worst possible time.