A failed grub update, an interrupted upgrade, a kernel that panics at boot: an unbootable Linux system feels like a locked door, but the data and the OS are still sitting on disk, intact. chroot is the key. Boot any live USB, mount the broken installation, and chroot turns your shell into a shell inside that installation, where every repair tool works as if the system were running normally.

The idea

chroot /mnt changes what a process believes / is. After it, /etc means /mnt/etc, the package database is the broken system’s database, and grub-install installs the broken system’s bootloader. You are effectively running the dead system’s userland on top of the live USB’s kernel, which is exactly the combination a repair needs.

Step by step

Boot a live environment (any major distro’s installer ISO works; matching the installed distro roughly is convenient but not required for most repairs). Then identify and mount the broken root:

lsblk -f                       # find the root partition
sudo mount /dev/nvme0n1p2 /mnt
# EFI systems: mount the EFI partition too
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

If the root lives under LUKS or LVM, open those layers first:

sudo cryptsetup open /dev/nvme0n1p2 cryptroot   # LUKS: prompts for passphrase
sudo vgchange -ay                               # activate LVM volume groups
sudo mount /dev/mapper/vg0-root /mnt

Now the part that separates a working chroot from a haunted one, the bind mounts:

for d in /dev /dev/pts /proc /sys /run; do
  sudo mount --bind $d /mnt$d
done
# EFI variable access, needed for efibootmgr/grub on UEFI:
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars 2>/dev/null

Tools inside the chroot expect /dev, /proc, and /sys to exist and reflect the actual kernel; bind mounts loan them the live system’s. Skip them and grub cannot find disks, DNS fails, and half your commands die cryptically. Finally:

sudo chroot /mnt /bin/bash

The prompt that returns is, for all practical purposes, a root shell on the broken machine. (arch-chroot /mnt, if available, does the whole mount checklist for you and works on any distro.)

The repairs you came for

Reinstall the bootloader, the most common rescue after Windows updates or disk cloning:

# UEFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi
update-grub          # Debian/Ubuntu; grub-mkconfig -o /boot/grub/grub.cfg elsewhere

# Legacy BIOS
grub-install /dev/nvme0n1
update-grub

Roll back or fix a kernel: an upgrade interrupted at the wrong moment leaves a half-written initramfs.

update-initramfs -u -k all      # Debian/Ubuntu
# or reinstall the kernel package entirely
apt reinstall linux-image-generic

Finish an interrupted upgrade:

dpkg --configure -a && apt -f install    # Debian family

Reset a forgotten password:

passwd yourusername

That last one deserves a beat of reflection: anyone with a USB stick and physical access can do this to any unencrypted Linux machine, which is the concise argument for full disk encryption on laptops.

Edit whatever config broke boot: a bad /etc/fstab line (a typo’d UUID or a missing nofail on a dead disk) is a classic silent boot-killer, and inside the chroot it is just a file to fix with any editor. blkid prints the real UUIDs to check against.

Leaving cleanly

Exit the shell and unmount in reverse:

exit
sudo umount -R /mnt
sudo reboot

umount -R releases the whole tree including bind mounts. If it complains about busy targets, close any file managers pointing into /mnt and try again.

When chroot is the wrong tool

chroot repairs a system whose disk and filesystem are healthy but whose software state is broken. It does not help when the disk itself is dying (rescue data first, with ddrescue, before any writes), when the filesystem is corrupted (run fsck from the live system, never on a mounted filesystem), or when the machine will not even reach the bootloader (firmware and hardware territory). Knowing which failure you have is half the rescue; the boot process article covers what happens in what order, which is the map for that diagnosis.

Frequently Asked Questions

What does chroot do?

chroot changes the apparent root directory for a process, so commands run as if the mounted broken system were the running system. Package managers, bootloader installers, and password tools all operate on the real installation.

Why do I need to bind mount /dev, /proc, and /sys before chrooting?

Tools inside the chroot expect kernel interfaces at those paths. Without them, device access fails, grub installers cannot see disks, and many commands error in confusing ways. Bind mounts borrow the live system kernel interfaces.

How do I chroot into a system with an EFI partition?

Mount the root partition first, then the EFI system partition on top at /mnt/boot/efi, then bind mounts, then chroot. Missing the EFI mount is the most common reason grub-install fails inside a chroot.

Can I fix a forgotten root password with chroot?

Yes. From a live USB, mount the root partition, chroot into it, and run passwd. This is also why full disk encryption matters: anyone with physical access can do the same to an unencrypted system.

What is arch-chroot?

A helper script from Arch that performs the standard bind mounts automatically before chrooting. It works on any distribution mounted at the target path and saves the manual mount checklist.

What if my root filesystem is on LVM or encrypted?

Activate the layers first from the live system: cryptsetup open for LUKS, then vgchange -ay to activate LVM volumes, and mount the logical volume as your root before proceeding with bind mounts and chroot.