Talk:Chroot

From ArchWiki
Jump to navigation Jump to search

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 'arch-chroot.in' 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)

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 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171 -- nl6720 (talk) 06:25, 3 July 2019 (UTC)