Rescue an unbootable system from a live USB

general / published / guide #73 / ≈ 15 min read

Your machine will not boot. Maybe you get a black screen, a blinking cursor, a grub rescue> prompt, a "kernel panic", or a wall of red systemd errors that stops at an emergency shell. Often it follows a software update that did not finish, a typo you saved into /etc/fstab, or a bootloader that got confused after installing another operating system. It feels terminal, but it almost never is.

Here is the good news: you usually do not need to reinstall. The data is fine and the system is fine — one small piece (the bootloader, the initramfs, a config line) is broken, and you can fix it from outside. The trick is to boot a second, independent Linux from a live USB, reach into your installed system from there, repair the one broken thing, and reboot. This guide is the generic rescue procedure that fixes the great majority of "it will not boot" situations, step by step, for a complete beginner.

Everything here uses tools that are free and open source (GRUB, cryptsetup, LVM2, the arch-chroot helper, mkinitcpio/dracut/initramfs-tools — all GPL) and already present on a normal Linux ISO. You do not need to read top to bottom; the table of contents jumps to your situation, but read the first three sections once — booting the live USB, finding your partitions, and getting a chroot — because every repair below depends on them.

Make and boot a live USB

A live USB is an ordinary Linux installer on a USB stick that boots a full, throwaway Linux entirely in memory, without touching your installed system. Almost any desktop Linux ISO works — Ubuntu, Linux Mint, Fedora, Debian, Arch, Manjaro. If you have a second working computer, download an ISO and write it to a USB stick (4 GB or larger) with a free tool such as balenaEtcher, GNOME Disks, Ventoy, or the plain dd command. From another Linux box, dd is the quickest:

# Find the USB stick by its size, then write the ISO to the WHOLE disk
# (e.g. /dev/sdc, not /dev/sdc1). This erases the stick.
lsblk -o NAME,SIZE,RM,TYPE,MOUNTPOINTS
sudo dd if=~/Downloads/linux.iso of=/dev/sdX bs=4M status=progress oflag=sync

Warning: pick the live system to match your broken machine's CPU architecture. A normal desktop or laptop is 64-bit x86 (x86_64/amd64) — use a 64-bit ISO. A Raspberry Pi or other ARM board needs an ARM (aarch64/arm64) ISO. This matters because the chroot below actually runs programs from your installed system, and a program built for a different architecture simply will not run.

Boot the stick by opening your firmware boot menu at power-on — usually by tapping F12, F10, F9, Esc, or Del as the machine starts (the exact key is shown briefly on the first screen, and varies by maker) — and choosing the USB device. At the live system's menu pick "Try" / "Live", not "Install". You will land on a normal desktop or a shell prompt with full network and tools.

Warning: if your machine uses UEFI (anything from roughly the last decade), boot the live USB in UEFI mode, not legacy/CSM/BIOS mode. Some boot menus list the same stick twice — once plain, once prefixed UEFI:. Choose the UEFI: entry. This matters because UEFI bootloader repairs (the efibootmgr and grub-install commands later) can only see the firmware's efivars when the live system itself was booted via UEFI. Booting the rescue stick the wrong way is the single most common reason a GRUB reinstall "succeeds" but the machine still will not boot.

Identify your disks and partitions

Before you can repair the installed system you have to find it: which partition holds its root filesystem (/), and — on a UEFI machine — which one is the EFI System Partition (the small FAT partition that holds the bootloader). Two commands tell you everything. Run them in a terminal on the live system:

# tree of disks and partitions, with filesystem type, label and size
lsblk -f
# the same plus partition sizes and mount points
lsblk -o NAME,SIZE,FSTYPE,PARTLABEL,MOUNTPOINTS
# detailed UUIDs and types, one line per partition
sudo blkid

Read the output by size and type. Your root partition is usually the big one formatted ext4 (or btrfs, or xfs). The EFI System Partition is small (typically 100–550 MB), formatted vfat/FAT32, and often labelled. Some systems also have a separate small /boot partition. Note the device names — throughout this guide /dev/sdaX is a stand-in for your partition; an NVMe SSD shows up as /dev/nvme0n1p2 instead, and a built-in card slot as /dev/mmcblk0p2. Write down three things:

  • your root partition, e.g. /dev/sda2;
  • your EFI partition (UEFI machines), e.g. /dev/sda1;
  • a separate /boot partition, if you have one.

