ubuntuusers.de

GUI-Tool "Laufwerke" war geschlossen, von dem wurde es nicht benutzt.

root@SH:~# blkid
/dev/nvme1n1p2: UUID="751c29f1-b192-47da-8e94-ca6f792164ed" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0fff225d-c0b7-470f-a5b4-e6b5999e9024"
/dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme0n1p3: UUID="79f59137-eb1d-478c-9fd5-4ca5fe762f55" TYPE="crypto_LUKS" PARTLABEL="System" PARTUUID="881d0d79-a2dd-465d-804f-2b124d8e52ed"
/dev/nvme0n1p1: UUID="CF71-55A9" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="28fcaa9e-2715-471c-8da7-5ac248737cdf"
/dev/nvme0n1p2: UUID="c499e5ae-3f2b-4d5a-a13b-57d0716e8a38" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a0ab9313-1e0f-40af-bf1f-2273cb35aaef"
/dev/loop8: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop6: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop4: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop2: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/mapper/luks-79f59137-eb1d-478c-9fd5-4ca5fe762f55: UUID="GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ" TYPE="LVM2_member"
/dev/loop9: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop7: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme1n1p1: UUID="8639-E43C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="23f5f805-14b9-4f04-a77d-f74bd3cea4d7"
/dev/loop5: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop3: BLOCK_SIZE="131072" TYPE="squashfs"
root@SH:~#

StephanHestermann schrieb:

root@SH:~# blkid
(...)
/dev/mapper/luks-79f59137-eb1d-478c-9fd5-4ca5fe762f55: UUID="GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ" TYPE="LVM2_member"
(...)
root@SH:~#

Da hast du nun die UUID innerhalb des verschlüsselten Laufwerks.

So wie das sich für mich aber darstellt, könntest du dir diesen ganzen Aufwand gespart haben. Diese HDD/SSD mit 500GB scheint doch noch ein bootbares OS zu enthalten. Das alte deinen Systems nämlich, wenn ich das richtig verstehe.

Also warum nicht einfach ins UEFI-BootMenu wechseln oder ins UEFI/BIOS und dort dieses 500GB-Device als Boot-Device auswählen und damit booten? Dann wirst du wieder nach der Passphrase gefragt und hast das Device offen.

StephanHestermann schrieb:

@adelaar nein

Die ganze Story:

Auf der 500GB-Partition, die ich versuche entschlüsselt zu mounten, liegt mein originales System. Bei dem habe ich - beim Versuch, die bis dato ebenfalls verschlüsselte, aber leere 1TB-Platte zu mounten - einen Fehler in der FSTAB gemacht, der dazu führte, daß sich das System beim Starten aufhängt. Zur Rettung habe ich eine Sparversion (ohne Verschlüsselung) auf der 1TB-Platte installiert und versuche nun, die kaputte FSTAB durch die (gesicherte) zuletzt funktionierende zu ersetzen. Bei der Gelegenheit will ich auch gleich in Erfahrung bringen, wie ich die 1TB-Platte, die meine Daten-Platte werden soll, korrekt einbinde. Die ist jetzt natürlich durch die "Rettungsinstallation" nicht mehr verschlüsselt, soll es aber letztendlich auch sein. Aber das ist Faust 2. Teil ...

Das wäre zu einfach

PS.

root@SH:~# cryptsetup luksOpen UUID=GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ 500GB
Gerät »UUID=GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ« existiert nicht oder Zugriff verweigert.
root@SH:~#

StephanHestermann schrieb:

PS.

root@SH:~# cryptsetup luksOpen UUID=GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ 500GB
Gerät »UUID=GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ« existiert nicht oder Zugriff verweigert.
root@SH:~#

Ist ja auch nix zum öffnen nun.

/dev/mapper/luks-79f59137-eb1d-478c-9fd5-4ca5fe762f55: UUID="GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ" TYPE="LVM2_member"

ist ein LVM-Volume

also erstmal ein

vgscan

machen. Ausgabe posten

Wenn es mit luksOpen schon aufgeschlossen wurde, dann könnte mal grobmotorisch die Device Mapper Device Nodes zum mounten durchprobieren. So etwa:

sudo mount -v /dev/dm-0 /mnt

