Question mount dev, proc, sys dans un environnement chroot?


J'essaie de créer une image Linux avec des paquetages personnalisés.
Ce que j'essaie de faire, c'est de fabriquer les paquets que je vais utiliser sur un ordinateur portable XO, car la compilation des paquets prend beaucoup de temps sur le vrai matériel XO, si je peux compiler tous les paquets dont j'ai besoin et image au XO, je peux gagner du temps et de l’espace.

Lorsque j'ai essayé d'installer certains paquets, la configuration a échoué en raison de l'absence des répertoires proc, sys et dev. Donc, j'ai appris par d'autres endroits que je devais "monter" les répertoires host proc, ... dans mon environnement chroot.

J'ai vu deux syntaxes et je ne sais pas lequel utiliser.

En machine hôte:

  mount --bind /proc <chroot dir>/proc 

et une autre syntaxe (dans l'environnement chroot):

  mount -t proc none /proc

Lequel dois-je utiliser, et quelle est la différence?


71
2017-07-18 19:06


origine


Attention: accorder l'accès aux unités de disque signifie que vous perdez certains des avantages de 'chroot()'. En particulier, le déterminé peut lire des fichiers en dehors de leur section du système de fichiers si vous ne faites pas attention. - Jonathan Leffler
@ Jonathan Leffler: Cela ne semble pas être un problème pour ce qu'il fait. - Zifre
@JonathanLeffler un utilisateur root dans un chroot peut toujours échapper au chroot. - LtWorf


Réponses:


Pour /proc et /sys, Je suppose que vous pourriez utiliser l'une ou l'autre méthode. Ils sont tous deux des systèmes de fichiers spéciaux, ils peuvent donc être recréés un nombre illimité de fois (la méthode bind mount utilise exactement le même montage que le système hôte, tandis que l'autre méthode utilise un nouveau montage). J'ai toujours vu le montage de liaison recommandé dans les guides, donc je l'utiliserais. Pour autant que je sache, il n’ya pas de différence importante.

cependant, /dev est généralement un montage tmpfs géré par udev, il doit donc être le même système de fichiers que sur la machine hôte. Cela signifie que vous devez utiliser la méthode bind mount.

Si ce chroot est là pendant un certain temps, vous pouvez mettre ces entrées dans /etc/fstab sur le système hôte pour simplifier les choses.


41
2017-07-19 01:02



Je voudrais demander s'il est logique de copier (lier) le proc / sys de l'hôte vers une autre machine? Pourquoi devraient-ils correspondre à cette machine? - ransh
@ransh ça fait sens si vous liez / proc à $ chrootdir / proc, vous aurez la possibilité de gérer le processus et ce qui se passe à l'intérieur de / proc des deux systèmes à partir des deux systèmes; Par exemple: depuis chroot, vous pouvez vérifier si un programme est en cours d'exécution sur l'hôte ... etc - Jonas
Peut-être le sys  type du système de fichiers apparaît (aujourd'hui) ne plus exister? - uprego


Le wiki Arch Linux suggère les commandes suivantes:

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/

Je peux confirmer qu'ils ont travaillé pour moi.


88
2018-04-26 06:10



Ils ont également semblé travailler pour moi à Ubuntu. - isaaclw
Dans mon cas (aussi Ubuntu), j'avais besoin d'un "mount -o bind / dev / pts dev / pts". - Thomas


le Manuel Gentoo appelle spécifiquement ces deux commandes pour le re-montage / proc et / dev. Je les ai utilisés plusieurs fois.

mount -t proc none /mnt/chroot/proc
mount -o bind /dev /mnt/chroot/dev

Je soupçonne / sys est juste un dossier normal, vous devriez donc être capable de créer un lien dur.

ln /sys /mnt/chroot/sys

8
2017-07-19 00:05



Vous ne pouvez pas relier un répertoire (généralement) comme vous le suggérez à / sys, et si vous utilisez un lien symbolique, il se brisera dès que vous chrootez.


Il peut être intéressant de noter dans cette question populaire, Arch Linux a fait un script arch-chroot; Télécharger arch-install-scripts-15-1-any.pkg.tar.xz

Ce qui prend en charge divers problèmes liés à la fois dans Arch-Linux et Manjaro , où je l'ai utilisé avec succès aussi. Peut-être plusdérivés comme Parabole sont tout aussi compatibles.

Bien qu'un standard simple chroot dans une installation secondaire de Manjaro ne vous permettra pas de courir

pacman --sync linux

(la balle d’argent après un crash du système), en remplaçant la ligne par

arch-chroot /run/media/*YOURSELF*/manja-disk2

vous permettra de réparer votre installation secondaire dérivée d'Arc via

pacman --sync linux

comme un charme. Le script bash arch-chroot prend soin de /dev /sys /proc et beaucoup plus, qui sont laissés seuls par la norme chroot.

voir également: Utiliser arch-chroot


0
2018-04-17 15:36





Il existe d'autres pseudo systèmes de fichiers et emplacements tmpfs. Ceci est sur debian:

/dev/pts 
/run
/run/shm
/proc/sys/fs/binfmt_mist
/var/lib/nfs/rpc_pipefs
/proc/fs/nfsd
/proc/bus/usb

Il devrait être bon de monter le usbfs, rpc_pipefs et devpts pseudo-systèmes de fichiers à partir du chroot. Je recommande ne pas contraignant /proc aux chroots /proc, puisque le noyau a le concept d'espaces de noms, et peut en fait placer différentes choses dans le processus de chroot.

Mise à jour: selon ce fil de liste de diffusion, / sys ne doit pas être lié, en particulier si les processus chrootés utilisent leur propre espace de noms réseau.

C'est une mauvaise idée de monter le système /var ou /run sur le chroot, si le chroot a son propre espace de nom de pid.


-1
2017-10-15 21:06



Spéculation? Sur les super-utilisateurs (et autres forums de discussion), il est généralement préférable de suspendre ou de rechercher et de répondre avec des sources liées si vous n'êtes pas sûr. Ceci afin d'éviter de risquer de répandre des indices malavisés. Désolé si déçu et bonne chance! - Simon B.
@SimonB. J'ai ajouté un lien vers une liste de diffusion soutenant l'idée que / sys ne devrait pas être lié. - Brian Minton
Avec l'espace de nom pid, vous parlez de fonctionnalités d'espace de noms utilisateur plus avancées que nous pouvons trouver sur les noyaux linux modernes (c.-à-d. Les fonctionnalités "conteneurs" sont basées), et rien d'autre). - Johan Boulé