OS 42.1: Kein Hochfahren mehr möglich mit LVM-Vollverschlüsselung

Sendbote · 13 Apr. 2016

Lange hatte ich auf Opensuse Leap 42.1 gewartet. Eine vorhergehende Installation von OS 13.1 mit einem verschlüsselten Homeverzeichnis auf einem Desktop-Rechner funktionierte zunächst, dann blieb der Rechner aber nach der Eingabe des Passwortes hängen. Also arbeitete ich wieder mit meinem alten Notebook, wartete auf 42.1 und installierte es vollverschlüsselt mit LVM (Systempartition mit btrfs und die Homepartion mit xfs). Das lief einige Wochen gut. Dann gelangte ich nicht mehr auf die KDE-Oberfläche:

Could not start kdeinit5. check your installation.

Nach einiger Recherche konnte ich zwar nicht das zugrunde liegende Problem beheben, konnte aber zumindest über Yast2 und durch

Code:

# snapper rollback 42

den früheren Zustand 42 des Systems, zu dem es noch lief, wieder herstellen.

Danach ging es einige Tage gut, das An- und Abmelden funktionierte. Nun bootet der Desktop-Rechner seit mehr als drei Wochen nicht mehr. Der Rechner bleibt wohl in einer Endlosschleife stecken. Mit Strg + Alt + F2 geht es nicht mehr, wie das bei dem oben geschilderten Problem noch möglich war, in eine Konsole weiter.
Mit Alt + Tab konnte ich folgende Meldung abrufen (gekürzt, da ich nicht die volle Ausgabe manuell erfassen wollte):

Code:

[ OK ] Started Show Plymouth Boot Screen.
[ OK ] Reached Target Paths.
[ OK ] Found device ST5 ...
[ OK ] Found device ...
[ OK ] Found device ...
Starting Cryptograhy Setup for  ... ST5 ...
[ OK ] Found device LVM.

[ OK ] Reached Basic System.
...
[ OK ] Reached target Remote File Systems.
[ OK ] Started dracut pre-mount hook.

Ein Bildschirmfoto zu diesem Problem lieferte bonedriven am 24. März 2016 im opensuseforum. Auch er installierte Leap 42.1 mit LVM-verschlüsselung:

https://forums.opensuse.org/showthread.php/516726-Can-t-boot-after-a-system-update

Mittlerweile behelfe ich mir wieder mit meinem alten Notebook. (Auf ihm lief über zwei Jahre Opensuse 13.1 recht stabil, mit ihm bekomme ich aber nun auch Probleme). Ich würde gerne den Desktop-Rechner wieder starten können ohne eine langwierige Neuinstallation. Falls ein Hardwarefehler vorliegt, erwäge ich einen neuen Rechner zu kaufen. Eine Neuinstallation wäre schließlich auch eine Option, wenn ich wüsste, dass kein Hardware- sondern ein Software- bzw. Konfigurationsproblem vorliegt. Ich habe nun mit einer Linux Mint Live CD gebootet und mit ihr die folgenden beiden Befehle abgerufen:

Ausgabe von # fdisk -lu und $ lsblk von einer Konsole des Linux Mint Live Systems:

Code:

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x233c9c8e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   143362047    71680000    7  HPFS/NTFS/exFAT
/dev/sda2   *   143362048   976773119   416705536    5  Extended
/dev/sda5       889712640   971651071    40969216   8e  Linux LVM
/dev/sda6       971655168   976773119     2558976   82  Linux swap / Solaris
/dev/sda7       143364096   144166911      401408   83  Linux
/dev/sda8       144168960   889712639   372771840   8e  Linux LVM

Partition table entries are not in disk order

Disk /dev/sdg: 4041 MB, 4041211904 bytes
81 heads, 37 sectors/track, 2633 cylinders, total 7892992 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4e67e3ec

   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1            2048     7892991     3945472    b  W95 FAT32

