Repairing a Broken Ubuntu System with chroot

Using chroot to repair a broken Ubuntu system means changing the apparent root directory to an unbootable installation mounted in a temporary location. The rescue medium provides basic tools, while the mounted installation supplies its own package database, configuration files and boot utilities. This method can recover a machine stranded by an interrupted upgrade, a corrupted package, a faulty graphics driver or boot settings that send the machine straight into an emergency shell. It is a controlled repair workspace rather than a reinstall that erases personal files.

The first task is preservation. A chroot can make damaged software usable again, but it cannot protect against accidental changes or a failing drive. Create a current backup of important data, record the partition layout, and use a USB drive with enough space for the rescue image and downloaded packages. If the disk produces repeated input/output errors or clicking sounds, clone it before attempting repairs. Replacing a failed drive can restore a bootable system, yet data recovery and migration remain separate tasks.

Australian home computers often create a mixed recovery situation. PCs bought through local retailers in Sydney, Melbourne, Brisbane or Canberra may run Windows 11 beside Ubuntu, with BitLocker enabled and a separate EFI partition. The Windows recovery key does not unlock Linux’s own encryption, but both systems may share the same disk, making partition identification critical. A repair intended for Ubuntu must not format the EFI area or overwrite a partition belonging to another installation.

Preparing a live rescue environment

Download an Ubuntu ISO that matches the installed release when possible, verify its SHA-256 checksum against Ubuntu’s published values, and write it to a USB with balenaEtcher or Rufus. Boot in live mode so the rescue system runs from USB while the internal drive stays untouched until you mount it. The live environment includes the standard command-line tools, but an Internet connection may still be needed to download replacement packages.

The firmware boot menu is usually reached with a manufacturer-specific key such as F12, F9, Esc or F8. Select the USB device in UEFI mode rather than legacy mode when the computer supports both. Ubuntu’s signed image should work with Secure Boot, so persistent disabling of that protection is rarely necessary. If the USB is ignored, try another port, update the firmware and confirm that the image verified before changing boot settings.

Broadband outages can coincide with a failed package upgrade, making a prepared rescue USB especially valuable. Australian households often use NBN service supplied by Telstra, Optus or providers such as Aussie Broadband. Download the image while the connection works and keep a phone tether available for chroot sessions that need apt. Offline work is still possible for some package configuration and boot repairs, but a full dependency repair usually needs repositories.

Mounting the damaged root filesystem

Begin in a root terminal and compare filesystem labels, types and UUIDs rather than trusting partition order:

sudo -i
lsblk -f
blkid
findmnt

Do not assume /dev/sda1 is the root partition. NVMe devices use names such as nvme0n1p2, while eMMC storage and LVM have different layouts. The likely root filesystem is ext4, but Btrfs and XFS are also possible; a FAT32 EFI partition normally contains EFI, not /etc/os-release.

If the root partition is encrypted with LUKS, unlock it before mounting, then activate any logical volumes:

cryptsetup open /dev/nvme0n1p3 cryptroot
vgchange -ay

Skip those commands for an unencrypted setup and use the actual device names. Create the mount point and mount the root filesystem, using the example only when lsblk confirms it:

mkdir -p /mnt
mount /dev/sda2 /mnt
cat /mnt/etc/os-release

If that file is absent, unmount and reassess the layout. A Btrfs installation may require its subvolume with mount -o subvol=@ /dev/DEVICE /mnt.

Mount separate boot and EFI partitions when they exist, then bind the virtual filesystems needed by the chroot:

mkdir -p /mnt/boot/efi
mount /dev/BOOT_PARTITION /mnt/boot
mount /dev/EFI_PARTITION /mnt/boot/efi
mount --make-rslave /mnt
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount -t proc proc /mnt/proc
mount --rbind /run /mnt/run

Replace the uppercase placeholders and omit lines that do not match the machine. Use findmnt /mnt to confirm the hierarchy. The bindings give the installed system access to devices, kernel interfaces and runtime state. Missing /run commonly breaks name resolution, while missing /proc can confuse package scripts.

Entering chroot and repairing packages

Switch into the mounted installation and confirm that it is the expected release:

