Какой из proc, sys и т. Д. Должен быть подключен (или нет) при привязке к «замещающему» дистрибутиву?

Этот ответ на другой вопрос в основном сводится к chrootпереходу в другой дистрибутив Linux, чтобы в основном использовать его в качестве замены слишком ограниченному (но незаменимому) родителю. Предлагаемые действия перед запуском chroot, которые я хотел бы понять лучше:

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

• Копирование resolv.confчеткое (доступ к сети / Интернету), хотя я не уверен насчет этого modules- это на самом деле казалось ненужным при chrootвходе в систему stage3 Gentoo, верно?
• Но почему proc, sysи dev/ptsперемонтирована вместо привязки монтажа? Какова реальная разница в этой ситуации, которая является «более правильной»?
• Это HowTo Bind-монтирует procи dev, но ни один, dev/ptsни sysустановлены на всех. Дополнительно он копирует /etc/{hosts,fstab}в новый корень. Имеет ли это смысл? Разве я не должен включить /etc/mdadm.confтогда?

/etc/resolv.conf копируется, чтобы не потерять DNS.

/ lib / modules копируется потому, что может потребоваться использование некоторого аппаратного компонента, который не должен присутствовать во время настройки chroot. Вы должны помнить, что исходный вопрос, на который вы ссылаетесь в своем OP, касается замены ОС NAS на Arch Linux. Таким образом, вам понадобятся драйверы для Ethernet, возможно, для беспроводной связи, различных USB-компонентов и так далее. Копирование папки / lib / modules гарантирует, что новая среда сможет справиться со своими будущими задачами.

Вы действительно правы насчет повторной установки или крепления. Страница Arch Linux Wiki на Chroot делает использование повторного монтажа и привязки монтажа , как вы определяете, как и в ответ на сообщение , которое Вы ссылаетесь:

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

(Я думаю, что это показывает, что синтаксис ваших строк, скопированных из этого поста , неверен: dev для монтирования предшествует точке монтирования).

Тем не менее, справочная страница Ubuntu по chroot рассказывает другую историю:

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

Здесь / proc монтируется с привязкой, а не перемонтируется.

Я на самом деле пробовал обе вещи, и после короткого пробного запуска я не смог заметить никакой разницы. По общему признанию, это не большая проверка, и поэтому я остановлюсь здесь на том, что это не должно иметь большого значения.

• /etc/resolv.conf- вам нужен этот файл для разрешения DNS-запросов. Это не обязательно при некоторых обстоятельствах:

  1. DHCP-клиент доступен в chroot, он выполняется, и DHCP-сервер возвращает соответствующую информацию (как правило, так).

  2. Вы не заинтересованы в создании сетей (или, точнее, создании DNS-запросов из обычных приложений, на которые они опираются /etc/resolv.conf) изнутри chroot.

• /lib/modules/$(uname -r)- имеет смысл, если вам может понадобиться загрузить дополнительные модули для активного ядра. Без этого вы бы застряли с тем, что у вас сейчас работает. Следовательно, если вы собираетесь запускать chrooted-систему дольше, вам, вероятно, следует это сделать. С другой стороны, в таком случае вы, вероятно, должны использовать pivot_rootвместо этого (что обычно делает initrd в конце своей жизни). Если вам просто нужно сделать это, например, чтобы установить загрузчик из chroot, в этом нет необходимости (поскольку все необходимые драйверы должны быть загружены, чтобы вы в любом случае могли выполнять сам chroot).

• /procи /devдовольно очевидны - они содержат базовые системные интерфейсы.

• /sysбыл IIRC не что широко используется еще в 2007 году , которая является то , что Slackware (который сам по себе является довольно консервативным) Как к датирована. В наши дни ваша система может как-то выйти из строя без этого (например, когда что-то пытается перечислить какое-то оборудование типа).

• /dev/pts- За прошедшие годы произошло несколько изменений в том, как /devобрабатывается дерево. В какой-то момент устройства /dev/ptsбыли обработаны devfs- см., Например, этот поток LKML для обсуждения возможных проблем.

• bind mount - есть несколько интересных аспектов bind mount (довольно хорошо объяснено на mount(8)странице руководства ). Например, если у вас есть:

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

  а затем перемонтировать /x/aтолько для чтения, вы не сможете ничего изменить в /x/B. Это понятно, но может застать вас врасплох в первый раз. Еще один хороший вопрос, что должно произойти /x/bв приведенном выше примере, когда вы umount /x/a. Для меня далеко не очевидно, что вы все еще можете получить доступ к дереву под ним. Следовательно, установка привязки может быть сложной. Функционально, когда используется на всей файловой системе, это то же самое.

• другие вещи из /etc/- это определенно имеет смысл скопировать соответствующую конфигурацию, которая полезна. Копирование , например /etc/passwd, /etc/shadow, /etc/groups может иметь смысл, а также ключи сервера для sshd.

/procуправляет процессами и sysизменяет параметры ядра или информацию о доступе к текущему ядру.

Теперь, принимая во внимание, что связывание подразумевает двунаправленную природу, procего не следует устанавливать вне chroot в качестве лучшего решения.

sysможет быть, но он зависит от текущего запущенного хоста ядра и должен быть таким же, как dev, смонтированный как bind.

/dev/ptsуже доступны как /devсмонтированные на привязке, но являются частью chroot, поэтому ptsрекомендуется перемонтировать новый mount -t devpts none /mnt/drive/dev/pts.