Differences

This shows you the differences between two versions of the page.

--- arm:chroot_into_arm_architecture [2017/02/26 13:14] – created sascha
+++ arm:chroot_into_arm_architecture [2018/02/17 17:41] (current) – sascha
@@ Line 3: / Line 3: @@
 Mittels ''[[linux:chroot]]'' in ein anderes Linux wechseln, um Reparaturen vorzunehmen, kann eine sehr praktische und zeitsparende Angelegenheit sein. Schwieriger wird es, wenn sich die Prozessorarchitektur des Zielsystems von dem aktuell verwendeten unterscheiden, da nahezu alle Programme als Binärdaten vorliegen, die die Instruktionen entsprechend für den jeweiligen Prozessor verwenden. Nehmen wir beispielsweise die Architektur ''x86_64'', auch bekannt als amd64, die 64 Bit-Variante des x86-Instruktionssatzes, welche auf nahezu jedem aktuellen Computer verwendet wird, und als Zielsystem ''armv7l'', ein Prozessor vom Typ ARMv7 mit 32 Bit, wie er beispielsweise beim Raspberry Pi 3 oder vielen Mobilgeräten Verwendung findet. ARM-Prozessoren mit 64 Bit weisen die Architektur ARMv8 auf. Würden wir einfach mittels ''chroot'' in ein solches ARM-System wechseln, würden die dort befindlichen für ARM kompilierten Binärpakete auf dem aktuellen Prozessor ausgeführt, der diese Instruktionen nicht kennt. Ergebnis wären Fehlermeldungen der Form
-  Kann die Binärdatei nicht ausführen: Fehler im Format der Programmdatei
+> Kann die Binärdatei nicht ausführen: Fehler im Format der Programmdatei
 oder
-  Konnte execv nicht aufrufen (Fehler im Format der Programmdatei)
+> Konnte execv nicht aufrufen (Fehler im Format der Programmdatei)
-  Fehler: Befehl konnte nicht korrekt ausgeführt werden
+> Fehler: Befehl konnte nicht korrekt ausgeführt werden
 Um dies zu umgehen, kann entweder eine [[arm:qemu_armv7_debian_vm|virtuelle Maschine mit einem ARM-System]] aufgesetzt werden, um die ARM-Instruktionen nativ verarbeiten zu können, oder man bedient sich statischer Binärpakete des [[http://www.qemu-project.org/|QEMU-Projekts]] für die verschiedensten Architekturen, was im Folgenden erklärt wird.
@@ Line 58: / Line 58: @@
 Wechseln wir nun mittels ''sudo chroot /mnt'' das Wurzelverzeichnis, erhalten wir keine Fehlermeldungen, da der Kernel jetzt weiß, wie er die ARM-Instruktionen zu handhaben hat. Auch ein ''uname -a'' oder das Ausführen von Shell-Skripten funktioniert auf diese Weise ohne weiteres.
+==== chroot für komplexere Aufgaben mit Einhängepunkten (mount / mtab) ====
+Ist wie zuvor beschrieben das zu reparierende System eingebunden und ein Binärinterpreter für ARM hinterlegt worden, sollte es möglich sein, nahezu alle Aufgaben zu erledigen. In seltenen Fällen kann es jedoch sein, dass die mount points oder Einhängepunkte benötigt werden, speziell die Datei ''/etc/mtab''. In dieser Datei sind alle aktuellen Einhängepunkte des Systems zu sehen, welche auch bei der Eingabe von ''mount'' ausgegeben werden.
+Sollte dies der Fall sein, wird man Fehlermeldungen wie
+> could not open file: /etc/mtab: No such file or directory
+oder
+> could not determine filesystem mount points
+erhalten. Probleme dieser Art lassen sich beheben, indem die von Linux verwendeten und benötigten speziellen Verzeichnisse ''/dev'' (Geräteinformationen), ''/proc'' und ''/sys'' (Schnittstellen zum Kernel für die Kommunikation mit laufenden Prozessen und Kernel-Subsystemen) zur Verfügung gestellt werden. Diese virtuellen Dateisysteme können wie folgt eingebunden werden, dabei gehe ich wie weiter oben davon aus, dass das System unter ''/mnt'' gemountet wurde:
+  cd /mnt
+  sudo mount -t proc proc proc/
+  sudo mount --rbind /sys sys/
+  sudo mount --rbind /dev dev/
+Anschließend kann wie gewohnt mit einem
+  sudo chroot /mnt
+in das eingebundene Linux-System gewechselt werden.
+Sollte es nach Beendigung der Arbeiten beim Unmounten Probleme geben, da das Verzeichnis noch verwendet wird oder beschäftigt ist, kann statt beispielsweise einem
+  sudo umount --recursive /mnt
+ein ''%%--force%%'' angehängt werden. Sollte auch dies nicht helfen, kann als Notlösung ein ''%%umount --lazy%%'' verwendet werden,
+  sudo umount --recursive /mnt --lazy
+dabei werden die Einhängepunkte ohne Überprüfungen einfach freigegeben. Dies kann jedoch höchstwahrscheinlich zu Problemen auf dem aktuellen Host-System führen, weswegen nach der Verwendung von ''%%--lazy%%'' nach Möglichkeit so schnell wie möglich ein Neustart durchgeführt werden sollte.
+{{tag>linux chroot arm binfmt-misc mount mtab}}