Code:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
├─sda1   8:1    0  68.4G  0 part 
├─sda2   8:2    0     1K  0 part 
├─sda5   8:5    0  39.1G  0 part 
├─sda6   8:6    0   2.5G  0 part [SWAP]
├─sda7   8:7    0   392M  0 part 
└─sda8   8:8    0 355.5G  0 part 
sdg      8:96   1   3.8G  0 disk 
└─sdg1   8:97   1   3.8G  0 part /media/mint/P4
sr0     11:0    1   1.2G  0 rom  /cdrom
loop0    7:0    0   1.1G  1 loop /rofs

Ich bin davon ausgegangen, dass eine Komplett-Verschlüsselung auf LVM-Basis sicherer ist als die alleinige Verschlüsselung des Homeverzeichnisses und auch "störungsfrei" machbar sei. Oder ist sie doch nur etwas für Experten?

Sollte man vor der LVM-Verschlüsselung eine seperate unverschlüsselte /boot-Partition anlegen? (Darüber gibt nach meinen Recherchen unterschiedliche Meinungen).

Ist es weniger störanfällig vor - also nicht bei - der Installation die Partitionen, in die man installieren will, zu verschlüsseln?

Muss bei LVM-Verschlüsselung (mindestens) noch ein zusätzliches Modul in /boot/grub installiert / hineinkopiert werden?

Wie kann ich Opensuse 42.1 auf dem Desktop-Rechner wieder starten?

Über Antworten würde ich mich freuen.

Gruß Sendbote

gehrke · 13 Apr. 2016

Sendbote schrieb:
Ich bin davon ausgegangen, dass eine Komplett-Verschlüsselung auf LVM-Basis sicherer ist als die alleinige Verschlüsselung des Homeverzeichnisses und auch "störungsfrei" machbar sei. Oder ist sie doch nur etwas für Experten?

Ich bin der Meinung, dass eine sogenannte 'Vollverschlüsselung' mit LUKS und LVM sicherer ist und sie lässt sich nach meiner 10 jährigen Erfahrung mit unterschiedlichen Linux-Distributionen genauso problemlos oder problembehaftet betreiben wie ohne. Allerdings hilft es, wenn man im Notfall weiß, wie man das LUKS-Device auf der Konsole öffnen kann - aber das ist an tausend Stellen wohl dokumentiert und kein Hexenwerk.

Sendbote schrieb:
Sollte man vor der LVM-Verschlüsselung eine seperate unverschlüsselte /boot-Partition anlegen? (Darüber gibt nach meinen Recherchen unterschiedliche Meinungen).

AFAIK muss man das sogar machen, weil man einen unverschlüsselten Bereich braucht, um den Code aufzunehmen, der für die Basics und die Entschlüsselung notwendig ist (also Kernel, InitRAM, GRUB...). Ist übrigens auch eine gewisse Schwäche dieses Systems.

Sendbote schrieb:
Ist es weniger störanfällig vor - also nicht bei - der Installation die Partitionen, in die man installieren will, zu verschlüsseln?

Ich habe kein Leap, aber so ziemlich alle openSUSE-Versionen davor in den letzten Jahren haben bem Handling mit LUKS/LVM bei der Installation vorbildlich funktioniert.

gehrke · 13 Apr. 2016

Vielleicht mal ein oder zwei Schritte zurück. Warum glaubst Du, dass LUKS/LVM mit Deinem Problem etwas zu tun haben? Glaubst Du das überhaupt?

Ich würde mal versuchen, in den Runlevel 3 zu starten, also ohne Grafik.

Auch interessant sollten die Logs des Systems sein, ansonsten ist das reines Raten. Falls Du das System nicht selbst gestartet kriegst, könntest Du die erwähnte Mint-Live verwenden, um zu booten und die Logs auszulesen.

Sendbote · 14 Apr. 2016

Hallo Gehrke, schönen Dank für deine beiden Beiträge.

Ich gehe davon aus, dass das Einrichten einer unverschlüsselten, seperaten Boot-Partition bei einem ansonsten verschlüsselten LVM-System die gängige und bessere Methode. Doch ist das zwingend erforderlich? Mit dem Booten und Abmelden hat es ja einige Wochen funktioniert, ohne dass ich eine gesonderte Boot-Partition eingerichtet habe. Nach dem Anmeldebildschirm gab ich das Passwort ein und das System startete. (Hierzu auch dieser Thread.)

