2010-07-18 19:06:10 +0000 2010-07-18 19:06:10 +0000
92
92

mount dev, proc, sys in een chroot-omgeving?

Ik probeer een Linux-image te maken met op maat gemaakte pakketten.
Wat ik probeer te doen is de pakketten die ik ga gebruiken op een XO laptop met de hand te maken, omdat het compileren van pakketten erg lang duurt op de echte XO hardware, als ik alle pakketten kan bouwen die ik nodig heb en gewoon de afbeelding naar de XO kan flitsen, kan ik tijd en ruimte besparen.

Toen ik probeerde om sommige pakketten te installeren, is het niet gelukt om te configureren vanwege het ontbreken van de proc, sys, dev-directories. Dus, ik leerde van andere plaatsen dat ik de host proc, … directories moet “mounten” aan mijn chroot omgeving.

Ik zag twee syntax en weet niet zeker welke te gebruiken.

In host machine: mount --bind /proc <chroot dir>/proc

en een andere syntax (in chroot omgeving):

mount -t proc none /proc

Welke moet ik gebruiken, en wat is het verschil?

Antwoorden (6)

118
118
118
2012-04-26 06:10:11 +0000

De Arch Linux Wiki stelt de volgende commando’s voor:

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/
45
45
45
2010-07-19 01:02:06 +0000

Voor /proc en /sys, veronderstel ik dat je beide methodes kan gebruiken. Het zijn beide speciale bestandssystemen, zodat ze een willekeurig aantal keren kunnen worden gereproduceerd (de bind-mount methode gebruikt exact dezelfde mount als het hostsysteem, terwijl de andere methode een nieuwe mount gebruikt). Ik heb de bind-mount altijd aanbevolen in gidsen gezien, dus ik zou die gebruiken. Voor zover ik weet, is er geen echt belangrijk verschil.

Echter, /dev is meestal een tmpfs-mount die beheerd wordt door udev, dus het moet hetzelfde bestandssysteem zijn als op de hostmachine. Dat betekent dat u de bind-mount methode zou moeten gebruiken.

Als deze chroot een tijdje blijft bestaan, kunt u deze entries in /etc/fstab op het hostsysteem zetten om de dingen te vereenvoudigen.

13
13
13
2010-07-19 00:05:08 +0000

Het Gentoo Handbook roept deze twee commando’s specifiek op voor het opnieuw monteren van /proc en /dev. Ik heb ze verschillende keren gebruikt.

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

Ik vermoed dat /sys slechts een gewone map is, dus je zou een harde koppeling moeten kunnen maken.

ln /sys /mnt/chroot/sys
1
1
1
2016-04-17 15:36:51 +0000

Het is misschien de moeite waard om in deze populaire vraag op te merken, dat Arch Linux een script heeft gemaakt arch-chroot ; download arch-install-scripts-15-1-any.pkg.tar.xz

Dit zorgt voor verschillende gerelateerde problemen zowel in Arch-Linux als Manjaro , waar ik het ook met succes heb gebruikt. Mogelijk zijn meer Arch- derivaten zoals Parabola net zo goed compatibel.

Terwijl een eenvoudige standaard chroot in een secundaire Manjaro installatie niet toelaat om

pacman --sync linux

te draaien (de zilveren kogel na een systeemcrash), zal het vervangen van de lijn door

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

u toelaten om uw secundaire Arch-derivate installatie via

pacman --sync linux

te repareren als een charme. Het bash script arch-chroot zorgt voor /dev /sys /proc en nog veel meer, die door de standaard chroot met rust worden gelaten.

zie ook: Met behulp van boogwortel

-1
-1
-1
2019-01-20 13:32:32 +0000

De eenvoudigste manier is om een voor lus te gebruiken:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
-1
-1
-1
2012-10-15 21:06:00 +0000

Er zijn andere pseudo-bestandssystemen en tmpf-locaties. Dit is op debian:

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

Het zou oké moeten zijn om de usbfs, rpc_pipefs en devpts pseudo-filesystems vanuit de chroot te mounten. Ik raad niet aan om /proc te binden aan de chroot’s /proc, aangezien de kernel het concept van namespaces heeft, en eigenlijk verschillende dingen in de proc van de chroot kan zetten.

Update: volgens deze mailinglijst thread , /sys moeten niet gebonden worden gemount, vooral als de ge-chroote processen zijn eigen netwerknaamruimte gebruiken.

Het is een slecht idee om het systeem /var of /run op de chroot te mounten, als de chroot zijn eigen pid-naamruimte heeft.