mount dev, proc, sys in einer chroot-Umgebung?

187164
Patrick

Ich versuche, ein Linux-Image mit benutzerdefinierten Paketen zu erstellen.
Was ich versuche zu tun ist, die Pakete, die ich auf einem XO-Laptop verwenden werde, von Hand zu fertigen, da das Kompilieren von Paketen auf der realen XO-Hardware sehr lange dauert, wenn ich alle benötigten Pakete zusammenstellen kann und nur die Bild auf dem XO kann ich Zeit und Platz sparen.

Beim Versuch, einige Pakete zu installieren, konnte die Konfiguration nicht durchgeführt werden, da die Verzeichnisse proc, sys und dev nicht vorhanden waren. Also habe ich von anderen Orten gelernt, dass ich die Host-Proc-, ...-Verzeichnisse in meine Chroot-Umgebung "einhängen" muss.

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

In der Hostmaschine:

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

und eine andere Syntax (in Chroot-Umgebung):

 mount -t proc none /proc

Welches sollte ich verwenden und was ist der Unterschied?

74
Achtung: Wenn Sie Zugriff auf die Festplattengeräte gewähren, gehen einige Vorteile von chroot () verloren. Insbesondere können die Ermittelten Dateien außerhalb ihres Abschnitts des Dateisystems lesen, wenn Sie nicht aufpassen. Jonathan Leffler vor 14 Jahren 0
@ Jonathan Leffler: Das hört sich nicht nach einem Problem für das an, was er tut. Zifre vor 14 Jahren 2
@JonathanLeffler Ein Rootbenutzer in einer Chroot kann der Chroot immer entkommen. LtWorf vor 8 Jahren 0

5 Antworten auf die Frage

94
gacrux

Das Arch Linux Wiki schlägt folgende Befehle vor:

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/

Ich kann bestätigen, dass sie für mich gearbeitet haben.

Sie schienen auch in Ubuntu für mich zu arbeiten. isaaclw vor 12 Jahren 2
In meinem Fall (auch Ubuntu) brauchte ich auch ein "mount -o bind / dev / pts dev / pts". Thomas vor 8 Jahren 3
42
Zifre

Für /procund /sysSie könnten beide Methoden verwenden. Bei beiden handelt es sich um spezielle Dateisysteme, sodass sie beliebig oft neu erstellt werden können (die Bind-Mount-Methode verwendet genau das gleiche Mount wie das Host-System, während die andere Methode ein neues Mount verwendet). Ich habe immer die Bindungshalterung gesehen, die in den Anleitungen empfohlen wird, also würde ich sie verwenden. Meines Wissens gibt es keinen wirklich wichtigen Unterschied.

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

Wenn diese chroot für eine Weile in /etc/fstabder Nähe ist, können Sie diese Einträge auf dem Hostsystem einfügen, um die Dinge zu vereinfachen.

Ich möchte fragen, ob es sinnvoll ist, die proc / sys vom Host auf einen anderen Rechner zu kopieren (zu binden)? Warum sollten sie zu dieser Maschine passen? ransh vor 7 Jahren 0
@ransh Es macht Sinn, wenn Sie / proc an $ chrootdir / proc binden, haben Sie die Möglichkeit, den Prozess und das, was innerhalb von / proc beider Systeme vor sich geht, von beiden Systemen aus zu handhaben. zB: von chroot aus können Sie überprüfen, ob ein Programm auf dem Host läuft ... etc Jonas vor 7 Jahren 0
Vielleicht scheint der "sys" - "Typ" des Dateisystems (** heute **) nicht mehr zu existieren? uprego vor 6 Jahren 0
9
robert

Im Gentoo-Handbuch werden diese beiden Befehle speziell zum erneuten Einhängen von / proc und / dev aufgerufen. 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 regulärer Ordner, daher sollten Sie in der Lage sein, eine feste Verbindung herzustellen.

ln /sys /mnt/chroot/sys
Sie können ein Verzeichnis (normalerweise) nicht wie für / sys hardlink verknüpfen, und wenn Sie einen Symlink verwenden, bricht es, sobald Sie chroot sind. vor 14 Jahren 17
Sie haben einige neue hinzugefügt, basierend auf systemd. Vielleicht ist es eine gute Idee, sie hinzuzufügen. AzP vor 6 Jahren 0
0
y guy

In dieser populären Frage kann es erwähnenswert sein, dass Arch Linux ein Skript arch-chroot erstellt hat ; 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 mehr Erz- Derivate wie Parabola sind genauso gut verträglich.

Während ein einfacher Standard chrootin einer sekundären Manjaro-Installation nicht ausgeführt werden kann

pacman --sync linux

(die silberne Kugel nach einem Systemabsturz) und ersetzt die Zeile mit

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

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, was der Standard alleine lässt chroot.

siehe auch: Verwendung von Arch-Chroot

-1
Brian Minton

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, nicht/proc an die Chroots zu binden /proc, da der Kernel das Konzept von Namespaces hat und tatsächlich verschiedene Dinge in den Chroot-Proc setzen kann.

Update: Laut diesem Mailing- Listenthread sollte / sys nicht gebunden gemountet werden, insbesondere wenn die chrootierten Prozesse ihren eigenen Netzwerknamensraum verwenden.

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

Spekulation? Bei Superbenutzern (und anderen Stapelforen) ist es in der Regel besser, zu warten oder mit verknüpften Quellen zu recherchieren, wenn Sie unsicher sind. So vermeiden Sie das Risiko, falsche Hinweise zu verbreiten. Entschuldigung, wenn enttäuscht und viel Glück! Simon B. vor 8 Jahren 0
@ SimonB. Ich habe einen Link zu einer Mailingliste hinzugefügt, der die Idee unterstützt, dass / sys nicht gebunden eingebunden werden sollte. Brian Minton vor 8 Jahren 0
Mit dem PID-Namespace sprechen Sie von erweiterten Features für Benutzer-Namespaces, die wir in modernen Linux-Kerneln finden können (dh die Features, auf denen "Container" basieren). Wenn wir den Begriff chroot verwenden, beziehen wir uns auf die Änderung des traditionellen Dateinamens ( und sonst nichts). Johan Boulé vor 7 Jahren 0

Verwandte Probleme