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

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

Advertisement

Ich versuche, ein Linux-Image mit individuell ausgewählten Paketen zu erstellen.
Was ich versuche, ist, die Pakete, die ich auf einem XO-Laptop verwenden werde, von Hand zu erstellen, da das Kompilieren von Paketen auf der echten XO-Hardware sehr lange dauert, wenn ich alle benötigten Pakete bauen und das Image einfach auf den XO flashen kann, kann ich Zeit und Platz sparen.

Als ich versuchte, einige Pakete zu installieren, scheiterte die Konfiguration, weil die Verzeichnisse proc, sys, dev fehlten. Ich habe also von anderen Stellen gelernt, dass ich die Host-Proc-, … Verzeichnisse in meine Chroot-Umgebung “mounten” muss.

Ich habe zwei Syntaxen gesehen und bin mir nicht sicher, welche ich benutzen soll.

In der Host-Maschine:

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

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

mount -t proc none /proc

Welche soll ich benutzen, und was sind die Unterschiede?

Advertisement
Advertisement

Antworten (6)

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

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/
45
45
45
2010-07-19 01:02:06 +0000

Für /proc und /sys könnte man wohl beide Methoden verwenden. Es handelt sich bei beiden um spezielle Dateisysteme, so dass sie beliebig oft neu erstellt werden können (die Bind-Mountmethode verwendet genau dasselbe Mount wie das Hostsystem, während die andere Methode ein neues Mount verwendet). Ich habe die in Anleitungen empfohlene Einbindungsmethode immer gesehen, also würde ich sie verwenden. Soweit ich weiß, gibt es keinen wirklich wichtigen Unterschied.

Allerdings ist /dev normalerweise ein tmpfs-Mount, das von udev verwaltet wird, so dass es sich um dasselbe Dateisystem wie auf dem Host-Rechner handeln muss. Das bedeutet, dass Sie die Bind-Mountmethode verwenden müssen.

Wenn dieser chroot für eine Weile vorhanden sein wird, können Sie diese Einträge in /etc/fstab auf dem Hostsystem zur Vereinfachung einfügen.

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

Das Gentoo Handbook ruft speziell diese beiden Befehle zum Re-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, dass /sys nur ein normaler Ordner ist, also sollten Sie in der Lage sein, einen Hardlink zu erstellen.

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

Es mag in dieser populären Frage erwähnenswert sein, daß Arch Linux ein Skript arch-chroot ; download arch-install-scripts-15-1-any.pkg.tar.xz

This erstellt hat, das sich um verschiedene verwandte Probleme sowohl in Arch-Linux als auch in Manjaro kümmert, wo ich es ebenfalls erfolgreich eingesetzt habe. Möglicherweise sind weitere Arch- Derivate wie Parabola ebenso kompatibel.

Während eine einfache Standard- chroot in eine sekundäre Manjaro-Installation es Ihnen nicht erlaubt,

pacman --sync linux

(die silberne Kugel nach einem Systemabsturz) laufen zu lassen, können Sie durch Ersetzen der Zeile durch

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

Ihre sekundäre Arch-Derivate-Installation über

pacman --sync linux

wie ein Zauber reparieren. Das Bash-Skript arch-chroot kümmert sich um /dev /sys /proc und vieles mehr, die vom Standard chroot allein gelassen werden.

siehe auch: Mit Arch-Chroot

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

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

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

Es gibt weitere 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 in Ordnung sein, die Pseudo-Dateisysteme usbfs, rpc_pipefs und devpts vom chroot aus zu mounten. Ich empfehle nicht das Binden von /proc an die /proc des chroot, da der Kernel das Konzept von Namensräumen hat und tatsächlich verschiedene Dinge in die chroot-Proc setzen kann.

Update: Laut diesem Thread der Mailingliste sollte /sys nicht gemountet werden, besonders wenn die chroot-Prozesse ihren eigenen Netzwerk-Namensraum benutzen.

Es ist eine schlechte Idee, die /var oder /run des Systems in den chroot zu mounten, wenn der chroot seinen eigenen pid-Namensraum hat.

Advertisement

Verwandte Fragen

6
10
5
37
7
Advertisement
Advertisement