Lequel de proc, sys etc. devrait être monté en liaison (ou non) lors du chrootage dans une distribution de «remplacement»?

Cette réponse à une autre question se résume essentiellement à chrootune autre distribution Linux afin de l'utiliser principalement en remplacement de son parent trop restreint (mais irremplaçable). Les actions suggérées avant l'exécution chroot, que j'aimerais mieux comprendre, sont:

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 copie resolv.confest claire (accès réseau / Internet), même si je ne suis pas sûr de la modules- cela semblait en fait inutile lors de l' chrootintégration dans un système Gentoo stage3, non?
• Mais pourquoi proc, syset dev/ptsremonté au lieu d'utiliser bind-monté? Quelle est la différence réelle dans cette situation, qui est "plus correcte"?
• Ce HowTo lie-monte procet dev, mais ni dev/ptsni ne syssont montés du tout. De plus, il copie /etc/{hosts,fstab}vers la nouvelle racine. Cela a-t-il du sens? Ne devrais-je pas l'inclure /etc/mdadm.confégalement?

/etc/resolv.conf est copié afin de ne pas perdre les DNS.

/ lib / modules est copié car il peut être nécessaire d'utiliser certains composants matériels qui ne doivent pas nécessairement être présents au moment de la configuration du chroot. Vous devez vous rappeler que la question d'origine à laquelle vous faites référence dans votre PO concerne le remplacement d'un NAS OS par Arch Linux. Vous aurez donc besoin de pilotes pour Ethernet, éventuellement sans fil, divers composants USB, etc. La copie du dossier / lib / modules garantit que le nouvel environnement sera en mesure de faire face à ses tâches futures.

Vous avez en effet raison de remonter par rapport au montage par liaison. La page Wiki Arch Linux sur chroot utilise le re-montage et le montage de liaison comme vous le spécifiez, conformément à la réponse au message auquel vous vous référez:

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

(Je pense que cela montre que la syntaxe de vos lignes, copiée à partir de ce post , est erronée: le dev à monter précède le point de montage).

Cependant, la page de manuel Ubuntu sur chroot raconte une histoire différente:

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

Ici / proc est monté sur bind, pas remonté.

J'ai en fait essayé les deux choses, et après un bref essai, je n'ai pas pu constater de différence. Certes, ce n'est pas vraiment un test, et je me reposerai donc ici pour que cela ne fasse pas beaucoup de différence.

• /etc/resolv.conf- vous avez besoin de ce fichier pour résoudre les requêtes DNS. Ce n'est pas nécessaire dans certaines circonstances:

  1. un client DHCP est disponible dans le chroot, il est exécuté et le serveur DHCP renvoie les informations appropriées (ce qui est généralement le cas).

  2. vous n'êtes pas intéressé par la mise en réseau (ou plus précisément les requêtes DNS à partir d'applications habituelles qui dépendent /etc/resolv.conf) de l'intérieur du chroot.

• /lib/modules/$(uname -r)- est logique au cas où vous pourriez avoir besoin de charger des modules supplémentaires pour le noyau actif. Sans cela, vous seriez coincé avec tout ce que vous avez actuellement en cours d'exécution. Par conséquent, si vous avez l'intention d'exécuter le système chrooté plus longtemps, vous devriez probablement le faire. D'un autre côté, dans ce cas, vous devriez probablement utiliser à la pivot_rootplace (ce que fait habituellement initrd à la fin de sa vie). Si vous avez juste besoin de le faire, par exemple pour installer le chargeur de démarrage à partir du chroot, cela ne devrait pas être nécessaire (car tous les pilotes nécessaires doivent être chargés pour que vous puissiez de toute façon faire le chroot lui-même).

• /procet /devsont assez évidents - ceux-ci contiennent des interfaces système de base.

• /sysétait IIRC pas que largement utilisé en 2007 , qui est ce que la Slackware (qui lui - même est plutôt conservatrice) Comment à est daté. De nos jours, votre système est susceptible d'échouer d'une manière ou d'une autre sans lui (par exemple, une fois que quelque chose essaie d'énumérer un type de matériel).

• /dev/pts- au fil des ans, la façon dont l' /devarbre est manipulé a subi plusieurs changements . À un moment donné, les périphériques /dev/ptsont été gérés par devfs- voir par exemple ce fil LKML pour une discussion sur les problèmes possibles.

• montage de bind - il y a quelques aspects intéressants des montages de bind (plutôt bien expliqués dans la mount(8)page de manuel). Par exemple si vous avez:

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

  puis remontez en /x/alecture seule, vous ne pourrez rien y changer /x/B. Ce qui est compréhensible, mais pourrait vous surprendre pour la première fois. Une autre bonne question est de savoir ce qui devrait se passer /x/bdans l'exemple ci-dessus lorsque vous umount /x/a. Pour moi, il est loin d'être évident, que vous puissiez toujours accéder à l'arbre en dessous. Par conséquent, le montage de liaison peut être délicat. Fonctionnellement, lorsqu'il est utilisé sur un système de fichiers entier, c'est la même chose.

• autres choses de /etc/- il est certainement judicieux de copier la configuration pertinente qui est utile. Copie par exemple /etc/passwd, /etc/shadow, /etc/groups peut donner un sens, ainsi que les clés de serveur pour sshd.

/procgère les processus et sysmodifie les paramètres du noyau ou accède aux informations du noyau actuel.

Maintenant, en tenant compte du fait que la liaison implique une nature bidirectionnelle, procne doit pas être monté en dehors du chroot comme meilleure solution.

syspourrait l'être, mais il repose sur l'hôte du noyau en cours d'exécution, et doit être le même que dev, monté en tant que liaison.

/dev/ptssont déjà disponibles tels que /devmontés sur bind, mais font partie du chroot, il ptsest donc recommandé de remonter le nouveau comme mount -t devpts none /mnt/drive/dev/pts.