Chroot utility

chroot is an utility that changes which folder is considered the root of the filesystem hierarchy by its child processes, so that it is impossible for them to access the parent folder of the new root, even though it physically exists on the disk.

Common use-cases

• Fast switching to another environment (distro, version, flavor, package mix etc) for the purposes of testing, building, debugging etc.
• Repairing a broken Linux installation by connecting its primary drive as an external device (for example using an USB enclosure) to some other working system and performing operations from within the system being repaired.
• Historically chroot was also used to increase the security of network services running on a given machine: if an attacker managed to trick a service to an arbitrary code execution, he would still not have access to the whole filesystem of the machine (he would remain in a so called chroot jail). This however does not prevent the attacker from using the machine's network interfaces to further penetrate the internal network, moreover on Linux and some other UNIXes, escaping a "chroot jail" is relatively easy. As a result, for security-related purposes chroot was replaced by virtual machines and containers.

Note: chroot utility is intended mostly for an occasional, ad-hoc usage. If you regularly need to switch to different environments, then consider more robust systems that automate setting up and offer greater flexibility, such as schroot or Podman.

---

---

Basic setup and usage

Unless explicitly stated otherwise, all commands in the below subsections require `root` privileges.

Create or provide a file hierarchy of a Linux system

In the subsequent sections, ${chrootFolder} will refer to the root folder of a file hierarchy created or provided as described below.

• In case of switching to existing installations, it boils down to mounting their root filesystem at a target folder of your choice.
• In case you want to create a fresh Debian image, you can use utilities such as mmdebstrap, for example to create a clean environment to build deb packages:

  mmdebstrap --skip=output/dev,output/mknod --variant=buildd \
      trixie "${chrootFolder}" http://deb.debian.org/debian

Mount virtual filesystems

As of 2026 these are proc, sysfs, udev and "children" of the latter 2 of which there are too many and which also tend to die off or spawn way too often. Fortunately, mount has --rbind option that allows to bind an already mounted filesystem together with all its children to an additional target folder. Of course systemd decided to break some basic functionality, so you additionally need to use either --make-rslave or --make-rprivate flag to enforce the proper behavior (see man mount_namespaces for details).

mount -t proc proc "${chrootFolder}/proc"
mount --rbind --make-rslave /sys "${chrootFolder}/sys"
mount --rbind --make-rslave /dev "${chrootFolder}/dev"

In case you are wondering: proc has 1 child also: binfmt_misc, which is used for registering binary executable handlers/interpreters, which does not make sense in a chroot (the absolute path of a given interpreter needs to be provided, which is inaccessible from a chroot-ed context), therefore no point in binding it.

Copy the DNS resolver config

cp /etc/resolv.conf "${chrootFolder}/etc/"

Perform a chroot switch

This usually boils down to

chroot "${chrootFolder}"

...which will start an interactive login shell of root user inside the chroot-ed environment, so that you can interactively perform whatever tasks you need.

For non-interactive tasks, you can instead provide an alternative command and its args:

chroot "${chrootFolder}" /root/myScriptToBeExecutedInChroot.sh myArg1 myArg2

/root/myScriptToBeExecutedInChroot.sh is a path inside the chroot-ed hierarchy.

Cleanup

After the chroot process exits, you need to unbind / umount all the virtual filesystems bound / mounted previously. Fortunately umount also has --recursive / -R flag to help with this:

umount -R "${chrootFolder}/dev"
umount -R "${chrootFolder}/sys"
umount -R "${chrootFolder}/proc"

If ${chrootFolder} is a mount point of an external drive and you want to umount it also, you can replace all the above commands with the below single one:

umount -R "${chrootFolder}"

---

---

Additional notes and scenarios

Running X11 GUI apps

Running X11 GUI apps from within a chroot-ed environment and displaying them on host's X11 server works using standard mechanisms: just export the value of DISPLAY env var from the host in the chroot and make sure the host X server will allow connections (for example using xhost utility).

Running Systemd services

Systemd services will generally refuse to run in a chroot-ed environment. Use systemd-nspawn instead of chroot if you need to run Systemd services.

Foreign architectures

If qemu-user-binfmt is installed, it is possible to chroot to a filesystem for any foreign arch it supports.

Modifying boot data

If you want to modify the boot data of another system whose drive you chroot-ed into (this includes for example running update-grub, update-initramfs, installing a new kernel or firmware + kernel modules for boot-critical devices etc), you need to mount its /boot hierarchy. This may include the following:

• /boot itself is sometimes a separate partition, most commonly on systems using some disk encryption scheme.
• On UEFI systems (which includes most of modern x86 and ARM hardware), their ESP partitions are mounted at /boot/efi.

It is usually most convenient to mount these filesystems right after performing a chroot switch.

After performing a chroot switch, check which filesystem are present by running grep /boot /etc/fstab. Below is an example output from a system with both /boot and /boot/efi entries:

UUID=7a307683-255a-4bac-937f-95aa2af2ca17  /boot      ext4  defaults    0  2
UUID=4D18-6163                             /boot/efi  vfat  umask=0077  0  1

If /etc/fstab entries use UUIDs as in the example above (which is the default on most modern distros) or unique PARTLABELs or LABELs, then all you need to do is to point mount to their corresponding mount-points:

mount /boot
mount /boot/efi

On some older systems, instead of UUIDs or labels, device nodes may be used in /etc/fstab, like for example /dev/sdaX etc. In such case you need to figure out what device node currently corresponds to a given filesystem. Most commonly, it will be another partition on the same physical drive as the root filesystem of that external system.

After you are done with your chroot work, these filesystems may be umount-ed either from within the chroot or after exiting.