chroot /mnt /bin/bash
cat /etc/os-release
getent hosts archive.ubuntu.com

A working chroot produces the installed system’s /etc/os-release, not the live image’s version. An exec format error usually means the live ISO has the wrong processor architecture, such as an arm64 image being used on an amd64 computer.

Because /run is mounted, Ubuntu’s systemd-resolved stub normally follows the installed system’s resolver configuration. If the host lookup fails, leave the chroot and make a temporary resolver file while preserving the original link:

exit
cp -a /mnt/etc/resolv.conf /mnt/etc/resolv.conf.rescue-backup
rm -f /mnt/etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 9.9.9.9\n' > /mnt/etc/resolv.conf
chroot /mnt /bin/bash

Use the fallback only when necessary, and restore the saved configuration before the final reboot. Public resolvers may be blocked on some workplace or educational networks, in which case the live session’s working nameservers are a better choice.

With networking available, repair interrupted package operations in stages:

dpkg --configure -a
apt-get update
apt-get -f install
apt-get install --reinstall package-name

Read the proposed transaction before confirming it. Replace package-name with the package named in /var/log/apt/term.log or /var/log/dpkg.log; reinstalling a metapackage such as ubuntu-desktop-minimal does not automatically replace every desktop file it depends on.

Clock errors can resemble network or certificate failures. Australia’s eastern states change clocks on the first Sunday in April and October, while Brisbane and Perth do not, and Adelaide and Darwin use half-hour offsets. Check date and correct the live system’s clock before trusting HTTPS errors or log ordering. Set the installed system’s /etc/timezone and /etc/localtime to the actual location rather than assuming the live session’s timezone.

Restoring boot and graphics configuration

A damaged /etc/fstab can prevent the real root filesystem from being mounted during startup. Compare blkid with cat /etc/fstab, replace stale device names with the correct UUID= values, and test the result with mount -a inside the chroot. Correcting the file prevents the next boot from dropping into an emergency shell or offering a maintenance prompt.

Recreate the boot loader only after the root filesystem and /boot mounts are correct. An EFI directory under /sys/firmware/efi indicates UEFI; for that mode, run:

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

For legacy BIOS, install to the whole disk rather than a partition:

grub-install --target=i386-pc /dev/sda
update-grub

Replace /dev/sda with the disk identified earlier, and use the target appropriate for the architecture.

On UEFI systems, confirm that an Ubuntu entry exists with efibootmgr -v; the firmware menu can boot /EFI/ubuntu/shimx64.efi when an entry is missing. Secure Boot requires signed shim and kernel components, so avoid replacing them with unsigned files. A custom kernel may require a Machine Owner Key, whereas Ubuntu’s own packages should retain the normal signing chain.

A black screen can result from a mismatched proprietary driver rather than a failed boot loader. Intel, AMD and NVIDIA combinations are common in Australian retail and enthusiast PCs. Use lspci -nnk to identify the device and ubuntu-drivers devices to list a matching recommendation, then reinstall the selected package. Rebuild boot images with update-initramfs -u -k all and refresh GRUB. After the display server returns, customising the GNOME desktop is a separate and safer task.

Returning safely to the installed system

Restore the original resolver configuration if the temporary one was used, then flush pending writes and unmount everything cleanly:

rm -f /mnt/etc/resolv.conf
mv /mnt/etc/resolv.conf.rescue-backup /mnt/etc/resolv.conf
sync
exit
umount -R /mnt

Omit the first two commands when no resolver backup exists. If recursive unmounting reports a busy target, inspect remaining mounts with findmnt, close programs using /mnt, and unmount nested boot or EFI mounts before the root filesystem.

Reboot and select the installed Ubuntu system from the firmware menu. Remove the rescue USB only after a successful boot, then check networking, sound, graphics and pending updates. If the repair fails, boot the live environment again and mount the installation. From an emergency shell, systemctl --failed and journalctl -b -1 -p err can reveal service failures; from live media, point journalctl at /mnt/var/log/journal when a persistent journal exists.

The point to remember is that chroot turns the broken installation into a repairable workspace without reinstalling the distribution. The correct filesystem, package state and boot configuration must all point to the same system; when they do, Ubuntu can return without surrendering the data and customisations already on its disk.