LV in LUKS-Partition fehlt in /dev/mapper - Unterschied Debian 12 vs. Ubuntu 22.04

[UnixFan]

Hallo!

Ich bin kürzlich von Kubuntu 22.04 auf Debian 12 umgestiegen.

Für Backups nutze ich über USB angeschlossene externe Platten und Sticks, die komplett mittels LUKS verschlüsselt sind, eine Partition für das ganze Gerät.
Diese LUKS-Partition ist ihrerseits mittels LVM als Physical Volume definiert und das einzige in der jeweiligen Volume Group.
Auf manchen Geräten ist darin nur ein Logical Volume definiert, auf anderen sind es mehrere LVs.

Mein Backup-Skript macht also zunächst ein

Code: Alles auswählen

sudo cryptsetup luksOpen /dev/sdc1 EXT_BACKUP

und erwartet, dass dadurch für jedes LV (dieses Geräts) ein Eintrag in /dev/mapper angelegt wird:

Code: Alles auswählen

for LV in /dev/mapper/vgBLUE-lvBLUE*
do
  sudo mount $LV /mnt
  ...
done

Das hat bisher problemlos funktioniert, tut es aber nach dem Umstieg nicht mehr: Die LV-Einträge in /dev/mapper gibt es nicht.

Was muss ich (bei Debian 12) ergänzen, damit die LVs als Block Device sichtbar werden und ein Mount möglich wird?

Danke für alle Tipps!
Jörg

[rhHeini]

Versuchs mal mit einem

Code: Alles auswählen

# vgchange -a y

Aus https://tldp.org/HOWTO/LVM-HOWTO/activatevgs.html

[UnixFan]

Hallo!

Das hatte ich nicht gefunden - danke.

Es benimmt sich etwas komisch: Der Aufruf

Code: Alles auswählen

sudo vgchange -a y vgBLUE

bei nicht-geöffneter LUKS-Partition führt zur Meldung

Code: Alles auswählen

Volume group "vgBLUE" not found
Cannot process volume group vgBLUE

(was für mich nach einem Scheitern aussieht, ohne "luksOpen" durchaus akzeptabel), aber wenn ich dann das "luksOpen" nachhole, dann zeigt anschließend ein "ls /dev/mapper/" das bisher vermisste LV.
Sieht also erfolgreich aus - danke!

Jetzt muss ich nur noch rauskriegen, wie sich ein Reboot auf diese Einstellung auswirkt, ob ich das Kommando ins Skript aufnehmen sollte oder ob Auto-Activation die einfachere Lösung ist.

Zum Unterschied zwischen Kubuntu und Debian: Es sieht so aus, als ob udev-Regeln da beteiligt wären, und die können ja durchaus variieren.

Viele Grüße
Jörg

[UnixFan]

Hallo!

Das im vorigen Beitrag beschriebene komische Verhalten nehme ich zurück, ich konnte es nicht mehr beobachten.
Jetzt habe ich das "sudo vgchange -a y vgBLUE" in mein Skript eingebaut, und es funktioniert.
Ist halt schade, dass ich das nun für jedes Medium machen muss - wahrscheinlich brauche ich eine Liste von "blkid" des Mediums und Namen der VG, aber das ist ja machbar.
Oder ich forsche noch mehr zu Auto-Activation.

Nochmals Danke!
Jörg

[Livingston]

Wenn Du alle Volume Groups auf einmal aktivieren möchtest, geht auch ein

Code: Alles auswählen

vgchange -a ay

(Man beachte das a vor dem y.)
Geht natürlich nur nach dem Öffnen des LUKS-Device.
Ansonsten: vgs listet Dir alle Volume-Gruppen, lvs listet alle Logical Volumes. Ein Blick in die man-pages lohnt sich.

[UnixFan]

Ja, das "ay" bei "vgchange" habe ich gesehen - "auto-activation".

Ein generelles "vgchange" ohne Angabe der VG ist mir nicht so recht sympathisch, weil ich im normalen Betrieb schon mit zwei VGs arbeite: Mein System ist vollverschlüsselt (bis auf /boot, wie üblich), und die zweite Platte hat ihre eigene VG.
Aber Dein Tipp mit "vgs" hilft, da wird die neue VG nämlich nach dem "luksOpen" schon vor der Aktivierung aufgeführt, während sie in "/dev" erst nach der Aktivierung auftaucht. (Das war mein erster Versuch.)
Da muss ich nur die Ausgabe etwas aufbereiten, dann habe ich den Namen der VG schön isoliert.

Zum Thema man-Pages: Ja, da bin ich auch sehr dafür, aber hier fehlte mir der Einstiegspunkt.

Danke!
Jörg

[UnixFan]

Nochmals hallo!

Die Tipps mit "vgs" und "lvs" waren sehr hilfreich, das Skript ist jetzt viel sauberer.
Danke!

Jörg

[Livingston]

Yeah, freut mich

Auch ein
Jörg
(Man darf aber auch Jørch schreiben.)