Recover a Linux System from a Live USB

When a Linux system won't boot—bad GRUB config, corrupted fstab, forgotten root password, failed kernel update—a live USB is your recovery toolkit. This guide walks through the full recovery workflow: mounting the broken system's partitions, entering a chroot environment, and fixing the most common causes of an unbootable machine. You do not need to reinstall.

Boot from a Live USB

Use any Linux live environment that matches or is close to your installed distro's architecture (x86_64 in nearly all modern cases). Ubuntu, Fedora, and Arch ISO images all work fine as rescue environments. Boot the ISO, choose "Try" or "Live" mode (not install), and open a terminal.

Identify the Target Partitions

Find the block devices belonging to your installed system before mounting anything.

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

Look for your root partition (ext4, btrfs, xfs) and, if separate, your EFI System Partition (ESP, type vfat, typically 100–600 MB) and /boot. Typical output will show devices like sda, nvme0n1, or vda with numbered partitions. If the filesystem type column is blank for a partition, it may be encrypted (see the LUKS note below).

sudo fdisk -l /dev/sda

Note the partition numbers. A common layout on a GPT/UEFI system: /dev/sda1 = ESP, /dev/sda2 = /boot, /dev/sda3 = root. On BIOS/MBR systems there is usually no ESP.

Unlocking LUKS Encryption (if applicable)

If your root partition is encrypted, unlock it first before mounting.

sudo cryptsetup open /dev/sda3 cryptroot

Enter the passphrase when prompted. The decrypted device then appears at /dev/mapper/cryptroot. Use that path wherever the guide refers to the root partition going forward.

Mount the Installed System

Create a mount point and mount root first, then any sub-mounts your system uses.

sudo mkdir -p /mnt/sysroot
sudo mount /dev/sda3 /mnt/sysroot

If /boot is a separate partition, mount it under the root:

sudo mount /dev/sda2 /mnt/sysroot/boot

On UEFI systems, mount the ESP:

sudo mount /dev/sda1 /mnt/sysroot/boot/efi

If you use Btrfs with subvolumes, specify the subvolume name. The root subvolume is commonly named @:

sudo mount -o subvol=@ /dev/sda3 /mnt/sysroot

Bind the Virtual Filesystems and Enter chroot

The chroot environment needs access to the kernel's virtual filesystems—/dev, /proc, /sys, and /run—to run tools like grub-install, update-grub, dracut, or passwd correctly.

sudo mount --rbind /dev  /mnt/sysroot/dev
sudo mount --rbind /proc /mnt/sysroot/proc
sudo mount --rbind /sys  /mnt/sysroot/sys
sudo mount --rbind /run  /mnt/sysroot/run

sudo chroot /mnt/sysroot /bin/bash

Your prompt changes to reflect you are now operating inside the installed system. Commands you run here affect the installed system's files, not the live environment.

Optionally source the environment to get correct PATH and locale:

source /etc/profile
export PS1="(chroot) $PS1"

Fix a Broken fstab

A corrupted or incorrect /etc/fstab is a top cause of boot failure. The most common mistakes are a wrong UUID, a missing mount point, or a bad options field.

Find the Correct UUIDs

blkid

Match each device to its UUID. Then edit fstab:

nano /etc/fstab

Each non-comment line must follow the format: UUID=xxxx /mountpoint fstype options dump pass. The root entry must have pass set to 1; other local filesystems should be 2; swap and network filesystems should be 0.

Validate fstab syntax without rebooting (run this inside the chroot):

findmnt --verify --verbose

Reset a Forgotten Root or User Password

Inside the chroot you have full access to passwd. No tricks required.

Reset the root password:

passwd root

Reset a regular user's password:

passwd username

Type the new password twice when prompted. The change is written directly to /etc/shadow in the installed system.

Repair or Reinstall GRUB

GRUB problems are the most frequent reason to use a live USB. The steps differ between UEFI and BIOS systems, and between distro families.

UEFI Systems

Debian/Ubuntu:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

Fedora/RHEL/Rocky:

grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Arch:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ARCH
grub-mkconfig -o /boot/grub/grub.cfg

BIOS/MBR Systems

Replace /dev/sda with the actual disk (not a partition—no number).

Debian/Ubuntu:

grub-install /dev/sda
update-grub

Fedora/RHEL/Rocky:

grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

Arch:

grub-install --target=i386-pc /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

Rebuilding the initramfs

If a kernel update was interrupted or an initramfs is missing, rebuild it inside the chroot.

Debian/Ubuntu:

update-initramfs -u -k all

Fedora/RHEL/Rocky:

dracut --force --regenerate-all

Arch:

mkinitcpio -P

Exit and Unmount Cleanly

A dirty unmount can leave the filesystem in an inconsistent state. Exit the chroot first, then unmount in reverse order.

exit

sudo umount -R /mnt/sysroot

The -R flag recursively unmounts all bind mounts. If any mount is busy, run sudo fuser -km /mnt/sysroot to kill processes using it, then retry. Remove the live USB and reboot.

Verification After Reboot

After the system boots, confirm the fixes held.

Check all filesystems mounted correctly per fstab:

findmnt --verify

Confirm GRUB version and config path:

grub-install --version
ls /boot/grub/grub.cfg

Review recent boot logs for errors:

journalctl -b -p err

Troubleshooting

• chroot fails with "cannot run command '/bin/bash': Exec format error": Your live USB is a different architecture (e.g., 32-bit ISO on a 64-bit system). Use a matching ISO, or install qemu-user-static and use arch-chroot from the arch-install-scripts package for cross-arch chroot.
• grub-install says "cannot find EFI directory": The ESP is not mounted at /boot/efi inside the chroot. Double-check your mount step and run ls /boot/efi/EFI to confirm it is populated.
• System still drops to emergency shell after reboot: The unit that failed will be printed on screen. Run journalctl -xb for full context. A common cause is an fstab entry for a device that no longer exists—comment it out temporarily and reboot again.
• Password reset appears to work but login still fails: Check that SELinux or AppArmor isn't relabeling the shadow file incorrectly. On SELinux systems, run restorecon -v /etc/shadow inside the chroot before exiting.
• Btrfs root won't mount: Try mounting without a subvolume option first to inspect subvolume layout: sudo mount /dev/sda3 /mnt/sysroot, then sudo btrfs subvolume list /mnt/sysroot.