Nachdem vor bald zwei Jahren mein Weg zu Arch Linux begonnen hat, läuft auf allen meinen Rechnern inzwischen nur noch Arch. Kein Arch-Derivat wie Manjaro oder Antergos, sondern überall nur Arch pur. So kann ich mein Systeme von Anfang an genau so aufbauen, wie ich es haben möchte. Das macht das Aufsetzen eines Systems ein wenig aufwändiger, doch ich habe noch kein einziges Arch-System noch einmal neu aufsetzen müssen. Somit hält sich der zusätzliche Aufwand durch die rein textbasierte Installation in Grenzen.

Bei all der Freude über ein fortwährend aktuelles System gibt es ab und an kleine Unstimmigkeiten bei der Installation von Software-Updates. Es kann schon mal passieren, dass eine neue Versionen einen Bug mitbringt. Da Arch aber eng am Upstream sitzt, ist dieser meist auch schnell wieder behoben. Die größten Pannen entstehen jedoch nicht durch die Systemupdates: Der größte anzunehmende Fehler sitzt in der Regel vor dem Bildschirm. So fiel bei mir während schon einmal während eines Pacman-Updates der Strom aus oder ich habe die Konfiguration des Bootmanagers verbastelt.

Das hier geschilderte Vorgehen funktioniert selbstverständlich auch bei anderen Linux-Distributionen wie auch mit anderen Live-Linuxen. Im Endeffekt geht es immer darum das eigentlich installierte System in einem Live-Linux per Chroot einzubinden, um in diesem mit dem eigentlich installierten arbeiten zu können, ohne es booten zu müssen.

Das Ergebnis ist am Ende meist das selbe: Wenn man sehr sehr viel Pech hat, dann lässt sich Arch nicht mehr booten. Aus diesem Grunde habe ich bei mir auch immer einen USB-Stick mit einem Ubuntu-System liegen. Von diesem Notfall-System aus lässt sich Arch in der Regel wiederbeleben — egal was zuvor passiert ist. Hat man nur eine Konfigurationsdatei wie die /etc/fstab oder die /boot/syslinux/syslinux.cfg verbastelt, dann kann man diese ja leicht von der Live-CD aus bearbeiten. Hängt allerdings das System, weil zum Beispiel Pacman jäh unterbrochen wurde, dann braucht es ein anderes Kaliber: Ein Chroot in die nicht mehr bootende Arch-Installation.

Arch-Chroot aus Ubuntu

Damit das klappt, müsst ihr euren Rechner von einer Linux-Live-DVD oder einem USB-Stick mit Linux booten. Für meine Zwecke reicht ein USB-Stick mit Ubuntu 14.04 und persistenter Partition aus, so muss ich nicht immer wieder die Spracheinstellungen korrigieren oder den WLAN-Zugang neu einrichten. Ist das Live-System geladen, öffnet ihr als erstes ein Terminal und schaut euch an, welche Device-IDs die in eurem System verbauten Festplatten und Partitionen bekommen haben. Am einfachsten klappt dies in meinem Augen immer mit dem Befehl lsblk.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232,9G 0 disk
├─sda1 8:1 0 26G 0 part
├─sda2 8:2 0 202,9G 0 part
└─sda3 8:3 0 4G 0 part [SWAP]
sde 8:64 1 1000M 0 disk
├─sde1 8:65 1 964M 0 part
└─sde2 8:66 1 2,3M 0 part
loop0 7:0 0 922M 1 loop /rofs

In meinem Fall sitzt das ganze System auf einer 256 GByte großen SSD, also ist /dev/sda das richtige Gerät. Nun weiß ich, dass bei meinem Rechner auf /dev/sda1 das System, auf /dev/sda3 die Homeverzeichnisse und auf /dev/sda4 das Boot-Verzeichnis liegt; kennt ihr euch auf eurem System nicht so gut aus und lässt sich auch aus der Partitionsgröße nicht auf die Zugehörigkeit schließend, dann könnt ihr aus dem Dateimanager heraus die Partitionen kurz einbinden und so direkt nachsehen, welche Daten wo liegen.

Lsblk gibt die Device-ID der im Rechner gefundenen Laufwerke übersichtlich aus.
Lsblk gibt die Device-ID der im Rechner gefundenen Laufwerke übersichtlich aus.
Im Dateimanager könnt ihr überprüfen welche Daten auf welcher Partition zu finden sind.
Im Dateimanager könnt ihr überprüfen welche Daten auf welcher Partition zu finden sind.