Mit Strg + Alt + F2 kam ich, wie oben beschrieben, nicht in eine Konsole. Nun, wie komme ich beim Bootvorgang in den runlevel 3?
Lässt sich folgende Beschreibung auf Opensuse Leap 42.1 übertragen?

I use Tumbleweed as my main distro so I need to boot to runlevel 3 to reinstall the Nvidia driver whenever there is a kernel update. That's not as easy with Grub 2 as it was in the days of Grub 1.

Boot to the Grub graphical bootloader screen. If 12.2 is not the default entry, use the arrow keys to highlight it. (most people won't need to do this because it is usually the default)

Once you're on the openSUSE boot entry do this sequence:

1. Press the E key. An edit screen will appear.
2. Use Arrow keys to put the cursor on the line containing the following text: /boot/vmlinuz
3. Press the End key
4. Press the spacebar once (i.e. enter a space) and the 3 key (i.e. you have entered a space and a 3)
5. Press F10 and the computer will boot to runlevel 3

gehrke hat geschrieben:

Auch interessant sollten die Logs des Systems sein, ansonsten ist das reines Raten. Falls Du das System nicht selbst gestartet kriegst, könntest Du die erwähnte Mint-Live verwenden, um zu booten und die Logs auszulesen.

Mit der Mint-Live CD bin ich gestartet, weiß aber nicht, welche Logs hier relevant wären und wo diese zu finden sind.

gehrke hat geschrieben:

Vielleicht mal ein oder zwei Schritte zurück. Warum glaubst Du, dass LUKS/LVM mit Deinem Problem etwas zu tun haben? Glaubst Du das überhaupt?

Ich denke, dass es das Zusammenspiel von Hard- und Software ist. Ich hatte beispielsweise bei Opensuse 13.1 mit diesem Desktop Probleme beim Auslesen des Passwortes. Nachdem ich die Tastatur noch einmal anschloss, funktionierte es wieder - bis dann auch damit Schluss war. Dasselbe passierte mir bei 42.1. (Dies wurde auch, soweit ich mich erinnern kann, im englischen Opensuse-Forum einmal beschrieben). Wie dem auch sei, mich würde interessieren, ob die Hardware weniger geeignet ist.

Gruß Sendbote

gehrke · 14 Apr. 2016

Sendbote schrieb:
Ich gehe davon aus, dass das Einrichten einer unverschlüsselten, seperaten Boot-Partition bei einem ansonsten verschlüsselten LVM-System die gängige und bessere Methode. Doch ist das zwingend erforderlich? Mit dem Booten und Abmelden hat es ja einige Wochen funktioniert, ohne dass ich eine gesonderte Boot-Partition eingerichtet habe.

Bist Du sicher, dass Du überhaupt eine LUKS/LVM-Partitionierung hast? Bei mir ist der LUKS-Container deutlich zu erkennen:

Code:

[root@j7 ~]# lsblk
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   15G  0 disk  
├─sda1                                          8:1    0  500M  0 part  /boot
└─sda2                                          8:2    0 14,5G  0 part  
  └─luks-<xxx>                                253:0    0 14,5G  0 crypt 
    ├─fedora-root                             253:1    0    8G  0 lvm   /
    ├─fedora-swap                             253:2    0  1,5G  0 lvm   [SWAP]
    └─fedora-home                             253:3    0    5G  0 lvm   /home

Deine Partitionierung sieht mir eher nach LVM ohne LUKS aus!?! Wo befindet sich bei Dir der LUKS-Container?

Sendbote schrieb:
Nun, wie komme ich beim Bootvorgang in den runlevel 3?
Lässt sich folgende Beschreibung auf Opensuse Leap 42.1 übertragen?

[...]
4. Press the spacebar once (i.e. enter a space) and the 3 key (i.e. you have entered a space and a 3)

Zum Vergrößern anklicken....

Ja, so sollte es vermutlich gehen. Probiere es aus...

Sendbote · 14 Apr. 2016

gehrke hat geschrieben:

Bist Du sicher, dass Du überhaupt eine LUKS/LVM-Partitionierung hast?

Sicher bin ich mir nicht. Doch wie sollte das Anmelden mit Passwort sonst möglich gewesen sein?

Ich dokumentiere meine Installationen, so auch jene vom 23.11.2015. Nach der Niederschrift der Daten über die Partitionierung habe ich geschrieben:

"Einstellungen für Vorschlag bearbeiten" mit Linksklick:
- LVM-basierten Vorschlag erstellen
- Volumegruppe verschlüsseln

verschlüsseln
Passwort für Volume-Gruppe: XXX

Möglicherweise zeigt die Linux Mint Live-CD die Daten nicht so, wie sie unmittelbar von einem verschlüsselten System aus sichtbar sind.

gehrke · 14 Apr. 2016

Boote mal in Runlevel 3, dann sehen wir weiter...

Sendbote · 14 Apr. 2016

Am Montag bin ich wieder im Büro. Dann kann ich versuchen, in den Runlevel 3 zu booten. Nehmen wir einmal an, ich komme in den Runlevel 3. Was dann? Nach welchen Daten dann suchen oder welche Operationen vornehmen?

gehrke · 14 Apr. 2016

Unter Leap dürfte systemd aktiv sein. Daher wäre wohl journalctl das Mittel der Wahl...
Wobei ich davon ausgehe, dass Du dann Booten kannst. In diesem Fall dürfte die Ursache aber auch nicht bei der Verschlüsselung zu finden sein, sonst kommst Du gar nicht so weit.

Falls das nicht hilft, ist wohl die Live-Version von Mint o.ä. gefragt.

Sendbote · 15 Apr. 2016

Danke für den Hinweis. Offenbar gibt es viele Möglichkeiten, das systemd-journal oder einzelne Teile davon mit journalctl zu lesen.
Gehen wir einmal davon aus, dass ich den Befehl journalctl ausführen kann. Wonach sollte ich dann suchen?
Sollte ich sämtliche Bootvorgänge auflisten oder nur die aktuelleren? Oder gar alle Einträge durchkämmen? (Es ist zweifelhaft, dass meine Kenntnisse ausreichen, dann "auffällige" Vorgänge zu finden.)

Code:

# journalctl /usr/lib/systemd/systemd
# journalctl --list-boots
# journalctl --list-boots | grep 2016-04
# journalctl -a | less

Sendbote · 20 Apr. 2016

Mittlerweile habe auf verschiedene Weise versucht, das auf dem Desktop installierte Opensuse 42.1 Leap wieder zu starten. Die ganze Sache hat doch bisher einige Stunden in Anspruch genommen.

Der Versuch, beim Bootvorgang in den Runlevel 3 zu kommen, misslang. Die oben dargestellten fünf Schritte

...
5. Press F10 and the computer will boot to runlevel 3

konnte ich ausführen, doch dann blieb der Rechner hängen: Die kreisförmigen Elemente des grünen Startbildschirmes von OS 42.1 oszillieren, doch das Betriebssystem fährt nicht hoch.

Von der Mint Live-CD eingegeben zeigt das Kommando lsblk alleine keine Crypt-Container (siehe oben), jedoch mit den Schaltern "fs":

Code:

mint mint # lsblk --fs
NAME   FSTYPE      LABEL                     MOUNTPOINT
sda                                          
├─sda1 ntfs                                  
├─sda2                                       
├─sda5 crypto_LUKS                           
├─sda6 swap        Swap                      [SWAP]
├─sda7 ext4                                  /media/mint/9e0f0c52-c0a8-41e0-a38a-dd371cc843f1
└─sda8 crypto_LUKS                           
sr0    iso9660     Linux Mint 16 Xfce 64-bit /cdrom
loop0  squashfs                              /rofs

Auf den Manpages von lsblk lesen wir:

-f, --fs
Output info about filesystems. This option is equivalent to "-o NAME,FSTYPE,LABEL,MOUNTPOINT". The authoritative information about filesystems and raids is provided by the blkid(8) command.

Code:

mint mint # blkid | grep crypto_LUKS
/dev/sda5: UUID="01badedc-7085-4d9e-8e25-cbe0845de5d4" TYPE="crypto_LUKS" 
/dev/sda8: UUID="1a37d272-8656-4975-86d8-7daec1220e18" TYPE="crypto_LUKS"

Nun wollte ich die LVM-Laufwerke von der Mint Live-CD aus öffnen und dann einhängen.

Code:

mint mint # cryptsetup luksOpen /dev/sda5 Mothership
Enter passphrase for /dev/sda5:

Zumindest ließ sich die Passphrase eingeben.

lvscan kann aber ein Laufwerk nicht finden:

Code:

mint mint # lvscan
  Couldn't find device with uuid xl7VGL-1V64-d6e9-CS69-h5wk-OjST-FeAa5R.
  inactive          '/dev/system/home' [354.57 GiB] inherit
  inactive          '/dev/system/root' [40.00 GiB] inherit
mint mint #

In einer mir verständlichen (aber leider nicht ausreichenden) Anleitung zum Entschlüsseln, aus der ich auch obige Befehle entnommen habe, las ich, man solle erst die Attribute der logischen Laufwerke ändern:

Code:

mint mint # lvchange -a y /dev/system/root
  Couldn't find device with uuid xl7VGL-1V64-d6e9-CS69-h5wk-OjST-FeAa5R.
  Refusing activation of partial LV root. Use --partial to override.

Nun, wie soll ich den Schalter "partial" anwenden? So wohl nicht:

Code:

mint mint # lvchange -a y --partial /dev/system/root
  PARTIAL MODE. Incomplete logical volumes will be processed.
  Couldn't find device with uuid xl7VGL-1V64-d6e9-CS69-h5wk-OjST-FeAa5R.

Offenbar ist es notwendig, die uuid eines Laufwerkes zu lesen
- und das Einhängen geht nur, wenn man die Attribute vorher geändert hat:

Code:

mint mint # mkdir /mnt/crypthome
mint mint # mount /dev/sda5 /mnt/crypthome
mount: unknown filesystem type 'crypto_LUKS'

Es gibt viele Anleitungen zum Entschlüsseln von Luks-Laufwerken im Internet. Doch davon habe ich nur wenige gefunden, die ich gut nachvollziehen kann. Systemadministratoren kennen in der Regel die notwendigen Befehle. Für sie ist die Entschlüsselung kein Hexenwerk. Viele andere Nutzer kommen jedoch schnell an ihre Grenzen, insbesondere dann, wenn sie OS 42.1 noch mit xfs und btrfs installiert haben. Auf einer offiziellen Anleitung von Arch-Linux über die Voraussetzungen der Entschlüsselung ist zu lesen, man solle schon "einige Stunden" mitbringen - neben einem verschlüsseltem Dateisysetem, genügend Speicherplatz und einer Live-CD.

Nun, ob ich mich noch weitere Stunden mit der Sache befasse, wird sich zeigen. Vielleicht kann mir ja doch noch jemand von euch weiterhelfen, den Rechner wieder schneller zum Laufen zu bringen?

gehrke · 20 Apr. 2016

Das sieht mir weniger nach einem Problem mit der Entschlüsselung aus (denn das hat ja fehlerfrei funktioniert) als vielmehr mit kaputten LVM-Metadaten oder gar dem Datenträger per se. Ist Dir bekannt, welches LV hinter dieser UUID steckt? Ich vermute SWAP, was ja durchaus zu verschmerzen bzw. ohne Datenverlust wieder aufgebaut werden könnte.

So etwas hatte ich noch nie und kann daher leider keine Lösung aus dem Hut zaubern. Aber es gibt einige Treffer dazu bei Startpage. Nur: einige Zeit für die Einarbeitung wirst Du da schon mitbringen müssen...

OS 42.1: Kein Hochfahren mehr möglich mit LVM-Vollverschlüsselung

Sendbote

Member

gehrke

Administrator

gehrke

Administrator

Sendbote

Member

gehrke

Administrator

Sendbote

Member

gehrke

Administrator

Sendbote

Member

gehrke

Administrator

Sendbote

Member

Sendbote

Member

gehrke

Administrator