Bei mehreren verschlüsselten Partitonen können das auch /dev/dm-1, /dev/dm-2, und so weiter sein.

@adelaar

root@SH:~# vgscan
  Found volume group "ubuntu-vg" using metadata type lvm2
root@SH:~#

@trollsportverein

root@SH:~# sudo mount -v /dev/dm-0 /mnt
mount: /mnt: unbekannter Dateisystemtyp „LVM2_member“.
       dmesg(1) may have more information after failed mount system call.
root@SH:~# 

Spezialgerät dm-1 und dm-2 nicht vorhanden

StephanHestermann schrieb:

  Found volume group "ubuntu-vg" using metadata type lvm2

Dann gehts weiter mit

vgchange -ay ubuntu-vg

und wenn das erfolgreich war mit

lvs

Ausgaben ebenfalls posten

root@SH:~# vgchange -ay ubuntu-vg
  1 logical volume(s) in volume group "ubuntu-vg" now active
root@SH:~# lvs
  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ubuntu-lv ubuntu-vg -wi-a----- 462,69g                                                    
root@SH:~#

Dann mach nun nochmal ein

blkid

Und poste die Ausgabe

root@SH:~# blkid
/dev/nvme1n1p2: UUID="751c29f1-b192-47da-8e94-ca6f792164ed" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0fff225d-c0b7-470f-a5b4-e6b5999e9024"
/dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme0n1p3: UUID="79f59137-eb1d-478c-9fd5-4ca5fe762f55" TYPE="crypto_LUKS" PARTLABEL="System" PARTUUID="881d0d79-a2dd-465d-804f-2b124d8e52ed"
/dev/nvme0n1p1: UUID="CF71-55A9" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="28fcaa9e-2715-471c-8da7-5ac248737cdf"
/dev/nvme0n1p2: UUID="c499e5ae-3f2b-4d5a-a13b-57d0716e8a38" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a0ab9313-1e0f-40af-bf1f-2273cb35aaef"
/dev/loop8: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop6: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop4: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop2: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/mapper/luks-79f59137-eb1d-478c-9fd5-4ca5fe762f55: UUID="GaQPft-jWIN-d3MZ-4KjK-VugG-mcnR-0nbTlJ" TYPE="LVM2_member"
/dev/loop9: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop7: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme1n1p1: UUID="8639-E43C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="23f5f805-14b9-4f04-a77d-f74bd3cea4d7"
/dev/loop5: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop3: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/mapper/ubuntu--vg-ubuntu--lv: UUID="19ca7a98-0349-4aeb-b0d3-b22581535531" BLOCK_SIZE="4096" TYPE="ext4"
root@SH:~# 

StephanHestermann schrieb:

root@SH:~# blkid
(...)
/dev/mapper/ubuntu--vg-ubuntu--lv: UUID="19ca7a98-0349-4aeb-b0d3-b22581535531" BLOCK_SIZE="4096" TYPE="ext4"
root@SH:~# 

Bingo. Nun kannst du mounten:

mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

sollte reichen. Hast nur eine Partition

Du sagst es: BINGO!

Na dann als gelöst markieren und viel Erfolg beim erneuten installieren mit korrigierter /etc/fstab

Nur mal als Zusammenfassung: Das Problem bestand demnach darin, dass das logische Volume deaktiviert war?

Denn ich muss hier keine Handstände machen, wenn ich meine LUKS-Partition öffne, mountet der LVM sofort alle Volumes darin ohne weiteres Zutun ☺

--ks

Kreuzschnabel schrieb:

Nur mal als Zusammenfassung: Das Problem bestand demnach darin, dass das logische Volume deaktiviert war?

Nun im vorliegenden Fall hat der Verfasser ja von einem anderen Laufwerk gebootet. Der SSD mit 1TB. Er hat aber auf der SSD mit 500GB ein System installiert gehabt, welches nicht mehr bootete, weil die /etc/fstab verändert wurde. Dann wird das logische Volume offenbar nicht automatisch wieder aktiviert wenn man das verschlüsselte Device entschlüsselt.

Jedenfalls erschien es ja in der Ausgabe von blkid vor dem Aktivieren mit vgchange -ay nicht.