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


87

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?


Achtung: Wenn Sie Zugriff auf die Festplattengeräte gewähren, verlieren Sie einige der Vorteile von ' chroot()'. Insbesondere können die Ermittelten Dateien außerhalb ihres Abschnitts des Dateisystems lesen, wenn Sie nicht vorsichtig sind.
Jonathan Leffler

2
@ Jonathan Leffler: Das klingt nicht nach einem Problem für das, was er tut.
Zifre

@JonathanLeffler Ein Root-Benutzer in einer Chroot kann der Chroot ohnehin immer entkommen.
LtWorf

Antworten:


43

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.


Ich möchte fragen, ob es sinnvoll ist, das proc / sys vom Host auf eine andere Maschine zu kopieren (zu binden). Warum sollten sie zu dieser Maschine passen?
Ransh

@ransh es macht Sinn, wenn Sie / proc an $ chrootdir / proc binden, haben Sie die Möglichkeit, den Prozess und die Vorgänge in / proc beider Systeme von beiden Systemen aus zu handhaben. zB: von chroot können Sie überprüfen, ob ein Programm auf dem Host läuft ... usw.
Jonah

Vielleicht sys typescheint das Dateisystem ( heute ) nicht mehr zu existieren?
174140

111

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/

2
Sie schienen auch in Ubuntu für mich zu arbeiten.
Isaaclw

4
In meinem Fall (auch Ubuntu) brauchte ich auch ein "mount -o bind / dev / pts dev / pts".
Thomas

Bitte geben Sie den Link zur Quelle an.
Styropor fliegen

@styrofoamfly Hinzugefügt.
Gacrux

1
Seit 2019 gibt es das ArchLinux-Wiki --rbindfür sysund dev.
Saad Malik

12

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

17
Sie können ein Verzeichnis (normalerweise) nicht fest verlinken, wie Sie es für / sys vorschlagen, und wenn Sie einen Symlink verwenden, wird dieser unterbrochen, sobald Sie chroot ausführen.

Sie haben einige neue hinzugefügt, basierend auf systemd. Vielleicht ist es eine gute Idee, sie hinzuzufügen.
AzP

1

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


-1

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.


Spekulation? Bei Superuser (und anderen Stack-Foren) ist es normalerweise besser, sich zurückzuhalten oder mit verknüpften Quellen zu recherchieren und zu antworten, wenn Sie sich nicht sicher sind. Auf diese Weise soll vermieden werden, dass irreführende Hinweise verbreitet werden. Sorry wenn enttäuscht und viel Glück!
Simon B.

@SimonB. Ich habe einen Link zu einer Mailingliste hinzugefügt, der die Idee unterstützt, dass / sys nicht gebunden werden sollte.
Brian Minton

Beim PID-Namespace geht es um erweiterte Funktionen für den Benutzernamensraum, die wir in modernen Linux-Kerneln finden (dh die Funktionen, auf denen "Container" basieren). Wenn wir den Begriff "Chroot" verwenden, beziehen wir uns auf die traditionelle Änderung des Dateinamensraums ( und sonst nichts).
Johan Boulé

-1

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

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.