Which of proc, sys etc. should be bind-mounted (or not) when chrooting into a "replacement" distribution?

Question

This answer to another question basically boils down to chrooting into another Linux distribution in order to mainly use that as a replacement to its too restricted (but irreplaceable) parent. The suggested actions before running chroot, which I would like to understand better, are:

cp /etc/resolv.conf etc/resolv.conf
cp -a /lib/modules/$(uname -r) lib/modules
mount -t proc archproc proc
mount -t sysfs archsys sys
mount -o bind /dev dev
mount -t devpts archdevpts dev/pts

• Copying resolv.conf is clear (network/internet access), while I'm not sure about the modules - this actually seemed unnecessary when chrooting into a stage3 Gentoo system, right?
• But why are proc, sys and dev/pts remounted instead of using bind-mounted? What is the actual difference in this situation, which is "more correct"?
• This HowTo bind-mounts proc and dev, but neither dev/pts nor sys are mounted at all. Additionally it copies /etc/{hosts,fstab} over to the new root. Does that make sense? Shouldn't I include /etc/mdadm.conf then as well?

Answer 1

/etc/resolv.conf is copied in order not to lose the DNSs.

/lib/modules is copied because because it may be necessary to use some hardware component that need not be present at the time of setting up the chroot. You must remember that the original question you refer to in your OP concerns the replacement of a NAS OS with Arch Linux. You will thus need drivers for ethernet, possibly wireless, various USB components, and so on. Copying the /lib/modules folder ensures that the new environment will be able to cope with its future tasks.

You are indeed right about re-mounting vs. bind-mounting. The Arch Linux Wiki page on chroot does use re-mounting and bind-mounting as you specify, as per the answer to the post you refer to:

cd /mnt/arch
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
mount -t devpts pts dev/pts/

(I think this shows the syntax of your lines, copied from this post, is wrong: the dev to be mounted precedes the mount point).

However, the Ubuntu man page on chroot tells a different story:

sudo mount -o bind /proc /var/chroot/proc

Here /proc is bind-mounted, not re-mounted.

I have actually tried both things, and after a brief test run, I have been unable to notie any difference. Not much of a test, admittedly, and I will thus rest my case here that it should not make much of a difference.

Answer 2

• /etc/resolv.conf - you need this file for resolving DNS requests. It isn't necessary under some circumstances:

  1. a DHCP client is available in the chroot, it does get executed and the DHCP server returns the appropriate information (which usually is the case).

  2. you are not interested in networking (or more precisely making DNS queries from usual applications that rely on /etc/resolv.conf) from inside of the chroot.

• /lib/modules/$(uname -r) - makes sense in case you might need to load any additional modules for the active kernel. Without this you'd be stuck with whatever you currently have running. Hence if you intend to run the chrooted system for longer time, you should probably do it. On the other hand, in such case you probably should use pivot_root instead (which is what usually initrd does at the end of its life). If you just need to do it e.g. to install the bootloader from the chroot, it shouldn't be necessary (since all needed drivers must be loaded for you to be able to do the chroot itself anyway).

• /proc and /dev are rather obvious - these contain basic system interfaces.

• /sys was IIRC not that widely used back in 2007 which is what the Slackware (which itself is rather conservative) How-to is dated. These days your system is likely to fail somehow without it (for example once something tries to enumerate some type hardware).

• /dev/pts - over the years there were several changes to how /dev tree is handled. At some point the devices in /dev/pts were handled by devfs - see e.g. this LKML thread for discussion of possible problems.

• bind mounting - there are some interesting aspects of bind mounts (rather nicely explained in mount(8) man page). For example if you have:

  /some/device on /x/a (rw)
  /x/a/A on /x/b (rw)
  

  and then remount /x/a read-only, you won't be able to change anything in /x/B. Which is understandable, but might catch you by surprise for the first time. Another good question is what should happen with /x/b in the above example when you umount /x/a. For me it is far from obvious, that you can still access the tree underneath it. Hence bind mounting can be tricky. Functionally, when used on whole filesystem, it is the same.

• other things from /etc/ - it definitely makes sense to copy relevant configuration that is of use. Copying e.g. /etc/passwd, /etc/shadow, /etc/groups may make sense, as well as server keys for sshd.

Answer 3

/proc manages processes and sys changes kernel parameters or access info of current kernel.

Now, taking in consideration that bind implies a bidirectional nature, proc must not be mounted outside of the chroot as best solution.

sys could be, but it relies on the current running kernel host, and must be the same as dev, mounted as bind.

/dev/pts are already available as /dev is bind-mounted, but are a part of the chroot, so remounting the new pts are recommended as mount -t devpts none /mnt/drive/dev/pts.