Tip: if lsblk -f shows a partition of type crypto_LUKS, your disk is encrypted — handle that in the next section before mounting. If it shows LVM2_member, your filesystems live inside LVM — also covered next. If you see neither, skip straight to Mount the installed system.

Unlock encryption and activate LVM (only if you have them)

If lsblk -f did not show crypto_LUKS or LVM2_member, skip this section entirely. Otherwise do the matching part first, because you cannot mount what is still locked or inactive.

Encrypted disk (LUKS)

A crypto_LUKS partition is locked. Open it with cryptsetup (free software, GPLv2+), which asks for your disk password and exposes the decrypted contents as a new device under /dev/mapper/:

# unlock the encrypted partition; "cryptroot" is a name you choose
sudo cryptsetup open /dev/sda2 cryptroot
# the decrypted device now appears here:
ls /dev/mapper/cryptroot

From now on, wherever this guide says your root partition, use /dev/mapper/cryptroot in place of /dev/sda2. If LVM lives inside the encryption (a common installer default), also do the LVM step next.

Logical volumes (LVM)

If your filesystems sit inside LVM (free software, GPLv2), the live system may not have activated them yet. Bring them online and list them with the lvm2 tools:

# scan for and activate every volume group it can find
sudo vgscan
sudo vgchange -ay
# list the logical volumes; the Path column is what you mount
sudo lvs -o lv_name,vg_name,lv_path,lv_size

Your root will be a path like /dev/mapper/vg0-root or /dev/vg0/root. Use that wherever this guide says your root partition.

Mount the installed system

Now assemble your installed system under /mnt so the live environment can reach into it. Mount root first, then — if they are separate partitions — /boot and the EFI partition inside it, in that order (the inner ones must go on top of the already-mounted root):

# 1) mount your ROOT partition at /mnt
sudo mount /dev/sda2 /mnt

# 2) if you have a SEPARATE /boot partition, mount it now
sudo mount /dev/sda3 /mnt/boot

# 3) UEFI machines: mount the EFI partition.
# Most Debian/Ubuntu systems put it at /mnt/boot/efi ...
sudo mount /dev/sda1 /mnt/boot/efi
# ... while many Arch/Fedora systems mount the ESP at /mnt/boot instead.
# Check your installed /mnt/etc/fstab to see which path YOUR system expects.

Tip: not sure where the EFI partition belongs? Look inside the system you just mounted: cat /mnt/etc/fstab lists exactly where this machine mounts /boot and the EFI partition. Mount them to the same paths here so the chroot matches the real system. If the root is Btrfs with subvolumes, you may need sudo mount -o subvol=@ /dev/sda2 /mnt — again, fstab shows the subvolume names.

Next, the part beginners most often miss. A repair run inside the chroot needs the kernel's live pseudo-filesystems — /dev (devices), /proc (process info), /sys (kernel/hardware info), and /run (runtime state) — or commands like grub-install cannot see your disks and quietly fail. There are two ways to provide them.

The easy way: arch-chroot. The arch-chroot helper (free software, GPL; in the arch-install-scripts package, and present by default on an Arch/Manjaro live ISO) mounts all of those for you and drops you into the chroot in one command — strongly recommended:

# installs the helper if your live ISO lacks it
#   Debian / Mint / Ubuntu:  sudo apt install arch-install-scripts
#   Fedora:                  sudo dnf install arch-install-scripts
# then enter the installed system in one step:
sudo arch-chroot /mnt

If that worked, you are now "inside" your installed system — skip to Common repairs. The prompt and the commands you run now act on the real system on disk, not the live USB.

The manual way: bind-mount, then chroot. If you cannot get arch-chroot, mount the four pseudo-filesystems by hand and then chroot in. Run these exactly, in order:

