Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM

Posted on by

In den letzten Beiträgen meiner Serie zu Voll-Verschlüsselung eines Laptops und angrenzenden Themen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen

haben wir uns auf einer externen SSD bereits Partitionen und LUKS-LVM-Volumes (LUKS on LVM / VGs: vga, vgs / LVs: lva1, lvs1) für eine Test-Installation von Opensuse Leap 15.0 erstellt. Das Alignment hatten wir dabei – entgegen den Fake-Informationen des externen USB-Controllers – bereits auf die spätere Nutzung der SSD direkt am SATA-III-Bus des Laptops ausgerichtet. Wir schließen diese Disk nun an den Laptop als externe USB-Disk an und nehmen eine Opensuse-Leap15-Installation vor. Ich greife dabei auf ein ISO-Image für eine Installations-DVD zurück. Der Laptop wird von mir an ein geeignetes LAN-Segment angeschlossen; Firewalls erlauben einen Zugriff auf Update Repositories von Opensuse im Internet.

Der Installationsprozess muss anschließende Boot-Vorgänge von verschlüsselten LVM-Volumes sicherstellen. Das betrifft einerseits reguläre Bootvorgänge, andererseits aber auch einen Bootvorgang aus einem vorhergehenden Hibernation-Zustand. Wir ignorieren letzteres in einem ersten Anlauf – und verzichten zunächst völlig auf die Einbindung eines SWAPs. Das führt zu einer Vereinfachung; der Hauptgrund ist aber, dass der Opensuse-Installer mit der Konfiguration auf Basis vorgefertigter LUKS-Devices Probleme hat.

Ich gehe zu Beginn dieses Artikels kurz auf Schritte und Elemente eines regulären Boot-Vorgangs ein und bespreche erst danach einige wichtige Schritte während der Installation. Das erscheint mir zum besseren Verständnis einiger Aktionen sinnvoll.

Ziel ist zudem keine detaillierte, allgemeingültige Installationsanleitung für Opensuse Leap; ich setze vielmehr voraus, dass der interessierte Leser auf seinem Laptop schon mal eine Standard-Opensuse-Installation durchgeführt hat. Hier geht es lediglich um Besonderheiten, die bei der Installation auf LUKS-Volumes zu beachten sind.

Hinweise: Mein Laptop hat ein Optimus-System (prozessorinterne Grafikkarte + Nvidia-Karte im Verbund). Das macht immer etwas Probleme; in meinem Fall muss man von vornherein bestimmte Video-Einstellungen wählen, um überhaupt den grafischen Install-Bildschirm zu erreichen. Darauf werde ich kurz eingehen. Zudem besitzt mein Test-Laptop noch ein Legacy BIOS. Mit OS kürze ich nachfolgend “Betriebssystem” ab; FS steht für “Filesystem”.

