Поэтому я настраиваю chroot, где мне нужны папки proc, sys и dev.
Я прочитал, что мне нужно смонтировать их следующим образом:
mount -t proc /proc /mnt/chroot/proc
mount -t sysfs /sys /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev
Ответы, полученные здесь: mount-dev-proc-sys-in-a-chroot-environment
Но я не нашел, где объясняется разница. Я не вижу, как они могут сильно отличаться ...
/dev - это вариант tmpfs (devtmpfs). Ядро заполняет его узлами устройства, но содержимое является гибким, и демон пользовательского пространства udev настраивает их разрешения, создает символические ссылки (например, /dev /disk /by- *) и т.д.
Вы хотите связать существующий экземпляр, чтобы перенести изменения, сделанные udev. Попытка смонтировать новый экземпляр выдаст свежие tmpfs только с предоставленными ядром узлами, но без ссылок udev. Царапины , что, по- видимому , нынешние ядра не лечить devtmpfs в одной инстанции, в отличие от обычных TMPFS. То есть, монтируя его дважды, вы оба раза получите одно и то же содержимое.
Тем не менее, я думаю, что те же рассуждения все еще применимы: люди рекомендуют связывать /dev, потому что они делают то же самое предположение, что я делал (правильно или нет), что он работает так же, как традиционные tmpfs.
Более того, до недавнего времени /dev был на самом деле традиционным tmpfs со всем, что в нем было создано пользовательским пространством (udev или аналогичным). При работе с системами до добавления devtmpfs привязка /dev все еще была необходима.
/proc и /sys являются полностью виртуальными файловыми системами (procfs и sysfs). Ядро контролирует все операции и определяет жесткую структуру.
Несколько монтирований procfs или sysfs в одних и тех же пространствах имен полностью идентичны - все они ссылаются на один и тот же экземпляр файловой системы. Поэтому нет никакой разницы между монтированием нового экземпляра для обычного chroot и связыванием существующего.
(Различия начинают проявляться, когда вы работаете с контейнерами, например, с пространствами имен процессов или сетевыми пространствами имен. Монтирование нового экземпляра procfs в контейнере даст ограниченное представление только о его собственных процессах; привязка procfs хоста позволит контейнеру видеть все процессы.)