What is the difference between "mount -t ..." and "mount -o bind ..." with regard to chroot environment

Question

So I am setting up a chroot where I need proc, sys and dev folders.

I have read that I need to mount them as follows:

mount -t proc /proc /mnt/chroot/proc
mount -t sysfs /sys /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev

Answers obtained from here: mount-dev-proc-sys-in-a-chroot-environment

But I did not find where the difference is explained. I can't see how they can be much different...

Answer 1

/dev is a tmpfs variant (devtmpfs). The kernel populates it with device nodes, but the contents are flexible, and udev userspace daemon adjusts their permissions, creates symlinks (e.g. /dev/disk/by-*), etc.

You want to bind the existing instance in order to carry over the changes made by udev. Trying to mount a new instance would give a fresh tmpfs with just kernel-provided nodes, but without udev links. Scratch that, apparently the current kernels do treat devtmpfs as single-instance, as opposed to ordinary tmpfs. That is, mounting it twice will still give you the same contents both times.

However, I think the same reasoning still applies: people recommend binding /dev because they make the same assumption that I've been making (whether correctly or not) that it works the same way as a traditional tmpfs.

Moreover, until fairly recently, /dev was in fact a traditional tmpfs with everything in it created by userspace (udev or similar). When working with systems before the addition of devtmpfs, binding /dev was still a necessity.

/proc and /sys are fully virtual filesystems (procfs and sysfs). The kernel controls all operations and defines a rigid structure.

Multiple procfs or sysfs mounts within the same namespaces are completely identical – all of them refer to the same instance of the filesystem. Therefore there is no difference between mounting a new instance for an ordinary chroot and binding an existing one.

(Differences begin to appear when you work with containers, e.g. process namespaces or network namespaces. Mounting a new procfs instance within a container would give a limited view of its own processes only; binding the host's procfs would allow the container to see all processes.)