Für die
schlechte Qualität der Bilder entschuldige ich mich; ich habe die am Abend gemacht und die falsche Einstellung am Handy gewählt :-(.

Schritte beim Booten

Um ein paar kritische Punkte im Installationsablauf zu verstehen, ist ein vorheriger grober Überblick über Schritte eines Boot-Vorgangs nützlich, in dem verschlüsselte Devices angesprochen werden müssen. Wir sollten uns an dieser Stelle daran erinnern, dass wir das für den Boot-Vorgang so wichtige Verzeichnis “/boot” nicht auf ein separates Volume oder eine separate Partition gelegt hatten; “/boot” ist mit seinen Inhalten vielmehr echter Bestandteil des “/”-Filesystems, welches im verschlüsselten (Raw-) Volume “/dev/vga/lva1” residiert (LVM => LUKS => “/”-FS mit ext4 => inodes für “/boot” und dessen Inhalte).

In jedem modernen Linux-System findet ein Mapping der LVM Volume Groups [VG] und Volumes [LVM] sowie der LUKS-basierten Crypto-Devices auf Einträge unter “/dev/mapper” statt. Der OS-Installer muss dafür sorgen, dass den am Boot-Prozess beteiligten Komponenten alle notwendigen Informationen an geeigneter Stelle zur Verfügung gestellt werden:

  • Der Bootmanager Grub2 (mit seinem Mini-Kernel) muss ein Minimum an Modulen laden, um verschlüsselte LVM-Devices erkennen, mappen und öffnen zu können; in meinem Fall sind das die Module gzio, part_gpt, lvm, cryptodisk, luks, gcry_rijndael, gcry_sha512, ext2.
  • Im Fall von “LUKS on LVM” müssen zuerst die LVM-“Volume Groups” [VG] wie die zugehörigen Volumes [LV] erkannt und gemappt werden. Danach ist die Verschlüsselung der Blöcke der (Raw-) Volumes zu behandeln. Erst dann ist der Zugang zum Filesystem möglich. Das LUKS-Volume, das das “/”-Filesystem [FS] enthält, muss also zwischenzeitlich geöffnet und ebenfalls gemappt werden. (Hierzu muss es einen passenden Eintrag in der Grub-Konfiguration geben, der auf die Krypto-UUID (s.u.) des (Raw-) Devices referenziert). Voraussetzung für weitere Schritte ist ferner die Abfrage der Passphrase durch Grub zur Ermittelung des LUKS-Master-Keys [MK].
  • Danach ist das “/”-Filesystem anhand dessen UUID im Crypto-Device zu identifizieren. Das enthaltene “/boot”-Verzeichnis ist auszulesen.
  • Der vorgesehene Linux-Kernel ist von dort zu laden; dem Kernel sind geeignete Parameter für weitere Schritte zu übergeben. Ein temporäres FS ist zu etablieren.
  • Eine initiales RAM-Filesystem (initramfs (liegt bei Suse unter /boot/initrd!) wird geladen, um notwendige Module/Treiber an den Kernel anbinden und initiale Scripts auszuführen zu können (u.a. zur HW- und Device-Detection).
  • Der echte Linux-Kernel übernimmt die Kontrolle und startet ein spezielles systemd (init) vom initramfs unter Nutzung von udev.
  • Crypto-Devices (u.a. verschlüsselte Resume-(Swap)-Devices für Hibernation-Reboot, aber natürlich auch wieder das Volume mit dem echten “/”-FS) werden dabei vom Linux-Kernel erkannt, geöffnet, gemappt und temporär gemountet. Relevante Dateien im “/”-FS sind auszulesen (u.a. /etc/crypttab, /etc/fstab).
  • Das echte root-Filesystem muss mit mittels pivot_root auf “/” eingehängt werden; das initramfs ist abzuhängen. Weitere Mount-Vorgänge sind durchzuführen, der eigentliche systemd-Dämon aus dem “/”-FS ist zu starten.

Siehe hierzu etwa:
[book.opensuse.reference/cha.boot.html]
http://man7.org/linux/man-pages/man7/dracut.bootup.7.html

Nützlich ist später auch ein Blick in die vom
Installer erstellte Datei “/boot/grub2/grub.cfg”. An den enthaltenen Anweisungen kann man die ersten der oben genannten Punkte quasi ablesen. Zwei nennenswerte Konsequenzen sind:

Vorbereiten von Grub2-Command-Line-Parametern:
Wichtige Schritte im Boot-Vorgang – Krypto-Devices öffnen und mappen, Auslesen enthaltener Filesysteme – müssen zunächst durch Grub2 in richtiger Reihenfolge abgewickelt werden; dem zu ladenden Kernel muss Grub2 anschließend vernünftige Start-Parameter übergeben. Der Installer muss also eine passende Datei grub.cfg mit Hinweisen auf verschlüsselte Devices erzeugen und entsprechende Boot-Manager-Komponenten auf die Platte schreiben.

Vorbereiten von initramfs und systemd:
Des weiteren sind aber auch bestimmte Kernel-Module für die Behandlung kryptierter Devices im initramfs zu hinterlegen. Weitere Startup-Schritte müssen durch spezielle systemd-Komponenten des initramfs und durch den normalen systemd-Dämon nach Einhängen des richtigen “/”-FS für den Kernel abgewickelt werden. Voraussetzungen für das Erreichen von systemd-Targets müssen adäquat gesetzt werden (über systemd-Generatoren). Die Erzeugung der initramfs und die systemd-Konfiguration erfolgt nicht nur bei Opensuse Leap durch “dracut“; das Programm wird gegen Ende der Installation aufgerufen.

Mehrfache Eingabe von Passwörtern im Boot-Vorgang:
Grub2 muss mindestens mal das LVM-Volume mit dem “/”-FS öffnen und auslesen. Aber auch der später geladene reguläre Linux-Kernel muss alle zu mountenden chiffrierten Devices öffnen, mappen und mounten! Daraus ergibt sich, dass wir – zumindest ohne weitere Tricks und Hilfsmittel – bestimmte Passwörter ggf. zweimal angeben müssen. Ist ein kryptierter SWAP-Bereich im Spiel, so ist u.a. im Vorfeld eines Starts aus dem Hibernation-Zustand auch das Passwort für den SWAP einzugeben.

Hinweis: Es hilft im jetzigen Stadium etwas, wenn die Passwörter für verschiedene Devices – z.B. “/”-FS und SWAP identisch sind! Das wird erkannt; einige Abfragen können so vermieden werden. Später werden wir dann auch noch Keyfiles nutzen, um den geladenen Kernel zu befähigen, sich selbst einen Zugang zu sekundären kryptierten Devices zu verschaffen.

Während der Installation nutzt Opensuse zur Konfiguration der beteiligten Komponenten (und im Besonderen von Grub2) Einstellungen, die dem “YaST Partitioner” vom User mitgegeben werden. Der Partitioner wird dem User schon zu Beginn der Installation angeboten. Am Ende der Installation wird über ein Wrapper-Script namens “mkinitrd” dracut für die Erzeugung des initramfs (liegt bei SuSE unter “/boot/initrd”) und für eine Durchführung der Boot-Loader-Konfiguration (Grub2) aufgerufen.

Die Default-Einstellungen für Grub2 (s. “/etc/default/grub”) und auch von dracut sind unter OS Leap 15 so, dass dabei eine Detektion von Crypto-Devices angestoßen wird. U.a. wird dabei die Informationen in der Datei “/etc/crypttab” im “/”-FS ausgewertet. Die Auswertung dieser Datei durch dracut ist nicht zuletzt für das korrekte Setup von systemd (im initramfs und im “/”-FS) relevant. Siehe zur Crypto-Device-Detection auf einem laufenden SuSE-System etwa die Datei “/etc/default/grub”; sie enthält eine Zeile der Form
‘GRUB_ENABLE_CRYPTODISK=”y”‘.

Für Infos zu dracut s. unten angegeben Links; dracut sorgt dafür, dass für host-Installationen das Modul “crypt” bereitsteht, wenn es dazu Hinweise erhält (explizite Parameter für den dracut-Aufruf, Analyse von /etc/crypttab) erhält. Fazit:

Die Existenz der Datei “/etc/crypttab” im künftigen “/”-FS ist zu gewährleisten, bevor am Ende der Installation dracut mittels mkinitrd ausgeführt wird und die Bootloader-
Konfiguration auf die Platte geschrieben wird.

Hinweis: mkinitrd bzw. dracut führen zur Erzeugung der nötigen Dateien während der Installation einen chroot-Wechsel in das in der Installer-Umgebung unter “/mnt” gemountete LVM-LUKS-Volume mit dem künftigen “/”-FS durch.

Ein Problem des SuSE-Installers

Der SUSE-Installer legt wesentliche Aktionen zur ordnungsgemäßen Boot-Konfiguration fest, indem er entsprechende Informationen des Anwenders aus Optionen des YaST-Partitioners aufgreift und in eine Standardkonfiguration – u.a. bzgl. LUKS umsetzt. Die Entwickler sind dabei offenbar davon ausgegangen, dass eine Verschlüsselung immer (mit Standardparametern) über SuSEs Partitioner angefordert wird. An die Möglichkeit einer eigenen LUKS-Parametrierung hat man dabei wohl nicht gedacht.

So hat leider niemand die entsprechenden Ruby-Programme befähigt, mit bereits vorbereiteten LUKS-Volumes (eigene LUKS-Parametrierung; eigenes Alignment!) adäquat umzugehen und daraus auch die notwendigen Konsequenzen für die Erstellung der Boot-Konfiguration zu ziehen. Bestimmte Schritte werden also leider nur dann korrekt getriggert, wenn man innerhalb des Partitioners eine (Neu-)Verschlüsselung gem. SuSE-Standard-Parametrierung anfordert. Unterbleibt das, so ist eine Konsequenz leider, dass dracut und systemd-Generatoren im späteren root-Filesystem keine Datei “/etc/crypttab” vorfinden. Das führt bei einem Reboot nach der Installation zu Fehlern und in einen nicht arbeitsfähigen Zustand des frisch installierten Leap-Systems.
https://bugzilla.opensuse.org/show_bug.cgi?id=1024240
https://bugzilla.redhat.com/show_bug.cgi?id=868421

Die in einigen Kommentaren von SuSE angeführte Auffassung, dass jemand, der ein LUKS-Volume selbst aufsetzt, gefälligst selbst für die Bereitstellung der “/etc/crypttab” zu sorgen hätte, ist insofern kritikwürdig, als es im Installationsprozess hierfür keinen geeigneten Punkt gibt, an dem man das erledigen könnte. Zudem ist nicht nachvollziehbar, warum der Partitioner zwar kryptierte Volumes mit Filesysteme erkennt, aber nicht rückfragt, ob eine Datei “/etc/crypttab” angelegt werden soll und eine solche auch nicht aus der Umgebung des Installers übernimmt, wenn man sie denn dort prophylaktisch zu Beginn des Installationsprozesses hinterlegt.

OK, nun zur Praxis.

Schritt 1: Booten von Installations-DVD

Wir brennen zunächst ein ISO-Image des Leap-15-Installationssystems auf DVD. Man bekommt das Image unter:
https://software.opensuse.org/distributions/leap.
Dann: Installer-DVD einlegen; vorbereitete SSD als externes USB-Laufwerk anschließen. Ggf. mit Spezialtaste das Boot-Menü anzeigen lassen (auf meinem Laptop ist das die F11-Taste). Die DVD wählen und booten. (Auf UEFI-Systemen muss man ebenfalls eine geeignete Taste zum Anzeigen der EFI-Boot-Optionen zu bekommen. Ich kann hier nicht auf Details eingehen).

Auf dem Begrüßungsschirm (jetzt im Winter ggf. mit herumlaufenden Pinguinen) sollte es am unteren Rand eine Reihe von Optionen geben, die über Fn-Tasten zu erreichen sind: F2 – Sprache // F3 Videomodus.
Wir stellen über F2 “Deutsch” ein. Ein Drücken von F3 bietet drei Einstellungsmöglichkeiten. In meinem Fall war die Wahl maximaler Auflösung sowohl für den Bereich “Installer Size” und “Video Bios Size” sinnvoll. Bzgl. der “Text Console Size” musste ich allerdings zwingend “Keine KMS” wählen.

  • Installer Size => 1920×1200
  • Text Console Size => Keine KMS (ggf. zwingend auf Optimus-System)
  • Video BIOS Size => 1920 x 1080

Eine andere Wahl bei “Text Console Size” führte unmittelbar nach dem Laden des Installationssystems zum Stillstand des Laptops (nach “Loading Installation System (6/6)”). Ich habe auch schon Systeme erlebt, wo das schon vorher (beim Starten von udev) geschah. Wir starten nach diesen Festlegungen die “Installation” per Klick auf den entsprechenden Punkt:

Es wird ein Installations-Kernel geladen, nach einem weiteren Schirmbild laufen am unteren Rand grüne Balken hoch. Wir drücken die “Escape”-Taste, um hierzu mehr Infos zu erhalten. udev wird gestartet. Danach wird (hoffentlich) die Netzwerk-Karte erkannt und eine IP-Adresse vom nächsten DHCP-Server im LAN bezogen. Anschließend sieht man 6 Zeilen der Art “Loading Installation System (n/6)”. Geht dabei alles gut, wird ein graphisches Interface gestartet. Repositories aus dem Internet werden hinzugefügt (Hinweis: hierfür benötigt man ausgehende http/https-Verbindungen zu download.opensuse.org; die müssen für die per DHCP vorgegebene IP des Laptops auf den eigenen Firewalls freigegeben sein. Wir landen schließlich auf einer grafischen Seite “Sprache, Tastatur und Lizenzvereinbarungen”. Wir testen kurz die Tastatur und drücken auf die Taste “Weiter”.

Nun wird es interessant; das System prüft die Festplatten und erkennt dabei offenbar die vorbereiteten verschlüsselten LVM-Volumes. Wir werden nach den Passwörtern zur Entschlüsselung gefragt:

Anschließend werden wir nach der Art der Installation gefragt. Wir wählen hier “Server”, um die Menge der zu installierenden Daten auf ca. 1.8 GB zu begrenzen. Könnten wir auch noch weiter reduzieren; aber da wir während der Installation später ein wenig Zeit für eigene Aktionen benötigen, ist das OK. Auf der nächsten Seite haben wir die Möglichkeit, unten den YaST-“Experten-Partitioner” zu wählen – und einen “Start mit vorhandenen Partitionen” auszulösen:

In der Partitionsübersicht sollten unsere mühsam vorbereiteten Volume Groups “vga” bzw. “vgs” und die zugehörigen Volumes “lva1” bzw. “lvs1” auftauchen. Man beachte das Symbol für Verschlüsselung. Wählen wir die grafische Darstellung (Punkt “Gerätegraphen”), so sollten wir folgende Äste im Baumdiagram sehen (dort verlaufen sie vertikal)

/dev/sda => /dev/sda3 => lvm pv => vgs => lvs1 => cr-auto-2 => swap

/dev/sda => /dev/sda4 => lvm pv => vga => lva1 => cr-auto-1 => ext4

Die genaue Laufwerks- und Mapper-Bezeichnungen hängen davon ab, ob die USB-Platte oder eine vorhandene interne Platte zuerst gezogen wird. Wir sehen, dass der “Partitioner” automatisch Bezeichnungen für die entschlüsselten Devices unter “/dev/mapper” vergibt. Die sind allerdings nicht besonders aussagekräftig – wir würden das für den späteren Betrieb gerne ändern. Außerdem müssen wir dafür sorgen, dass die Laufwerke gemäß ihres Zweckes (“/”-Filesystem, Swap) gemountet werden.

Sollten wir die geöffneten Volumes noch nicht mit einem Filesystem versehen haben, so ist ein Mounten nicht ohne Formatierung möglich, wie ein
versuchsweiser Klick auf “lva1” im linken Seitenbereich zeigt. Das Dumme dabei ist, dass YaSTs Partitioner dann auch gleich noch eine neue Verschlüsselung mit eigenen Parametern vornehmen will. Um das zu vermeiden, müssen wir die Formatierung (Erstellung der Filesysteme) in einem Terminal manuell vornehmen.

Schritt 2: “/etc/crypttab” anlegen – und Plattendaten neu einlesen lassen

Sollten wir die Volumes – wie im letzten Beitrag besprochen – bereits formatiert sein, so müssen wir dennoch vorab die mapper-Namen ändern. Die Zuordnung kryptierter Devices zu bestimmten Mapper-Bezeichnungen erfolgt u.a. über eine Datei “/etc/crypttab“, die u.a. im Zuge des Boot-Vorgangs ausgelesen wird. Wir hoffen darauf, dass auch der Opensuse-Installer bzw. YaSTs Partitioner die Existenz einer solchen Datei in der Installationsumgebung ernst nehmen. Die Installationsumgebung weist selbstverständlich ein eigenes Filesystem mit Verzeichnissen auf. Diesen Verzeichnisbaum sollte man nicht verwechseln mit dem des späteren “/”-FS für das zu installierende Leap-System.

In jedem Fall wird es Zeit, in ein Konsolen-Terminal mit freiem Prompt zu wechseln. Wir tun dies mit “Ctrl-Alt-F2” oder “Ctrl-Alt-F5”. Hier führen wir nun drei Schritte durch:

  • Schritt A: Anlegen einer Datei “/etc/crypttab“. Als Inhalt dient im Moment genau eine Zeile:
    cr-root /dev/vga/lva1 none
    (siehe dazu die man-Seiten). Wer hier gegenüber potentiellen Angreifern ein wenig “Obfuscation” betreiben will, kann natürlich auch eine andere Bezeichnung für das Mapping wählen. Viel hilft das aber nicht …
  • Schritt B: Es schadet nicht, die Volumes neu zu formatieren. Das geht im jetzigen Zustand mit
    mkfs.ext4 /dev/mapper/cr-auto-1
    mkswap /dev/mapper/cr-auto-2

    Achtung: Die UUID, die danach unter “lsblk -o name,UUID” für “cr-auto-1” angezeigt wird, merken wir uns für eine spätere Prüfung des Eintrags in der “/etc/fstab”: 

    linux-...:~ # lsblk -o name,UUID
NAME          UUID
sda           
├─sda1        
├─sda2          2F3CD-7D21
├─sda3          UUID-Sequenz 
│ └─vgs-lvs1    d6bcf6fb-641c-4238-4f55-bc677d22d245
│   └─cr-auto-2 663e1134-ab5d-3aac-bb6f-d45b7b1f34dc
├─sda4          UUID-Sequenz
│ └─vga-lva1    db43615a-23e2-5125-49c1-ccbc2041e76c
│   └─cr-auto-1 a3202dac-a44e-4344-b551-dd123ce893b2
├─sda5         UUID-Sequenz
├─sda6         UUID-Sequenz
├─sda7         UUID-Sequenz
└─sda8        
sr0           
linux-...:~ #

    Dabei ist die mapper-Bezeichnung zu wählen, die uns vorher im Gerätegraphen (s.o.) oder über “ls -la /dev/mapper” angezeigt wurde.

  • Schritt C: Wichtig: Wir schließen die entschlüsselten Devices.
    cryptsetup close cr-auto-1
    cryptsetup close cr-auto-2

Wer sich an dieser Stelle darüber wundert, dass wir das SWAP-Device nicht eingetragen haben: Wir verzichten im ersten Anlauf auf jegliche Einbindung des SWAPs (s.u.).
Man beachte:

  • Die UUID für das “/”-Filesystem ist dem geöffneten, gemappten Device (/dev/mapper/cr-auto-1 und später /dev/mapper/cr-root) zugeordnet.
  • Die sog. Crypto-UUID ist bei LUKS on LVM dagegen diejenige UUID, die dem (Raw-) Volume /dev/vga/lva1 ( = /dev/mapper/vga-lva1) zugeordnet ist.

Danach wechseln wir mit “Ctrl-Alt-F7” zurück auf die graphische Konsole. Im Übersichtsbild wechseln wir links zur höchsten Hierarchie-Ebene und
machen dann rechts den Button “Geräte erneut absuchen” ausfindig. Ein Klick führt zum erneuten Einlesen aller erkannten Devices. Wir werden wiederum nach den Passphrases für die LUKS-Volumes gefragt. Wir sehen uns dann die neue Situation im “Gerätegraphen” an:

Es kann sein, dass für das Swap-Verzeichnis nun ein neuer Name vergeben wurde.

Aber – wie wir an der Bezeichnung “cr-root” erkennen: Die in der Umgebung des Installers etablierte Datei “/etc/crypttab” wirkt tatsächlich – zumindest an dieser Stelle. Das bedeutet leider nicht, dass dieselbe “/etc/crypttab”, die wir im vorläufigen Dateisystem des Installers erzeugt haben, später auch bei Erzeugung des initramfs verwendet werden wird. Dazu müsste der Installer die vorhandene “/etc/crypttab” aus seiner Filesystem-Umgebung in das erst noch zu füllende spätere “/”-FS kopieren. Tut er aber nicht, solange wir im Partitioner nicht eine Neu-Verschlüsselung anfordern!

Schritt 3: Mount-Verzeichnis “/” zuordnen

Das erkannte File-System erlaubt nun eine Zuordnung von Mount-Verzeichnissen ohne Neuanforderung einer Verschlüsselung. Man klicke im Partitioner auf den Button zur Bearbeitung von “lva1”:

Wir ordnen im Moment nur das Filesystem auf dem LUKS-Volume “lva1” einem Verzeichnis (“/”) zu. Das als Swap formatierte Volume “lvs1” lassen wir außen vor; d.h. wir führen die Installation so aus, dass das System erstmal gar keinen SWAP nutzt. Begründet ist das in der Erfahrung, dass der Installer die Konfiguration eines vorab kryptierten Swap-Volumes nicht sauber abwickelt. Für ein erstes Booten nach der Installation ist ein SWAP aber auch nicht nötig; wir können den SWAP später immer noch einrichten.

Schritt 4: Entfernen des resume-Parameters für den Kernel

Nach dem Verlassen des Partitioners durchlaufen wir ein paar Standardschritte zur Festlegung der Zeitzone, zur Anlage eines Users und zur Festlegung des Root-Passwortes. Dann hat der Installer alle Informationen, um die Installation der Verzeichnisse samt benötigter Distributionsprogramme im vorgesehenen “/”-FS vorzunehmen. Er fasst die Installationsvorgaben vorab nochmal zusammen:

Ein Problem ist nun, dass die für die Grub2-Konfiguration vorgesehenen Kernel-Parameter (trotz fehlenden SWAP-Mounts) einen resume-Eintrag mit Verweis auf die UUID des SWAP-Bereichs beinhalten – obwohl wir das SWAP-Volume nicht gemountet haben und auch keinen Eintrag in der “/etc/crypttab” vorgesehen hatten. Vor allem letzteres würde beim Booten des installierten OS zu Problemen führen. Hat man zuvor auch mal den Partitioner manuell verlassen und wieder betreten, so kann es ferner sein, dass es inzwischen Doppeleinträge für die Kernel-Parameter gibt. Wir müssen also die Grub2-Konfiguration bereinigen und klicken deshalb auf den Punkt “Systemstart” der Zusammenfassung.

Nach einem Wechsel zum Reiter “Kernelparameter” reduzieren wir die Parameter der Kernel-Befehlszeile auf folgende Einträge:

Danach bestätigen wir die Bootloader-Konfiguration und landen wieder im Bildschirm mit der Zusammenfassung für die Installation. Wer noch mag, kann dort noch einen unkomplizierten SSH-Zugang sichern und Firewall-Themen auf später verschieben. Nun lassen wir den Installer werkeln und die üblichen Schritte zum Kopien der benötigten Systemdateien in das künftige “/”-Filesystem durchlaufen.
Hinweis: Der SuSE-Installer führt dazu einen Mount des Devices /dev/mapper/cr-root auf das Verzeichnis “/mnt” der Installationsumgebung durch.

Schritt 5: Anlage der Datei “/etc/crypttab” // Check und Bereinigung der Datei /etc/fstab im vorgesehenen “/”-FS

Während der Installer seine 1.8 GB an Files von der DVD auf die SSD schreibt, nutzen wir die Zeit für einen wichtigen Schritt:

Wir wechseln mit Ctrl-Alt-F2 wieder zu einem Terminal. Dort checken wir mittels des “mount”-Kommandos, auf welches Verzeichnis der Installer unser Device “/dev/mapper/cr-root” zur Installation aller Dateien gemountet hat. Das ist typischerweise “/mnt”. Dann prüfen wir mit

ls -la /mnt/etc | grep crypttab
cat /mnt/etc/crypttab
cat /mnt/etc/fstab

ab, ob überhaupt eine “crypttab”-Datei im “/”-FS erzeugt wurde. Bei mir war das regelmäßig nicht der Fall – auch nicht, wenn ich sie in der Installer-Umgebung (dort unter /etc/crypttab) angelegt hatte. Ist die Datei unter “/mnt/etc” tatsächlich nicht vorhanden, legen wir sie – also “/etc/crypttab” – mittels des “vi”-Editors an. Als Inhalt schreiben wir (wie oben):

cr-root    /dev/vga/lva1    none

Hinweise: “none” bedeutet hier, dass kein Key-File benutzt werden soll und auch kein explizites Passwort übergeben wird. Die LUKS-Version 1, die wir für Zugriffe des GRUB2-Boot-Managers zwingend benötigen, wird automatisch gewählt. Wir hätten aber auch explizit “cr-root /dev/vga/lva1 none luks” schreiben können. Siehe hierzu:
man crypttab

Wir könnten hier auch mit Crypto-UUIDs arbeiten; das sind die UUIDs, die direkt den Raw-LVM-Volumes (s. den Output von lsblk weiter oben und unten) zugeordnet sind. Das Arbeiten mit diesen UUIDs ist aber gar nicht nötig. Ein Blick in die später im “/”-FS des neu installierten Systems erzeugten “/boot/grub2/grub.cfg” zeigt, dass dort auch Einträge mit Verweisen auf die Devices unter “/dev/mapper” für Kernel-Parameter erzeugt werden. Der Verweis auf den “/dev”- oder “/dev/mapper”-Pfad für das LVM-Volume ist ausreichend, da die LVM-Kernel-Module diese Devices damit für Grub2 wie auch für den Kernel im Fall von “LUKS on LVM” eindeutig identifizieren können. Die richtigen Einstellungen für das initramfs und systemd durch dracut erfordern aber zwingend die Existenz der Datei “/etc/crypttab” in dem künftigen “/”-FS.

Die “/etc/fstab” bereinigen wir um ggf. vorhandenen Doppeleinträge. Der bislang einzige Eintrag dort sollte folgende Form haben

linux-xxx :~ # cat /mnt/etc/fstab
UUID=a3202dac-a44e-4344-b551-dd123ce893b2    /    ext4    acl,user_xattr    0 1

Entscheidend ist die UUID-Nr. Sie muss identisch mit der sein, die auch das Kommando “lsblk -o name,UUID” für cr-root anzeigt! Bei den Partitionen, die wir angelegt hatten, sollte sich in etwa folgendes Bild ergeben:

linux-...:~ # lsblk -o name,UUID
NAME            UUID
sda           
├─sda1        
├─sda2          2F3CD-7D21
├─sda3          UUID-Sequenz 
│ └─vgs-lvs1    d6bcf6fb-
641c-4238-4f55-bc677d22d245
│   └─cr-auto-3 663e1134-ab5d-3aac-bb6f-d45b7b1f34dc
├─sda4          UUID-Sequenz
│ └─vga-lva1    db43615a-23e2-5125-49c1-ccbc2041e76c
│   └─cr-root   a3202dac-a44e-4344-b551-dd123ce893b2
├─....
sr0           
linux-...:~ #

Hinweise: Die abgebildeten UUIDs sind natürlich erfunden und konsistent zu früheren Angaben gehalten.

Für diese Schritte ist genügend Zeit vorhanden, wenn wir von DVD installieren. Man kann ja immer mal wieder einen Blick auf das grafische Terminal mit der Fortschrittsanzeige werfen.

Schritt 6: Abschluss der Installation – Check des initramfs

Nachdem wir sicher sind, dass die “/etc/crypttab” sich (vor Durchführung von chroot und mkinitrd am Ende des Installationsprozesses) im künftigen “/”-FS befindet, warten wir in Ruhe die letzten Schritte der Installation ab.

Danach halten wir den laufenden Reboot-Prozess an und wechseln wieder auf eine Textkonsole. Dort untersuchen wir das “/”-FS. Vorab prüfen wir mittels des “mount”-Kommandos, ob unser “/dev/mapper/cr-root” noch auf “/mnt” eingehängt ist. Evtl. ist es notwendig, das Crypto-Device mit “cryptsetup open” als “cr-root” zu öffnen und dann “/dev/mapper/cr-root” auf “/mnt” zu mounten. Dann prüfen wir mit

lsinitrd /mnt/boot/initrd | less

oder

lsinitrd /mnt/boot/initrd -f /etc/crypttab

ab, ob dort eine Datei “/etc/crypttab” existiert. Wenn nicht, ist etwas schiefgegangen. Man muss dann aber nicht verzweifeln. Im nächsten Artikel zeige ich, wie man das Ganze nach einem fehlgeschlagenen Bootvorgang noch hinbekommt – ohne die gesamte Installation zu wiederholen.

Ich bin aber optimistisch, dass der nun eingeleitete Bootprozess auch bei euch erfolgreich ablaufen wird und folgende Phasen aufweist:

  1. Wir rufen das Boot-Menü auf (bei mir über F11).
  2. Wir werden von Grub2 nach der Passphrase für das Root-Volume (UUID: db43615a-23e2-5125-49c1-ccbc2041e76c) gefragt.
  3. Wir erhalten nach einigen Sekunden (bei mir ca. 6 Sek. wegen der relativ hohen Anzahl an PBKDF2-Iterationen!) ein graphisches Grub-Menu und wählen dort “Openuse Leap 15”
  4. Wiederum nach einer kurzen Pause (Laden des Kernels und initramfs; Start des speziellen systemd) werden wir erneut nach dem Passphrase für das “/”-FS gefragt.
  5. Das System bootet und wir landen am Prompt einer Login-Shell der Textkonsole.

Läuft der Boot so ab: Glückwunsch – ihr habt erfolgreich ein Opensuse Leap 15 System mit LUKS on LVM installiert und gebootet.

Sollte das bei euch nicht so ablaufen, sollten statt dessen wiederkehrende Fehlermeldungen auftauchen und nach vielen Wiederholungen der Prompt einer Dracut-Emergency-Shell erscheinen, so ist bei euch die “/etc/crypttab” nicht an richtiger Stelle angelegt worden. Das müssen wir dann manuell korrigieren. Dazu mehr im nächsten Artikel:

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart

Bis dahin wünsche ich allen Lesern: Frohe
Weihnachten!

Links

proper-manual-os-setup-on-luks-encrypted-drive-with-non-aes-algorithm-on-yum-bas
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption

Dracut-Grundlagen
https://wiki.gentoo.org/wiki/Dracut
https://en.wikipedia.org/wiki/Dracut_(software)

Dracut, crypt-Module, systemd und Infos in der grub.cfg
https://lists.opensuse.org / opensuse / 2017-08 / msg00211.html
https://bugzilla.opensuse.org/show_bug.cgi?id=904987 !!!!
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption
https://github.com/systemd/systemd/issues/6381
http://man7.org/linux/man-pages/man8/dracut.8.html

Dracut Recovery
https://exebit.wordpress.com/2015/11/20/centos-7-dracut-boot-recovery/