Mit immer mehr Macken hat mich das alteingesessene Xubuntu 18.04 auf meinem Gaming-Rechner nun endgültig vergrault. Nachdem die Installation des Arch-Linux-Derivats Antergos auf meinem Notebook so problemlos verlaufen ist, sollte Antergos auch auf dem Produktiv- und Gaming-Rechner zum Einsatz kommen. Ganz so einfach war es dann aber doch nicht. Alte USB-Sticks, UEFI und der Cnchi-Installer der Distribution haben hartnäckig versucht, mich von diesem Plan abzubringen.
Die verschlüsselte Installation auf einem Notebook auf dem die ganze Platte für Antergos zur Verfügung steht, war keine große Sache. Anders sieht es bei meinem Desktop-System mit zwei SSDs und mehreren Festplatten aus. Das neue System soll verschlüsselt installiert werden. Das Antergos-Installationsmedium liefert ein Live-System mit Gnome, aus dem heraus sich der grafische Cnchi-Installer starten lässt.
UEFI war noch neu, als das Mainboard gebaut wurde, dementsprechend unausgereift scheint es. Die Probleme gehen schon los, als ich den Stick nur im UEFI-Modus booten kann. Einen weiteren Eintrag gibt es schlicht nicht. Hier eine wichtige Notiz an mich selbst: NIMM KEINE ALTEN USB-STICKS! Das hätte mir in diesem Fall vor allem viel Zeit gespart – allerdings letztendlich wohl auch nicht funktioniert. Mein Asus-Mainboard wollte den alten Stick partout im UEFI-Modus booten. Wenn ich das System so installiert habe, wollte es aber später nicht booten. Ein neuer Stick wurde zunächst auch als Startmedium im BIOS-Modus anerkannt. Allerdings auch nur einmal, als ich wegen eines Fehlers nochmal neu startete, war schon wieder nur UEFI-Modus angesagt. Wer sich jetzt fragt: Wie erkenne ich das denn? Ganz einfach: Ein schwarzer Bildschirm mit kryptischen Zeilen: UEFI-Modus. Bunter Hintergrund mit vier Startoptionen: BIOS-Modus.
Da ich nicht herausgefunden habe, warum der USB-Stick mal über UEFI und mal auch anders zum Booten angeboten wird, blieb mir nur, eine DVD zu brennen und damit zu installieren.
Noch ein Fehler, den man nicht machen sollte, der mir aber zu später Stunde gern mal passiert und mir eine zweite Installationsrunde eingebracht hat: Wenn man ein verschlüsseltes System installiert, braucht man eine unverschlüsselte /boot-Partition.
Cnchi-Installer bricht ab
Zugegeben: Der Antergos-Installer Cnchi (aktuell Version 0.16.21) ist noch als „Beta“ gekennzeichnet, aber was bleibt einem schon übrig. Ganz smart holt sich das Programm bei der Installation eine aktuelle Liste der herunterzuladenden Pakete aus dem Netz. Hilft aber nix, denn es steht eins drauf, das schlicht nicht verfügbar ist: xorg-mkfontdir. Da hat das Rolling Release wohl die Paketliste überholt. Dafür hat Cnchi keine Lösung und bricht die Installation deshalb unweigerlich ab.
Ein Tipp am Rande: Da Cnchi immer mal wieder Denkpausen einlegt, ist es ganz praktisch, das Programm über ein Terminalfenster zu starten. Cnchi protokolliert dann recht detailliert, was es gerade macht. Auf diese Weise sieht man sofort, wenn das Programm gerade auf eine Verbindung wartet oder Probleme auftreten.
Einfacher Workaround
Im Forum fand ich schließlich den Hinweis auf einen einfachen Workaround für das Problem. Im Verzeichnis /usr/share/cnchi/data/packages.xml des Live-Systems liegt eine Kopie der Paketliste. Die kann man mit einem Editor wie vi bearbeiten und damit die Zeile, die xorg-mkfontdir anfordert, löschen. Anschließend startet man Cnchi so, dass das Tool diese Liste verwendet, statt sich eine Fassung davon herunterzuladen:
cnchi -p /usr/share/cnchi/data/packages.xml
Die Installation läuft dann komplett durch, endet allerdings mit einer Fehlermeldung, dass die Booloader-Installation gescheitert ist. Jetzt besser nicht hektisch neu starten.
Besonders schön wäre jetzt noch, wenn der Dialog mir auch sagen würde, wie ich denn nun konkret rausfinde, ob der Bootloader funktioniert. Aber hier lässt das Tool die Anwenderin im Regen stehen. Das Öffnen der Wiki-Seite klappte bei mir ebenfalls nicht.
Bootloader mit arch-chroot nochmal installieren
Um den Bootloader aus Sicht des neu installierten Systems neu zu generieren, wechselt man in eine chroot-Umgebung. Verwendet man dazu einfach den Befehl chroot, funktioniert das angeblich nicht, das Arch-Linux-Forum empfiehlt, das Skript arch-chroot zu verwenden. Das ist Teil der Arch-Install-Skripte. Bevor es /usr/bin/chroot ausführt, hängt es Dateisysteme wie /proc ein und macht /etc/resolv.conf für chroot verwendbar.
Um den Bootloader Grub neu zu schreiben, sind folgende Schritte nötig: Zunächst wechselt man zu root, hängt die Swap-Partition (bei mir /dev/sda3) ein, mounted das verschlüsselte Root-Dateisystem (bei mir /dev/mapper/arch) nach /mnt und mounted die /boot-Partition nach /mnt/boot:
sudo -s
swapon /dev/sda3
mount /dev/mapper/arch /mnt
mount /dev/sdc1 /mnt/boot
Anschließend ruft man das Skript arch-chroot auf und schreibt den Bootloader neu:
arch-chroot /mnt
grub-mkconfig -o /boot/grub/grub.cfg
Mit exit verlässt man die chroot-Umgebung wieder. Danach konnte ich mein neues, vollverschlüsseltes System per Bootloader Grub problemlos starten.
Alles gut
Endlich läuft alles wie gewünscht. Beim Booten habe ich die Wahl zwischen den installierten Systemen, um Antergos zu starten, wird beim Booten das Passwort zum Entsperren abgefragt. Als Desktop habe ich mich diesmal für Cinnamon entschieden, weil ich als Dateimanager Nemo nutzen will. Nautilus fand ich zunehmend umständlich, Thunar schmiert einfach immer mal wieder ab, wenn es darum geht, größere Dateimengen zu kopieren oder hakt beim Einbinden des Synology-NAS. Als schlankes Backup habe ich auch gleich noch Openbox eingerichtet.
Die auf weiteren Festplatten in verschlüsselten Partitionen lagernden Daten beim Booten automatisch einzubinden, war keine große Sache mehr. Ein Eintrag in die /etc/crypttab und einer in die /etc/fstab genügen, wie’s geht, steht im Arch-Linux-Wiki unter „Mounting at boot time“.