# make the live kernel's device and state trees visible inside /mnt
sudo mount --types proc  /proc /mnt/proc
sudo mount --rbind       /sys  /mnt/sys
sudo mount --rbind       /dev  /mnt/dev
sudo mount --rbind       /run  /mnt/run
# make the recursive binds propagate properly
sudo mount --make-rslave /mnt/sys
sudo mount --make-rslave /mnt/dev
sudo mount --make-rslave /mnt/run
# (optional, so name resolution works inside the chroot)
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
# finally, enter the installed system with bash as the shell
sudo chroot /mnt /bin/bash

Tip: after chroot your prompt may look bare. That is normal — you are in a minimal shell inside your real system. Every command below now operates on the installed system on disk. When a repair section gives apt/pacman/dnf variants, run the one for your installed distribution, not the live USB's.

Common repairs

You are now in a chroot, standing inside your installed system. Pick the repair that matches your symptom. If you are not sure which one you need, the two most common fixes after a failed boot are reinstall the bootloader and regenerate the initramfs — doing both is harmless and cures a large share of cases.

Reinstall or repair the bootloader (GRUB)

GRUB (free software, GPLv3) is the menu that loads your kernel. A missing grub rescue> prompt, a half-installed dual boot, or a wiped boot sector usually means GRUB needs reinstalling. The command differs for UEFI and BIOS machines.

On a UEFI machine (you mounted an EFI partition earlier), install GRUB into the EFI partition. Adjust --efi-directory to wherever you mounted the ESP (/boot/efi on Debian/Ubuntu, often /boot on Arch/Fedora — the path inside the chroot, without the /mnt):

# Debian / Mint / Ubuntu (GRUB binary is named grub-install)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
# Fedora is the same; on Arch the EFI dir is commonly /boot:
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB

On an older BIOS / legacy machine, install GRUB to the whole disk, not a partition:

# note the WHOLE disk (sda), NOT a partition (sda2)
grub-install --target=i386-pc /dev/sda

Warning: for a BIOS install, point grub-install at the whole disk (/dev/sda), never at a partition (/dev/sda1). Installing GRUB to a partition is unsupported, prints a "blocklists are unreliable" warning, and produces a system that will not boot.

After installing GRUB you must regenerate its menu so it lists your kernels. The command depends on your distribution:

# Debian / Mint / Ubuntu
update-grub
# Arch / Manjaro / Fedora (write the config explicitly)
grub-mkconfig -o /boot/grub/grub.cfg
# Some Fedora/UEFI layouts use this path instead:
grub-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Tip: update-grub is just a thin wrapper that Debian-family distros ship around grub-mkconfig -o /boot/grub/grub.cfg. If update-grub is "command not found" inside your chroot, you are simply not on a Debian-family system — use the grub-mkconfig form instead.

Regenerate the initramfs

The initramfs is a tiny temporary system the kernel loads first, holding the drivers needed to reach and mount your real root (disk controllers, RAID, LUKS, LVM). A botched update, a missing driver, or an "unable to find root device" / "cannot open root" panic often means the initramfs is broken or stale. Rebuild it with your distribution's tool — all three are free software (GPL):

# Debian / Mint / Ubuntu  (initramfs-tools)
update-initramfs -u -k all
# Arch / Manjaro  (mkinitcpio) — -P rebuilds every preset
mkinitcpio -P
# Fedora  (dracut) — rebuild for all installed kernels
dracut --regenerate-all --force

Tip: if you got here because an update left things in a strange state, regenerate the initramfs after finishing the package repair below — that way it is built against the fully-configured packages, not the half-installed ones.

Fix a broken /etc/fstab

A single bad line in /etc/fstab (the table of filesystems to mount at boot) can stop the whole boot and drop you into an emergency shell — typically after you edited it to add a disk and made a typo, or a UUID changed. Open it inside the chroot and check every line:

# open the table in a text editor (use nano if vi is unfamiliar)
nano /etc/fstab

