["gelöst"] Luks LVM mit zweiter Volumegroup startet seit Upgrade auf Bookworm nicht mehr

[san04]

Hallo zusammen,

ich habe hier gerade einen Rechner, der seit dem Upgrade auf Bookworm nicht mehr startet, bzw. nur das initramfs.

Der Start des Systems sieht aktuell wie folgt aus (gekürzt):

Code: Alles auswählen

Please unlock disk sda3_crypt: ***************************
cryptsetup: sda3_crypt: set up successfully
Gave up waiting for suspend/resume device
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
-Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/user--desktop--vg-root does not exist. Dropping to a shell!
Busybox v1.35.0 (Debian 1:1.35.0-4+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs)

Vor vielen Jahren habe ich ihn vollverschlüsselt (ohne boot) mit LUKS und LVM aufgesetzt. Als irgendwann der Speicherplatz knapp wurde, habe ich die Partition einer HDD mit in die Volumegroup (VG) aufgenommen. (würde ich heute nicht mehr so machen aber zur damaligen Zeit erschien mir das irgendwie sinnvoll, um alles mit einem Passwort ohne Klartext-Sicherung zu starten).

Hier mal ein paar auf das wesentliche gekürzte Auszüge des Systems. Das System liegt auf sda3, das zweite PV auf sdb4

Code: Alles auswählen

$ lsblk -f
NAME FSTYPE FSVER LABEL  UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                            
├─sda1
│    vfat   FAT32        30A8-C95C                               502,3M     2% /boot/efi
├─sda2
│    ext2   1.0          c543eb4f-c8e7-4610-97bb-729478d184ce    138,6M    36% /boot
├─sda3
│    crypto 1            4bd94948-abb8-45a4-b661-c3334b7db545                  
│ └─sda3_crypt
│    LVM2_m LVM2         aUfnCp-ipwX-HIqZ-KweQ-3kkC-c1cI-vYsy6Y                
│   ├─user--desktop--vg-root
│   │  ext4   1.0          1020bef7-4988-407d-910b-4a6a53a76d37     39,6G    78% /
│   └─user--desktop--vg-swap_1

sdb                                                                                            
├─sdb4
│    crypto 1            77ffaa74-2718-4d85-8671-2da802ff163e                  
│ └─crypt
│    LVM2_m LVM2         b6l5Ux-HLjs-4MN7-pd55-Bjdo-QPgm-CehhkP                
│   └─user--desktop--vg-bilder
│      ext4   1.0          9ca66e96-44b6-40cd-bede-7dd17183ab60       87G    76% /home/user/Bilder

Code: Alles auswählen

$ sudo pvs
  PV                     VG                 Fmt  Attr PSize    PFree
  /dev/mapper/crypt      user-desktop-vg lvm2 a--  <465,66g    0 
  /dev/mapper/sda3_crypt user-desktop-vg lvm2 a--  <255,43g    0 

$ sudo lvs
  LV     VG                 Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  bilder user-desktop-vg -wi-ao---- <465,66g                                                    
  root   user-desktop-vg -wi-ao----  239,49g                                                    
  swap_1 user-desktop-vg -wi-ao----  <15,94g        
  
$ sudo vgs
  VG                 #PV #LV #SN Attr   VSize    VFree
  user-desktop-vg   2   3   0 wz--n- <721,09g    0 
  

In der Crypttab und fstab finden sich u.a. diese Zeilen

Code: Alles auswählen

$ cat /etc/crypttab 
sda3_crypt UUID=4bd94948-abb8-45a4-b661-c3334b7db545 none luks
bilder UUID=77ffaa74-2718-4d85-8671-2da802ff163e /root/keyfile luks

$ cat /etc/fstab
# Bilder Partition hinzufügen ME 12/15
/dev/mapper/user--desktop--vg-root /               ext4    errors=remount-ro 0       1
UUID=c543eb4f-c8e7-4610-97bb-729478d184ce /boot           ext2    defaults        0       2
UUID=30A8-C95C  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/user--desktop--vg-swap_1 none            swap    sw              0       0
/dev/mapper/user--desktop--vg-bilder /home/user/Bilder               ext4    user,defaults 0       2

und das keyfile existiert nach wie vor

Code: Alles auswählen

sudo ls -lah /root/keyfile
-r-------- 1 root root 4,0K  4. Dez 2015  /root/keyfile

Laut Luks-Header sind zwei Key Slots belegt (Passwort+Keyfile):

Code: Alles auswählen

$ sudo cryptsetup luksDump /dev/sdb4
LUKS header information for /dev/sdb4
Key Slot 0: ENABLED
...
Key Slot 1: ENABLED

Einen Defekt schließe ich aus, da ich das System aus dem Initramfs booten kann, wenn ich

Code: Alles auswählen

cryptsetup luksOpen /dev/sdb4 crypt
vgchange -ay

händisch ausführe.

Offenbar hängt es an der Entschlüsselung oder der Aktivierung der VG im automatischen Boot-Vorgang. Das initramfs habe ich neu gebaut, wie könnte ich das Problem besser einkreisen bzw. wo liegt der Fehler?

[san04]

Leider komme ich hier nicht weiter.

Ich hatte im Kopf, dass identische Passwörter für die beiden Partitionen dann auch zur Bootzeit dazu führen, dass beide entschlüsselt werden. Daher habe ich das alte Passwort von sdb4 in Keyslot 2 verschoben und ein identisches Passwort zu dem ersten PV (sda3) in Keyslot 0 der sdb4 gesetzt. Ändert aber nichts, ich muss wie gehabt manuell sdb4 mit dem Passwort entschlüsseln und die VG aktivieren um zu booten.

Vielleicht hat ja noch jemand eine Idee?

[san04]

Bei genauerer Betrachtung ist mir aufgefallen, dass das System wohl nur gebootet hat, weil beide LUKS-Partitionen mit demselben Passwort verschlüsselt waren. Das Keyfile ist ja erst nach Aktivierung der Volume-Gruppe verfügbar.
Warum es nun trotzdem nicht mehr so klappt ist mir immer noch unklar.

Mein Ziel war jetzt eigentlich die Partition zu erhalten und nur aus dem LVM herauszulösen. Dafür habe ich folgende Befehle ausgeführt

Code: Alles auswählen

lvremove /dev/user-desktop-vg/bilder
vgreduce user-desktop-vg /dev/mapper/bilder

Anschließend wollte ich das das PV auch noch entfernen und das geht wohl nicht ohne Datenverlust:

Code: Alles auswählen

pvremove /dev/mapper/bilder

Danach war alles futsch und auch ein wieder anlegen half nicht, um das PV nochmal zu aktivieren.

Also habe ich einen neuen LUKS-Container angelegt, in crypttab und fstab eingetragen und das Backup dorthin kopiert. So erscheint mir das Setup nun auch etwas logischer und ich kann leichter booten, falls die zweite Festplatte tatsächlich mal ausfällt, da sie nicht mehr im LVM hängt.

Ob/wie man das LVM auflösen kann ohne die Daten zu verlieren habe ich noch nicht weiter recherchiert. Mein Problem ist damit zwar nicht gelöst, aber umgangen...