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

/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.

• /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.