ubuntuusers.de

Hallo, ich habe eine Sicherung einer Partition erstellt, die mit LUKS verschlüsselt ist. Wenn ich nun das Image einbinden will nach der Anleitung im Wiki:

1
2
3
4
5

user@user:~$ udisksctl loop-setup -f 2023-06-11.iso
Mapped file 2023-06-11.iso as /dev/loop57.
user@user:~$ udisksctl unlock -b /dev/loop57 
Passphrase: 
Error unlocking /dev/loop57: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/loop57: Failed to activate device: File exists

Es klappt nicht, die Fehlermeldung oben erhalte ich auch, wenn ich das Image über den Dateimanager einbinden will. Die Festplatte, auf der das Image gespeichert ist, ist ebenfalls mit LUKS verschlüsselt. Hier hat das Einbinden problemlos funktioniert (über den Dateimanager).

Mache ich was falsch, oder ist das ein Bug? Ich bin dabei, meine Festplatte umzuziehen, und habe deshalb dieses Backup gemacht. Dieses betrachte ich erst als abgeschlossen, wenn es mir gelungen ist, dieses auch wieder zu öffnen (alte Backup-Regel).

Da könnte daran hängen, dass es noch Reste im Device-Tree gibt - vgl. z.B. https://unix.stackexchange.com/questions/546306/error-unlocking-a-luks-partition-failed-to-activate-devicefile-exists

seahawk1986 schrieb:

Da könnte daran hängen, dass es noch Reste im Device-Tree gibt - vgl. z.B. https://unix.stackexchange.com/questions/546306/error-unlocking-a-luks-partition-failed-to-activate-devicefile-exists

Hmm, ich verstehe leider nich, was ein Device-Tree, oder Reste darin sind. Im Artikel ist jedenfalls davon die Rede, dass es nach Neustart funktioniert hätte. Hat es bei mir nicht. Einziger Unterschied: dann war es loop 55 statt 57. Ich verstehe auch die Antwort nicht, oder was mit der Ausgabe (in meinem Fall wie unten) anzufangen wäre.

1
2
3
4
5
6
7
8
9

:~$ sudo dmsetup ls --tree
luks-3dbd73ff-8d01-48be-9055-459c77289385 (253:3)
 └─ (8:17)
ubuntu--vg-root (253:1)
 └─nvme0n1p3_crypt (253:0)
    └─ (259:3)
ubuntu--vg-swap_1 (253:2)
 └─nvme0n1p3_crypt (253:0)
    └─ (259:3)

1
2
3
4
5

sudo fdisk -l
Festplatte /dev/loop55: 464,54 GiB, 498801311744 Bytes, 974221312 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

Die originale Partition ist Teil einer "LVM Volume Group" (gemeinsam mit der Swap-Partition). Kann es sein, dass das eine Rolle spielt? Das Image beinhaltet nur die Daten-Partition, nicht die Swap-Partition.

Das_Auge schrieb:

[…] nach der Anleitung im Wiki

1. Funktioniert es mit der dort angegebenen alternativen Methode mit Superuser-Rechten?

2. Bist Du sicher, die Passphrase richtig eingegeben zu haben?

3. Wie lautet die Fehlermeldung, wenn Du bewusst ein falsches Passwort eingibst?

udisksctl kenne ich leider nicht gut genug. Wenn das ein Image von einer ansonsten noch existierenden Partition ist, liegts vielleicht einfach an der doppelten UUID.

Wenn das Image ein LUKS Container ist (keine Partitionstabelle o.ä. dazwischen), dann sollte es direkt mit cryptsetup open funktionieren (ohne Loop-Device bzw. das macht cryptsetup selbst für dich).

kB schrieb:

Das_Auge schrieb:

[…] nach der Anleitung im Wiki

1. Funktioniert es mit der dort angegebenen alternativen Methode mit Superuser-Rechten?

2. Bist Du sicher, die Passphrase richtig eingegeben zu haben? 3. Wie lautet die Fehlermeldung, wenn Du bewusst ein falsches Passwort eingibst?

Bei der Admin-Variante komme ich erfolgreich bis zum letzten Schritt (mounten). Dort sagt es mir dann

1
2

: $ sudo mount -t ext4 /dev/mapper/container /media/user/img/ 
mount: /media/user/img: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/mapper/container ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

Wenn ich das Falsche Passwort eingebe (bei "cryptsetup luksOpen…", dem vorletzten Schritt), meldet es mir hingegen: "Kein Schlüssel mit dieser Passphrase verfügbar."

In der Variante im Userspace macht es keinen Unterschied, ob die Passphrase stimmt: die Fehlermeldung ist die gleiche.

frostschutz schrieb:

udisksctl kenne ich leider nicht gut genug. Wenn das ein Image von einer ansonsten noch existierenden Partition ist, liegts vielleicht einfach an der doppelten UUID.

Die UUID ist nicht gleich, aber der VG-Name. Da es mir nicht gelugen ist, ihn in der neuen Partition zu ändern, habe ich ihn in der alten geändern (nicht nachmachen!) und mir damit das System zerschossen. Ich konnte den Schritt mit einem Live-System wieder rückgängig machen.

Wenn das Image ein LUKS Container ist (keine Partitionstabelle o.ä. dazwischen), dann sollte es direkt mit cryptsetup open funktionieren (ohne Loop-Device bzw. das macht cryptsetup selbst für dich).

Es ist eine Partition aus einer LVM Volume-Group. "cryptsetup open" sagt: Gerät »container« kann nicht verwendet werden, da es gerade benutzt wird oder der Name ungültig ist.

Ich glaube, ich habe das Problem jetzt gefunden: Ich habe versucht, eine LVM Volume Group zu mounten, anstatt ein Logical Volume.

Während mir "sudo vgdisplay" nur erstere ausgibt, bekomme ich mit "sudo vgdisplay -v" auch letztere serviert.

Wenn du nur das suchst dann gehts auch "intuitiver":

1

sudo lvs # äquivalent zu pvs für physical volume bzw. vgs für die volume groups

Mittlerweile hatte ich wirklich die Notwendigkeit, das Image zu booten. Die fehlenden Puzzlestücke:

1. Ich habe das image von ubuntu-vg auf ubuntu-vg-alt umbenannt (musste etwas knobeln, bis ich die richtige UUID dafür gefunden hatte)

2. ich habe mit

   1	sudo vgchange -ay ubuntu-vg-alt

   das Volume aktiviert, sodass ich es dann ganz normal einbinden konnte

Danke für eure Tipps und Hilfen!