Talk:Chroot

From ArchWiki
Revision as of 06:25, 3 July 2019 by Nl6720 (talk | contribs) (→‎About section Using chroot: re)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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)