Który z proc, sys itp. Powinien być zamontowany na wiązaniu (lub nie) podczas chrootowania do dystrybucji „zastępczej”?

Ta odpowiedź na inne pytanie sprowadza się zasadniczo do chrootwejścia w inną dystrybucję Linuksa, aby głównie wykorzystać ją jako zamiennik jej zbyt ograniczonego (ale niezastąpionego) rodzica. Sugerowane działania przed uruchomieniem chroot, które chciałbym lepiej zrozumieć, to:

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

• Kopiowanie resolv.confjest czyste (dostęp do sieci / Internetu), chociaż nie jestem pewien modules- to wydawało się niepotrzebne, gdy chrootwchodziłem do systemu stage3 Gentoo, prawda?
• Ale dlaczego proc, sysi dev/ptsponownie zamontować zamiast korzystania wiążą zamontowany? Jaka jest faktyczna różnica w tej sytuacji, która jest „bardziej poprawna”?
• Ten dokument bind-wierzchowce proci dev, ale ani dev/ptsani sysmontowane są w ogóle. Dodatkowo kopiuje /etc/{hosts,fstab}się do nowego katalogu głównego. Czy to ma sens? Czy też nie powinienem dołączyć /etc/mdadm.conf?

Plik /etc/resolv.conf jest kopiowany, aby nie utracić DNS-ów.

/ lib / modules jest kopiowany, ponieważ może być konieczne użycie jakiegoś komponentu sprzętowego, który nie musi być obecny podczas konfigurowania chroota. Musisz pamiętać, że oryginalne pytanie, na które powołujesz się w OP, dotyczy zastąpienia systemu operacyjnego NAS systemem Arch Linux. Będziesz zatem potrzebował sterowników do Ethernetu, ewentualnie sieci bezprzewodowej, różnych komponentów USB i tak dalej. Skopiowanie folderu / lib / modules zapewnia, że ​​nowe środowisko będzie w stanie poradzić sobie z przyszłymi zadaniami.

Rzeczywiście masz rację co do ponownego montażu vs. Strona Arch Arch Wiki na chroot używa ponownego montowania i montowania binda, jak określasz, zgodnie z odpowiedzią na post, do którego się odwołujesz:

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

(Myślę, że to pokazuje składnię twoich linii skopiowanych z tego postu , jest niepoprawna: dev przeznaczony do zamontowania poprzedza punkt montowania).

Jednak strona podręcznika użytkownika Ubuntu na chroot opowiada inną historię:

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

Tutaj / proc jest podłączony, a nie ponownie podłączony.

Próbowałem obu rzeczy i po krótkim okresie próbnym nie zauważyłem żadnej różnicy. Trzeba przyznać, że nie jest to żadna próba i dlatego opieram swoją sprawę na tym, aby nie miało to większego znaczenia.

• /etc/resolv.conf- potrzebujesz tego pliku do rozwiązywania żądań DNS. W niektórych okolicznościach nie jest to konieczne:

  1. klient DHCP jest dostępny w chroot, zostaje wykonany, a serwer DHCP zwraca odpowiednie informacje (co zwykle ma miejsce).

  2. nie jesteś zainteresowany pracą w sieci (a ściślej tworzeniem zapytań DNS ze zwykłych aplikacji, na których polegają /etc/resolv.conf) z wnętrza chroota.

• /lib/modules/$(uname -r)- ma sens na wypadek, gdyby konieczne było załadowanie dodatkowych modułów dla aktywnego jądra. Bez tego utknąłbyś z czymkolwiek, co aktualnie masz. Dlatego jeśli zamierzasz uruchomić system chrootowany przez dłuższy czas, prawdopodobnie powinieneś to zrobić. Z drugiej strony, w takim przypadku prawdopodobnie powinieneś użyć pivot_rootzamiast tego (co zwykle robi initrd pod koniec swojego życia). Jeśli po prostu musisz to zrobić, np. Aby zainstalować bootloader z chroota, nie powinno to być konieczne (ponieważ wszystkie potrzebne sterowniki muszą zostać załadowane, abyś mógł i tak zrobić chroota).

• /proci /devsą raczej oczywiste - zawierają one podstawowe interfejsy systemowe.

• /sysIIRC nie był tak szeroko stosowany w 2007 roku, z czego pochodzi Slackware (który sam w sobie jest raczej konserwatywny). W dzisiejszych czasach twój system prawdopodobnie jakoś zawiedzie bez niego (na przykład, gdy coś spróbuje wyliczyć jakiś typ sprzętu).

• /dev/pts- na przestrzeni lat wprowadzono kilka zmian w sposobie obsługi /devdrzewa. W pewnym momencie urządzenia /dev/ptsbyły obsługiwane przez devfs- patrz np. Ten wątek LKML w celu omówienia możliwych problemów.

• bind mount - istnieje kilka interesujących aspektów mountów bind (dość ładnie wyjaśnionych na mount(8)stronie podręcznika). Na przykład, jeśli masz:

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

  a następnie ponownie podłącz /x/atylko do odczytu, nie będziesz mógł niczego zmienić /x/B. Co jest zrozumiałe, ale może cię zaskoczyć po raz pierwszy. Kolejnym dobrym pytaniem jest to, co powinno się stać z /x/bpowyższym przykładem, kiedy ty umount /x/a. Dla mnie nie jest oczywiste, że nadal można uzyskać dostęp do drzewa pod nim. Dlatego montaż wiązań może być trudny. Funkcjonalnie, gdy jest używany na całym systemie plików, jest taki sam.

• inne rzeczy z /etc/- zdecydowanie warto skopiować odpowiednią konfigurację, która jest w użyciu. Kopiowanie np /etc/passwd, /etc/shadow, /etc/groups może mieć sens, a także klucze do serwera sshd.

/proczarządza procesami i syszmienia parametry jądra lub dostęp do informacji o bieżącym jądrze.

Teraz, biorąc pod uwagę, że wiązanie implikuje charakter dwukierunkowy, procnie może być montowane poza chroot jako najlepsze rozwiązanie.

sysmoże być, ale zależy od bieżącego działającego hosta jądra i musi być taki sam, jak devzamontowany jako bind.

/dev/ptssą już dostępne, ponieważ /devsą montowane na oprawach, ale są częścią chroota, więc ptszaleca się ponowne zamontowanie nowego mount -t devpts none /mnt/drive/dev/pts.