Chroot

Chroot (Change root) - on Unix operating systems is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. This modified environment is called a chroot jail.

Reasoning

Changing root is commonly done for performing system maintenance on systems where booting and/or logging in is no longer possible. Common examples are:

• Reinstalling the bootloader.
• Rebuilding the initramfs image.
• Upgrading or downgrading packages.
• Resetting a forgotten password.

Requirements

• Root privilege..
• Another Linux environment, e.g. a LiveCD or USB flash media, or from another existing Linux distribution.
• Matching architecture environments; i.e. the chroot from and chroot to. The architecture of the current environment can be discovered with: uname -m (e.g. i686 or x86_64).
• Kernel modules loaded that are needed in the chroot environment.
• Swap enabled if needed: swapon /dev/sdxY
• Internet connection established if needed.

Partition(s) mount

The root partition of the Linux system that you are trying to chroot into needs to be mounted first. To find out the device name assigned by the kernel, run:

# lsblk

Then create a directory for mounting the root partition to, and mount it:

# mkdir /mnt/arch
# mount /dev/sdx1 /mnt/arch

Next, if there are separate filesystems for other system directories

# mount /dev/sdx2 /mnt/arch/boot/
# mount /dev/sdx3 /mnt/arch/home/

Note: If trying to access an encrypted filesystem, do not forget to first unlock its container (e.g. with # cryptsetup open /dev/sdX# name for dm-crypt/LUKS-based encryption), then mount the device using its previously supplied device-mapper 'name (under the form # mount /dev/mapper/name /mnt/arch/...

Change root

Using arch-chroot

The bash script arch-chroot is part of the arch-install-scripts package from the official repositories. Before running /usr/bin/chroot, the script mounts api filesystems like /proc and makes /etc/resolv.conf available from the chroot.

Run arch-chroot with the new root directory as first argument:

# arch-chroot /mnt/arch

To run a bash shell instead of the default sh:

# arch-chroot /mnt/arch /bin/bash

To run mkinitcpio -p linux from the chroot, and exit again:

# arch-chroot /mnt/arch /usr/bin/mkinitcpio -p linux

Using chroot

Mount the temporary api filesystems:

# cd /mnt/arch
# mount -t proc proc proc/
# mount --rbind /sys sys/
# mount --rbind /dev dev/

And optionally:

# mount --rbind /run run/

To use an internet connection in the chroot environment copy over the DNS details::

# cp /etc/resolv.conf etc/resolv.conf

To change root into a bash shell:

# chroot /mnt/arch /bin/bash

If you see the error:

::*<code> chroot: cannot run command '/usr/bin/bash': Exec format error </code>  , it is likely that the architectures of the host environment and chroot environment do not match.
::*<code> chroot: '/usr/bin/bash': permission denied </code>, remount with the exec permission: <code> mount -o remount,exec /mnt/arch. </code>

After chrooting it may be necessary to load the local bash configuration:

# source /etc/profile
# source ~/.bashrc

Using systemd-nspawn

systemd-nspawn may be used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot, but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.

Change directory to the mountpoint of the root partition and run systemd-nspawn:

# cd /mnt/arch
# systemd-nspawn

It is not necessary to mount api filesystems like /proc, manually, as systemd-nspawn starts a new init process in the contained environment which takes care of everything. It is like booting up a second Linux OS on the same machine, but it is not a virtual machine. To quit, just log out or issue the poweroff command. You can then unmount the partitions as described in #Exit from the chroot environment..

Run graphical applications from chroot

If you have an X-сервер, running on your system, you can start graphical applications from the chroot environment.

To allow the chroot environment to connect to an X server, open a virtual terminal inside the X server (i.e. inside the desktop of the user that is currently logged in), then run the xhost, command, which gives permission to anyone to connect to the user's X server:

$ xhost +local:

Then, to direct the applications to the X server from chroot, set the DISPLAY environment variable inside the chroot to match the DISPLAY variable of the user that owns the X server. So for example, run

 
$ echo $DISPLAY

as the user that owns the X server to see the value of DISPLAY. If the value is ":0" (for example), then in the chroot environment run

# export DISPLAY=:0

Exit from the chroot environment

When you are finished with system maintenance, exit from the chroot:

# exit

Last, unmount the temporary filesystems and the root partition:

 
# cd /
# umount --recursive /mnt/arch/

Without root privileges

Chroot requires root privileges, which may not be desirable or possible for the user to obtain in certain situations. There are, however, various ways to simulate chroot-like behavior using alternative implementations.

Proot

Proot may be used to change the apparent root directory and use mount --bind without root privileges. This is useful for confining applications to a single directory or running programs built for a different CPU architecture, but it has limitations due to the fact that all files are owned by the user on the host system. Proot provides a --root-id, argument that can be used as a workaround for some of these limitations in a similar (albeit more limited) manner to fakeroot.

Fakechroot

Fakechroot is a library shim which intercepts the chroot call and fakes the results. It can be used in conjunction with fakeroot to simulate a chroot as a regular user.

# fakechroot fakeroot chroot ~/my-chroot bash