Який із 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в системі Gentoo stage3, правда?
• Але чому proc, sysі dev/ptsперемонтована замість прив'язки монтажу? У чому полягає фактична різниця в цій ситуації, яка "правильніше"?
• Це HowTo Bind-монтує procі dev, але ні один, dev/ptsні sysвстановлені на всіх. Крім того, він копіює /etc/{hosts,fstab}в новий корінь. Чи має це сенс? Чи не повинен я /etc/mdadm.confтоді також включати ?

/etc/resolv.conf копіюється, щоб не втратити DNS.

/ lib / модулі копіюється, тому що, можливо, буде потрібно використовувати якийсь апаратний компонент, який не повинен бути присутнім під час налаштування chroot. Ви повинні пам’ятати, що оригінальне питання, на яке ви посилаєтесь у вашій ОП, стосується заміни ОС NAS на Arch Linux. Таким чином, вам знадобляться драйвери для Ethernet, можливо, бездротового зв'язку, різних USB-компонентів тощо. Копіювання папки / lib / module гарантує, що нове середовище зможе впоратися зі своїми майбутніми завданнями.

Ви справді маєте рацію щодо повторного монтажу проти встановлення прив'язки. Сторінка Wiki Arch Arch на 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, який потрібно встановити, передує точці монтажу).

Однак сторінка man 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)- має сенс у випадку, якщо вам може знадобитися завантажити будь-які додаткові модулі для активного ядра. Без цього ви б застрягли з тим, що ви зараз працюєте. Отже, якщо ви маєте намір запускати хроноване систему довше, ви, мабуть, це зробите. З іншого боку, у такому випадку вам, мабуть, слід скористатись цим pivot_root(що зазвичай робить initrd наприкінці свого життя). Якщо вам просто потрібно це зробити, наприклад, щоб встановити завантажувач з chroot, це не повинно бути необхідним (оскільки всі необхідні драйвери повинні бути завантажені для вас, щоб мати можливість робити сам chroot).

• /procі /devє досить очевидними - вони містять базові системні інтерфейси.

• /sysIIRC не був таким широко використовуваним ще в 2007 році, і саме це датується Slackware (яке саме по собі є досить консервативним). У наші дні ваша система, швидше за все, вийде з ладу без цього (наприклад, колись щось намагається перерахувати обладнання певного типу).

• /dev/pts- з роками відбулося кілька змін у тому, як /devповодиться з деревом. У якийсь момент пристроями /dev/ptsоброблялися пристрої devfs- див., Наприклад, цю нитку LKML для обговорення можливих проблем.

• встановлення прив’язки - є кілька цікавих аспектів кріплення прив'язки (досить непогано пояснено на mount(8)сторінці man). Наприклад, якщо у вас є:

  /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, встановлений як прив'язувати.

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