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.<p>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.<p>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.
The arch linux install has a little wrapper around chroot, used to configure the installed system without booting it.<p><a href="https://wiki.archlinux.org/title/Installation_guide#Chroot" rel="nofollow">https://wiki.archlinux.org/title/Installation_guide#Chroot</a>
> sudo mkdir /rescue/boot<p>> sudo mount /dev/nvme0n1p3 /rescue/boot<p>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.
I just installed Gentoo from WSL2 this way, on my secondary NVME on my Framework 16. Went without a hitch besides some minor things you need to be aware of:<p>-the lack of access to efi subsystem from wsl means you need to pass some extra flags to help grub/etc along, and you may need to set it as the boot partition in the bios manually<p>-you'll have to mount the drive to wsl with `wsl --mount <DiskPath> --bare`, after finding the right DiskPath with `Get-CimInstance -query "SELECT * from Win32_DiskDrive"`, and you might have to offline the disk first in Windows disk manager
Currently working on scripts to provision a drive outside of the machine it’s meant to go on using chroot. I’ve so far accidentally unmounted /dev/pts several times from the host system and running docker inside the chroot caused a hard lock. Fun stuff.
chroot was (is?) the recommended way of installing gentoo which is pedagogical.<p>There are various handy (chroot) techniques that are probably considered "old school" now. For example, having a "rescue partition" which can be booted into remotely, and from there reinstall or repair the "main os". This is necessary when repartitioning remotely, for example.
Used this or at least a very similar technique a few times to fix boot issues.<p>I've got a version of the mounting command that I think is easier to use:<p><pre><code> for f in proc sys dev run dev/pts ; do mount --bind /$f /mnt/$f ; done
</code></pre>
Change the "/mnt/$f" to whatever mountpoint that you're using which would be "/rescue/$f" to align with TFA.<p>I don't know what difference it makes to have /run mounted, but once you chroot into the mountpoint you can mount the boot partition etc and run whatever grub or mkinitramfs command you need to fix stuff.<p>I would leave the /boot mounting to later in the process - after you chroot. This way you can easily check /etc/fstab for where the boot partition lives (or if there is one), so you only need to locate the root partition initially which is generally easy to figure out from the disk sizes.<p>There's extra steps needed however if the system uses LVM.
It's kind of funny to see this being called a technique. It has been something I've done so many times to impressive results. To me, it's just something you can do, among a million other things, if you know enough about Linux.
The tools shouldn't require the use of chroot. It is quite common on Solaris to be able to specify a path that should be considered the root directory for the tool, usually -R. This was super useful in a netboot world using nfs, and also for crash recovery.<p>If a system is screwed up enough, then a chroot strategy won't work because it relies on the path you are chrooting to to be generally valid and functional. If it's missing libraries you may well be screwed.
I can highly recommend: <a href="https://github.com/fsquillace/junest">https://github.com/fsquillace/junest</a>
Ah - my attempt at doing this was almost there, except for the few bits that kept erroring out because I didn't mount the proc,dev,etc. mountpoints correctly :) Something to give another whirl on. At the time, I wanted something simple without docker to store everything development-related using different libraries. This is where debootstrap+chroot comes in - to build against various versions of libraries in Debian (if I remember correctly - it's been awhile.)
What if I'm ssh'd into a Linux box and want to (say) format its root disk. Can I boot a new instance of Linux in memory and then access the root disk?
Once I had to rescue a SunOS system and edit /etc/vfstab but I only had ed to my disposal. At that point I had never touched ed before, so that was a bit of a learning exercise, for sure.
Sure, chroot can be useful in a pinch, but it would not be the first thing I'd reach to. If you got the partitions mounted, you can already do quite a lot of things without needing to chroot.
This is how Linux From Scratch is done, and I've used the same technique to install missing video drivers that the Ubuntu install didn't include for whatever reason.