Ist die Frage geklärt, holt ihr euch mit sudo -s Root-Rechte und erzeugt einen Mount-Punkt für euer Arch-System im aktuellen Live-Linux; für mein Beispiel nutze ich einfach /arch. In dieses mountet ihr zuerst die Systempartition, dann die Homepartition nach /arch/home und schließlich — natürlich nur wenn /boot auch auf einer eigenen Partition liegt — die Bootpartition eures Arch-Systems.

$ sudo -s
$ mkdir /arch
$ mount /dev/sda1 /arch
$ mount /dev/sda2 /arch/home
### Falls ihr weitere Partitionen nutzt...
$ mount /dev/sda4 /arch/boot

Damit das Chroot später komplett funktioniert, müsst ihr nun noch Symlinks zu dynamischen Verzeichnissen des Live-Systems wie /proc oder /dev in den zukünftigen Chroot-Bereich legen. Alleine mit diesen Symlinks würde allerdings der Netzwerkzugang inklusive Namensauflösung noch nicht korrekt funktioniern, holt euch daher noch die resolv.conf des Live-Linux in das Chroot rüber. Ist das alles geschehen, öffnet ihr schließlich mit dem Chroot-Befehl euer Arch-Linux — ohne es vorher Booten zu müssen.

$ mount -t proc none /arch/proc
$ mount -t sysfs none /arch/sys
$ mount -o bind /dev /arch/dev
$ mount -o bind /dev/pts /arch/dev/pts # Wichtig für Pacman
$ cp -L /etc/resolv.conf /arch/etc # Für Netzwerkzugriff
$ chroot /arch bash

Im Chroot arbeitet ihr nun mit sämtlichen Daten eures Arch-System, die Wurzel des Verzeichnisbaums beginnt wie gewohnt bei / und nicht mehr mit dem zuvor erstellten Mountpunkt. Zum Bearbeiten der fstab wechselt ihr also einfach nur nach /etc und öffnet dort die Fstab-Datei mit einem Editor wie zum Beispiel Nano: nano /etc/fstab. Ihr braucht sogar auf Programme mit einer graphischen Oberfläche nicht verzichten, dazu müsst ihr lediglich den Xserver des Ubuntu-Systems mit xhost + für Zugriffe von außen öffnen.

Mithilfe des Chroot lässt sich von Ubuntu aus direkt in Arch arbeiten.
Mithilfe des Chroot lässt sich von Ubuntu aus direkt in Arch arbeiten.
Erlaubt man den Zugriff auf den Xserver des Ubuntu-Systems lassen sich auch Programme mit GUI starten.
Erlaubt man den Zugriff auf den Xserver des Ubuntu-Systems lassen sich auch Programme mit GUI starten.

Befehle wie pacman -Syu zum Einspielen von Updates oder etwa syslinux-install_update -i -a -m für die Neu-Installation des Syslinux-Bootloaders lassen sich direkt aus dem Chroot ausführen, als ob ihr aus eurem Arch-System heraus arbeiten würdet. Mit ein bisschen Ellbogenschmalz und Geschick beim Googeln nach Fehlermeldungen bekommt man sein Arch danach in der Regel wieder recht schnell flott, sodass man wieder ganz normal von der Festplatte oder der SSD booten kann.

Vorheriger ArtikelRaspberry Pi zeigt kleines buntes Quadrat rechts oben im Display?
Nächster ArtikelIt’s done! Debian 8 Jessie kommt am 25. April
Hallo, ich bin Christoph - Linux-User, Blogger und pragmatischer Fan freier Software. Wie ihr ohne Zweifel bemerkt haben solltet, schreibe ich hier über Linux im Allgemeinen, Ubuntu im Speziellen sowie Android und andere Internet-Themen. Wenn du Freude an meinen Artikel gefunden haben solltest, dann kannst du mir über Facebook, Twitter oder natürlich dem Blog folgen.

8 Kommentare

  1. Warum nicht einfach mit einem hauseigenen Arch-ISO Arch reparieren?

    Partition mounten -> arch-chroot /partition

    Du sparst dir eine Menge Arbeit damit.

    • Wenn man sowas gerade da hat, dann ja. Wenn man aber währenddessen auch durchs Netz surfen muss, etwa um Hinweise zum Problem zu finden, dann ist man mit einem Live-Linux mit GUI einfach besser unterwegs. Grüße, Christoph.

  2. Eine Verwendungszweck wäre z.B das arbeiten an einem nicht bootenden Arch System welches auf einem mit gummiboot inkompatiblen UEFI Geräte installiert ist. So habe ich jedenfalls gerade mein Arch repariert 🙂

  3. Statt des -o bind kann ich -o rbind empfehlen! Mountet auch innere Binds rekursiv neu, dann kann man sich das /dev/pts sparen ;-).

Schreibe einen Kommentar zu Christoph Langner Antwort abbrechen

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein