With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong.

Though these days you may want to look into things like systemd-nspawn instead of plain chroot.

This brings back memories - I owned a large web hosting company and we had thousands of machines. When hardware issues came up, or machines wouldn't boot, using this method was our first line of defense - we'd boot the machine from a burned copy of "Recovery Is Possible" which was an all-in-one Linux distro for recovery, then mount the partitions and chroot in to figure out what is going on - or use rsync to migrate data off as needed.

Just looked and it looks like "Recovery Is Possible" hasn't been updated in a dozen years which dates my story, but I fondly remember overnight phone calls from panicked new sysadmins and telling them to be calm and "RIP it and get chrooted in" and then waking up to help them troubleshoot.

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

The arch linux install has a little wrapper around chroot, used to configure the installed system without booting it.

https://wiki.archlinux.org/title/Installation_guide#Chroot

> sudo mkdir /rescue/boot

> sudo mount /dev/nvme0n1p3 /rescue/boot

This is a little extra. What you can generally do is immediatelly after chroot just run 'mount -a' to mount everything from the chroot's fstab. The empty `/boot` probably already exists.