Quale di proc, sys ecc. Dovrebbe essere montato (o meno) quando si esegue il chrooting in una distribuzione "sostitutiva"?

Questa risposta a un'altra domanda si riduce sostanzialmente ad chrootinglobare in un'altra distribuzione Linux per usarla principalmente in sostituzione del suo genitore troppo limitato (ma insostituibile). Le azioni suggerite prima di eseguire chroot, che vorrei capire meglio, sono:

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

• La copia resolv.confè chiara (accesso a rete / Internet), anche se non sono sicuro del modules- questo in realtà sembrava inutile quando si chrootentra in un sistema Gentoo stage3, giusto?
• Ma perché sono proc, syse dev/ptsrimontato invece di usare bind-montato? Qual è la differenza effettiva in questa situazione, che è "più corretta"?
• Questo HowTo si collega proce dev, ma né dev/ptsné sysè montato affatto. Inoltre, viene copiato /etc/{hosts,fstab}nella nuova radice. Ha senso? Non dovrei includere anche /etc/mdadm.confallora?

/etc/resolv.conf viene copiato per non perdere i DNS.

/ lib / modules viene copiato perché potrebbe essere necessario utilizzare alcuni componenti hardware che non devono essere presenti al momento della configurazione del chroot. È necessario ricordare che la domanda originale a cui si fa riferimento nel proprio OP riguarda la sostituzione di un sistema operativo NAS con Arch Linux. Avrai quindi bisogno di driver per Ethernet, possibilmente wireless, vari componenti USB e così via. La copia della cartella / lib / modules garantisce che il nuovo ambiente sarà in grado di far fronte alle sue attività future.

Hai davvero ragione riguardo al re-montaggio e al bind-mount. La pagina Wiki di Arch Linux su chroot utilizza il re-mount e il bind-mount come specificato, secondo la risposta al post a cui si fa riferimento:

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

(Penso che questo mostri che la sintassi delle tue linee, copiata da questo post , sia errata: lo sviluppatore da montare precede il punto di montaggio).

Tuttavia, la pagina man di Ubuntu su chroot racconta una storia diversa:

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

Qui / proc è montato su bind, non re-montato.

In realtà ho provato entrambe le cose e, dopo un breve test, non sono stato in grado di notare alcuna differenza. Non è un granché un test, devo ammettere, e quindi riporterò qui il mio caso che non dovrebbe fare molta differenza.

• /etc/resolv.conf- è necessario questo file per risolvere le richieste DNS. Non è necessario in alcune circostanze:

  1. un client DHCP è disponibile nel chroot, viene eseguito e il server DHCP restituisce le informazioni appropriate (che di solito è il caso).

  2. non sei interessato al networking (o più precisamente alla creazione di query DNS dalle normali applicazioni su cui si basano /etc/resolv.conf) dall'interno del chroot.

• /lib/modules/$(uname -r)- ha senso nel caso in cui sia necessario caricare eventuali moduli aggiuntivi per il kernel attivo. Senza questo saresti bloccato con qualsiasi cosa tu abbia attualmente in esecuzione. Pertanto, se si intende eseguire il sistema chroot per un periodo di tempo più lungo, probabilmente è necessario farlo. D'altra parte, in tal caso probabilmente dovresti usare pivot_rootinvece (che è ciò che fa di solito initrd alla fine della sua vita). Se hai solo bisogno di farlo, ad esempio per installare il bootloader dal chroot, non dovrebbe essere necessario (poiché tutti i driver necessari devono essere caricati per poter comunque fare il chroot stesso).

• /proce /devsono piuttosto ovvi: contengono interfacce di sistema di base.

• /sysIIRC non era così ampiamente usato nel 2007, ed è così datato lo Slackware (che è piuttosto conservativo). In questi giorni è probabile che il tuo sistema fallisca in qualche modo senza di esso (ad esempio una volta che qualcosa tenta di enumerare un tipo di hardware).

• /dev/pts- nel corso degli anni ci sono stati diversi cambiamenti nel modo in cui l' /devalbero viene gestito. Ad un certo punto i dispositivi /dev/ptssono stati gestiti da devfs- vedi ad esempio questo thread LKML per la discussione di possibili problemi.

• bind mount - ci sono alcuni aspetti interessanti dei bind mount (spiegati piuttosto bene nella mount(8)pagina man). Ad esempio se hai:

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

  e quindi rimonta /x/adi sola lettura, non sarai in grado di cambiare nulla /x/B. Il che è comprensibile, ma potrebbe sorprenderti per la prima volta. Un'altra buona domanda è cosa dovrebbe succedere /x/bnell'esempio sopra quando tu umount /x/a. Per me è tutt'altro che ovvio che puoi ancora accedere all'albero sottostante. Quindi il montaggio del binding può essere complicato. Funzionalmente, se utilizzato sull'intero filesystem, è lo stesso.

• altre cose da /etc/- ha sicuramente senso copiare la configurazione pertinente che è utile. Copiare ad esempio /etc/passwd, /etc/shadow, /etc/groups può avere un senso, così come le chiavi di server per sshd.

/procgestisce i processi e sysmodifica i parametri del kernel o accede alle informazioni del kernel corrente.

Ora, considerando che il legame implica una natura bidirezionale, procnon deve essere montato al di fuori del chroot come soluzione migliore.

syspotrebbe essere, ma si basa sull'host del kernel in esecuzione corrente e deve essere lo stesso di dev, montato come bind.

/dev/ptssono già disponibili come /devè montato su bind, ma fanno parte del chroot, quindi ptssi consiglia di rimontare il nuovo come mount -t devpts none /mnt/drive/dev/pts.