Booting a rescue or live system and chrooting into an installed Linux to repair it

Goal

Repair an installed Linux system (reinstall a bootloader, fix a package, reset a password, edit a config the installed system cannot boot far enough to edit itself) from an independent rescue or live medium, using the installed system's own binaries via chroot.

Prerequisites

A rescue or live medium (installer rescue mode, live USB or cloud rescue image) of a compatible CPU architecture; root on that medium; the installed disks visible to it, with any encryption passphrase at hand.

Steps

1. Boot the rescue/live medium and identify the installed root partition: lsblk -f or blkid to match filesystem labels/UUIDs against what the installed /etc/fstab expects.
2. Mount the installed root at a working directory, for example mount /dev/<root-partition> /mnt (on Btrfs name the root subvolume, e.g. -o subvol=@ on Ubuntu or -o subvol=root on Fedora). If /boot or /boot/efi are on separate partitions, mount them at their subdirectories under /mnt before proceeding — the chroot needs to see them at the paths the installed system expects.
3. Make the kernel's virtual filesystems visible inside the target: for d in dev proc sys run; do mount --rbind /$d /mnt/$d; mount --make-rslave /mnt/$d; done. --rbind also carries submounts such as /dev/pts and, on a UEFI-booted rescue system, /sys/firmware/efi/efivars; a plain --bind of /sys does not include efivarfs (mount it with mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars in that case). --make-rslave keeps a later recursive unmount from propagating back into the rescue system. The rescue medium must itself be booted in UEFI mode, or no EFI variables exist to write.
4. Enter the chroot: chroot /mnt /bin/bash runs the shell "with root directory set to" /mnt (chroot(1)), so programs resolve paths and configuration from the installed system.
5. Do the repair with the installed system's own tools. Boot loader, BIOS/MBR: grub-install /dev/<disk> (whole disk; grub2-install on RHEL). UEFI on Debian/Ubuntu: grub-install --target=x86_64-efi --efi-directory=/boot/efi. UEFI on RHEL-family: do not run grub2-install (it would replace the signed Secure Boot chain); reinstall the packages instead, e.g. dnf reinstall shim-x64 grub2-efi-x64 (needs repository access from inside the chroot). Then regenerate grub.cfg at the path the distribution uses. Other repairs: reinstall a package, edit /etc/fstab, passwd <user> (on SELinux systems then touch /.autorelabel), rebuild an initramfs (name the kernel version explicitly).
6. Exit the chroot, run sync, then umount -R /mnt, which unmounts the bind mounts, /boot/efi, /boot and the root in the right order. If it reports a busy target, find the process (fuser -vm /mnt) rather than forcing it.
7. Reboot, removing the rescue medium, and confirm the system now starts normally.

Expected result

Commands run inside the chroot behave as if run natively on the installed system; after unmounting and rebooting, the installed system boots on its own.

Limits and test basis

A chroot shares the rescue kernel, not the installed system's own, and does not isolate networking, users or process IDs — commands inside it run with full root privileges on the host. If the installed root uses LVM, RAID or LUKS, activate those layers (vgchange -ay, mdadm --assemble, cryptsetup open) before the first mount step. A missing efivarfs inside the chroot is a common cause of grub-install failing on UEFI systems, since it needs the EFI variables to write the boot entry.