mount dev, proc, sys dans un environnement chroot?

87

J'essaie de créer une image Linux avec des packages choisis.
Ce que j'essaie de faire, c'est de concevoir à la main les packages que je vais utiliser sur un ordinateur portable XO, car la compilation de packages prend beaucoup de temps sur le vrai matériel XO, si je peux construire tous les packages dont j'ai besoin et simplement flasher le image au XO, je peux gagner du temps et de l’espace.

Lorsque j'ai essayé d'installer certains paquets, la configuration a échoué car les répertoires proc, sys et dev étaient manquants. J'ai donc appris ailleurs que je devais "monter" les répertoires proc, ... de l'hôte dans mon environnement chroot.

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

Dans la machine hôte:

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

et une autre syntaxe (en environnement chroot):

  mount -t proc none /proc

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

Patrick
la source
Attention: en accordant l'accès aux unités de disque, 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
2
@ 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 lui échapper de toute façon.
LtWorf

Réponses:

43

Pour /procet /sys, je suppose que vous pouvez utiliser l'une ou l'autre méthode. Ce sont tous deux des systèmes de fichiers spéciaux, ils peuvent donc être recréés autant de fois que nécessaire (la méthode de montage de liaison utilise exactement le même montage que le système hôte, alors que l’autre méthode utilise un nouveau montage). J'ai toujours vu la monture Bind recommandée dans les guides, je l'utilisais donc. Pour autant que je sache, il n'y a pas de réelle différence importante.

Cependant, il /devs’agit généralement d’un montage tmpfs géré par udev. Il doit donc s'agir du même système de fichiers que sur la machine hôte. Cela signifie que vous auriez besoin d'utiliser la méthode bind mount.

Si ce chroot doit être utilisé pendant un certain temps, vous pouvez insérer ces entrées /etc/fstabsur le système hôte pour simplifier les choses.

Zifre
la source
Je voudrais demander s'il est logique de copier (lier) le proc / sys de l'hôte à une autre machine? Pourquoi devraient-ils correspondre à cette machine?
Ransh
@ transh c'est logique si vous liez / proc à $ chrootdir / proc, vous aurez la possibilité de gérer les processus et tout ce qui se passe dans / proc des deux systèmes à partir des deux systèmes; Par exemple: à partir de chroot, vous pouvez vérifier si un programme est en cours d'exécution sur l'hôte ... etc.
Jonah
Peut-être que le sys typesystème de fichiers semble ( aujourd'hui ) ne plus exister?
174140
111

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 --rbind /sys sys/
mount --rbind /dev dev/
gacrux
la source
2
Ils semblaient aussi travailler pour moi à Ubuntu.
isaaclw
4
Dans mon cas (également Ubuntu), j'avais également besoin d'un "mount -o bind / dev / pts dev / pts".
Thomas
S'il vous plaît inclure le lien vers la source.
styrofoam fly
@styrofoamfly Ajouté.
gacrux
1
Depuis 2019, le wiki ArchLinux remplit maintenant les fonctions --rbindde syset dev.
Saad Malik
12

Le manuel Gentoo appelle spécifiquement ces deux commandes pour remonter / 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 que / sys est juste un dossier normal, vous devriez donc être capable de faire un lien dur.

ln /sys /mnt/chroot/sys
robert
la source
17
Vous ne pouvez pas créer de lien dur (généralement) comme vous le suggérez pour / sys, et si vous utilisez un lien symbolique, il se cassera dès que vous chrootez.
Ils en ont ajouté de nouveaux, basés sur systemd. C'est peut-être une bonne idée de les ajouter.
AzP
1

Il convient de noter, dans cette question populaire, que Arch Linux a créé un script arch-chroot ; Téléchargerarch-install-scripts-15-1-any.pkg.tar.xz

Ceci qui s’occupe de divers problèmes liés à la fois dans Arch-Linux et Manjaro , où je l’ai aussi utilisé avec succès. Peut - être plus archi- dérivés comme Parabole sont compatibles aussi bien.

Bien qu’un simple standard chrootdans une installation secondaire de Manjaro ne vous permette pas d’exécuter

pacman --sync linux

(la solution miracle après un crash système), en remplaçant la ligne par

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

vous permettra de réparer votre installation secondaire d’Arch-dérivate via

pacman --sync linux

comme un charme. Le script bash arch-chrootprend en charge /dev /sys /procet bien plus encore, qui sont laissés seuls par le standard chroot.

voir aussi: Utilisation d'arch-chroot

y mec
la source
-1

Il existe d'autres pseudo-systèmes de fichiers et emplacements tmpfs. C'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 d' accord pour monter le usbfs, rpc_pipefset devptspseudo-systèmes de fichiers de l' intérieur du chroot. Je recommande de ne pas lier /procles chroot /proc, car le noyau a le concept d'espaces de noms et peut réellement mettre différentes choses dans le proc du chroot.

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

C'est une mauvaise idée de monter le système /varou /runsur le chroot, si le chroot a son propre espace de noms pid.

Brian Minton
la source
Spéculation? Sur les super-utilisateurs (et autres forums de pile), il est généralement préférable d'attendre, ou de rechercher et de répondre avec des sources liées, si vous n'êtes pas sûr. Ceci permet d'éviter de répandre des indices erronés. Désolé si déçu et bonne chance!
Simon B.
@SimonB. J'ai ajouté un lien à une liste de diffusion supportant l'idée que / sys ne doit pas être lié par une liaison.
Brian Minton
Avec pid namespace, vous parlez de fonctionnalités d’espace de noms d’utilisateur plus avancées que vous pouvez trouver sur les noyaux Linux modernes (c’est-à-dire sur lesquelles sont basées les fonctionnalités des «conteneurs»), tandis que lorsque nous utilisons le terme chroot, nous faisons référence au changement d’espace de noms de fichier traditionnel ( et rien d'autre).
Johan Boulé
-1

Le moyen le plus simple consiste à utiliser une boucle for:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
oleberlin
la source