Mount Dev, Proc, Sys in einer Chroot-Umgebung?

Ich versuche, ein Linux-Image mit benutzerdefinierten Paketen zu erstellen.
_{Ich versuche, die Pakete, die ich auf einem XO-Laptop verwenden werde, von Hand zu erstellen, da das Kompilieren von Paketen auf der realen XO-Hardware sehr viel Zeit in Anspruch nimmt Bild an den XO, kann ich Zeit und Platz sparen.}

Als ich versuchte, einige Pakete zu installieren, schlug die Konfiguration fehl, da die Verzeichnisse proc, sys und dev fehlten. Also habe ich von anderen Stellen gelernt, dass ich die Host-Proc, ... -Verzeichnisse in meine Chroot-Umgebung "einhängen" muss.

Ich habe zwei Syntaxarten gesehen und bin mir nicht sicher, welche ich verwenden soll.

Auf dem Hostcomputer:

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

und eine andere Syntax (in einer Chroot-Umgebung):

  mount -t proc none /proc

Welches sollte ich verwenden, und was ist der Unterschied?

Für /procund /syskönnen Sie vermutlich beide Methoden verwenden. Beide sind spezielle Dateisysteme, sodass sie beliebig oft neu erstellt werden können (die Bind-Mount-Methode verwendet genau die gleiche Mount-Methode wie das Host-System, während die andere Methode eine neue Mount-Methode verwendet). Ich habe immer die in Handbüchern empfohlene Bindebefestigung gesehen, also würde ich sie verwenden. Soweit ich weiß, gibt es keinen wirklich wichtigen Unterschied.

In der /devRegel handelt es sich jedoch um ein tmpfs-Mount, das von udev verwaltet wird. Daher muss es sich um dasselbe Dateisystem wie auf dem Hostcomputer handeln. Das bedeutet, dass Sie die Bind-Mount-Methode verwenden müssen.

Wenn diese Chroot für eine Weile existieren wird, können Sie diese Einträge /etc/fstabauf dem Host-System ablegen, um die Dinge zu vereinfachen.

Das Arch Linux Wiki schlägt die folgenden Befehle vor:

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

Das Gentoo Handbuch ruft speziell diese beiden Befehle zum erneuten Mounten von / proc und / dev auf. Ich habe sie mehrmals benutzt.

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

Ich vermute, / sys ist nur ein normaler Ordner, daher sollten Sie in der Lage sein, einen festen Link zu erstellen.

ln /sys /mnt/chroot/sys

In dieser populären Frage ist es vielleicht erwähnenswert, dass Arch Linux ein Skript erstellt hat, das sich in der Arch -Chroot befindet . herunterladenarch-install-scripts-15-1-any.pkg.tar.xz

Dies behebt verschiedene verwandte Probleme sowohl in Arch-Linux als auch in Manjaro , wo ich es auch erfolgreich eingesetzt habe. Möglicherweise sind auch mehr Arch- Derivate wie Parabel kompatibel.

Während ein einfacher Standard chrootin eine sekundäre Manjaro-Installation nicht zulässt, dass Sie ausgeführt werden

pacman --sync linux

(die silberne Kugel nach einem Systemabsturz), Ersetzen der Zeile mit

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

Damit können Sie Ihre sekundäre Arch-Derivate-Installation über reparieren

pacman --sync linux

wie ein Zauber. Das Bash-Skript arch-chrootkümmert sich um /dev /sys /procund vieles mehr, die vom Standard alleine gelassen werden chroot.

Siehe auch: Verwenden von Arch-Chroot

Es gibt andere Pseudo-Dateisysteme und tmpfs-Speicherorte. Dies ist auf Debian:

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

Es sollte die Montage in Ordnung sein usbfs, rpc_pipefsund devptsPseudo-Dateisysteme in der chroot. Ich empfehle, mich nicht/proc an die Chroots zu binden /proc, da der Kernel das Konzept von Namespaces hat und tatsächlich verschiedene Dinge in den Prozess der Chroots einfügen kann.

Update: Gemäß diesem Mailinglisten-Thread sollte / sys nicht gebunden werden, insbesondere wenn die chroot-Prozesse einen eigenen Netzwerk-Namespace verwenden.

Es ist eine schlechte Idee, das System /varoder /rundie Chroot zu mounten , wenn die Chroot einen eigenen PID-Namespace hat.

Am einfachsten ist es, eine for-Schleife zu verwenden:

cd /

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