Look for the usual culprits: a misspelled device or mount path, a wrong UUID= (compare each against the live output of blkid), a filesystem type that does not match, or an entry for a disk that is no longer plugged in. Correct or comment out (prefix with #) the offending line. To make a non-essential mount never block boot again, add the nofail option so the system carries on if that device is absent:

# before: a second disk that halts boot when missing
# UUID=1111-2222  /data  ext4  defaults            0  2
# after: nofail lets boot continue even if it is absent
UUID=1111-2222  /data  ext4  defaults,nofail,x-systemd.device-timeout=5  0  2

Warning: be careful editing the / (root) and EFI//boot lines — those are not optional and must point at the right UUIDs. When in doubt, change one line, save, and test by rebooting; do not rewrite the whole file blind. Keep a backup first: cp /etc/fstab /etc/fstab.bak.

Recover a half-finished package upgrade

If the machine died or lost power during an update — or an update failed and left packages half-configured — the fix is to let the package manager finish what it started. Make sure you have network in the chroot (the resolv.conf copy above), then:

# Debian / Mint / Ubuntu: finish configuring, then repair dependencies
dpkg --configure -a
apt --fix-broken install
apt update && apt full-upgrade

# Arch / Manjaro: complete the system upgrade (never a partial upgrade)
pacman -Syu

# Fedora: complete or repair the transaction
dnf upgrade --best
# if dnf reports an interrupted transaction:
dnf history redo last

Warning: on Arch, never run a partial upgrade (e.g. installing one package without -Syu) — it mixes mismatched libraries and is a frequent cause of an unbootable system in the first place. Always complete the full pacman -Syu.

After the packages are settled, it is worth regenerating the initramfs (above) and the GRUB menu, since an interrupted upgrade may have left either stale.

Reset a forgotten root or user password

Locked out rather than unbootable? Once you are in the chroot you are effectively root on the installed system, so you can set a new password with no old password needed — using passwd (free software, part of every distribution's core tools):

# reset the root account's password
passwd
# or reset a specific user (replace alice with the real username)
passwd alice

Type the new password twice when prompted (it will not echo). If the account was locked rather than just forgotten, unlock it with passwd -u alice.

Exit cleanly and reboot

When the repair is done, back out carefully — leaving the chroot, unmounting everything in one go, and (if you opened LUKS) closing the encrypted device — so nothing is left half-mounted:

# 1) leave the chroot shell
exit

# 2) unmount /mnt and everything under it, recursively, in one command
sudo umount -R /mnt

# 3) if you unlocked LUKS earlier, close it now
sudo cryptsetup close cryptroot

# 4) reboot, and remove the USB stick when the screen goes blank
sudo reboot

Tip: if umount -R /mnt complains that the target is busy, you probably still have a shell sitting inside /mnt — run cd / first, make sure you typed exit to leave the chroot, then try again. As a last resort sudo umount -R -l /mnt performs a lazy unmount, and a clean reboot flushes everything regardless.

Remove the USB stick as the machine restarts so it boots from the internal disk. If it boots — congratulations, you repaired it without reinstalling. If it still will not boot, go back through the chroot and try the other common repair (you most likely need both the bootloader and the initramfs); the error message on screen usually points at which.

Quick reference

  • Boot a live USB matching your CPU arch; on UEFI machines boot it in UEFI mode.
  • lsblk -f and sudo blkid — find your root, EFI, and /boot partitions.
  • Encrypted: sudo cryptsetup open /dev/sdaX cryptroot. LVM: sudo vgchange -ay then sudo lvs.
  • sudo mount /dev/sdaX /mnt, then mount /mnt/boot and the EFI partition (/mnt/boot/efi or /mnt/boot).
  • sudo arch-chroot /mnt — easiest chroot (mounts /dev /proc /sys /run for you).
  • GRUB (UEFI): grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB. BIOS: grub-install --target=i386-pc /dev/sda (whole disk).
  • GRUB menu: update-grub (Debian/Ubuntu) or grub-mkconfig -o /boot/grub/grub.cfg (Arch/Fedora).
  • Initramfs: update-initramfs -u -k all / mkinitcpio -P / dracut --regenerate-all --force.
  • Fstab: edit /etc/fstab, fix or comment the bad line, add nofail to non-essential mounts.
  • Upgrade: dpkg --configure -a && apt --fix-broken install / pacman -Syu / dnf upgrade.
  • Password: passwd or passwd username.
  • Exit: exit, sudo umount -R /mnt, sudo cryptsetup close cryptroot, sudo reboot.

Tools used in this guide (all free and open source)

Every program named above is free and open source — nothing on this page is paid, proprietary, or cloud. Here is each one with its project page and license:

← back to index