From ArchWiki

Multiple chroots

Is it possible to have multiple Chroots on the same target device? —This unsigned comment is by Cotton (talk) 17:06, 23 July 2010‎. Please sign your posts with ~~~~!

Update file system

Can chroot be used to update the entire root file system? After the chroot, running the mount command reports /dev/root on / type ext3 with /dev/root being a symbolic link to /dev/mmcblk0p2. Unmounting /dev/root and /dev/mmcblk0p2 both report invalid argument. Rereading the partition table using blockdev --rereadpt /dev/mmcblk0 reports device or resource busy. My guess it mmcblk0 is busy because /dev/mmcblk0p2 is still the root file system under the changed root file system I am using now. Before doing a chroot, I kills all the applications but the shell used to run chroot. Any suggestions on how I can successfully reread the partition table in this use model? --Tfischer

About using arch-chroot in other linux distributions

My interest with the added tip wasn't about packaging for other distributions (I didn't even mention the word 'package'). It was only to provide a quick explanation about how to use arch-chroot from another distribution for the sole purpose of chrooting into Arch itself. This was motivated by a personal issue, where I had to use arch-chroot from another linux distribution to access my arch partition, due to a filesystem/boot error. Also, notice that this tip wasn't really related to Install from Existing Linux -- no mentions about 'installations' either.

Thiagowfx (talk) 17:18, 19 December 2014 (UTC)

arch-chroot is just a bash script (i.e. it is not compiled as the tip said), so why not just extract the script from the Arch package and use it on the other system? I think that it is a standalone script (i.e. not sourcing other parts) so it should just work... -- Lahwaacz (talk) 18:06, 19 December 2014 (UTC)
Okay, the reason for compiling / running 'make' is that, in the tarball I indicated in the tip, the only thing that is present regarding arch-chroot is an '' file. 'make' is necessary for m4 to replace what needs to be replaced in this file, thus creating our final 'arch-chroot' bash script. Maybe using the term 'compile' wasn't a good idea, but the user should 'make' anyway (or, at least, manually get rid of the lines calling 'm4'). I won't insist on this, though, it is yours the final decision; I just wanted to say the reason for including the tip, I thought it could be useful for someone. Thiagowfx (talk) 19:13, 19 December 2014 (UTC)

About section Using chroot

mount -t proc /proc proc/ is misleading. when mounting procfs, it ignores the first argument (that is the resource, or in this case /proc). This command line is misleading as it lets the user think that they're mounting the host's `/proc`, and thus it's a requirement to mount, which is not. The line can be replaced with mount -t proc none proc/. Roosemberth 05:44, 03 July 2019 (UTC)

Agreed. Note that mount(8) suggests to use proc instead of none.
The same argumentation should apply to sysfs. sysfs(5) says to mount as mount -t sysfs sysfs /sys; therefore, I assume the device argument does not matter here either.
Respiranto (talk) 13:51, 26 February 2021 (UTC)

mount --rbind /sys sys/ is unnecessarly dangereous for most use cases. Usually the only submount of /sys is efivars, which is not needed most of the time. On the other hand accidentally modifying your efivars (cf. from the mindset “it's a chroot, everything is fine”) may cause permanent damage to your computer. The line can be replaced with mount --bind /sys sys. The original line with a proper warning should be added afterwards for users redirected here when installing arch (and thus really want write access to efivars). Roosemberth 05:44, 03 July 2019 (UTC)

That's ridiculous. Without efivarfs you can't update the boot entries in NVRAM. And the bricking is mitigated by -- nl6720 (talk) 06:25, 3 July 2019 (UTC)

Chroot section doesn't work

  1. mkdir /location/of/new/root
  2. cd /location/of/new/root
  3. mount -t proc /proc proc/
  4. mount --rbind /sys sys/
  5. mount --rbind /dev dev/

just won't work! Before that you need to mount root partition to that /location/of/new/root Why nobody complains about it? I tried to add missing step, but my edit silently were deleted. Webcapcha (talk) 21:43, 28 August 2020 (UTC)

See the 2nd point in chroot#Requirements. When you mkdir /location/of/new/root, you don't have a "Linux environment" yet. You can either mount it from somewhere else (which is apparently what you did) or create it using e.g. pacstrap or debootstrap on the same filesystem without mounting anything (which is why your edit was wrong). -- Lahwaacz (talk) 07:41, 29 August 2020 (UTC)
I see requirements, but why we give clear steps which directories and how should be mounted and in the same time vague advice about linux environment without example. Webcapcha (talk) 08:17, 29 August 2020 (UTC)