Das mit mkudffs erstellte UDF-Dateisystem kann nicht in einem luks-Volume bereitgestellt werden

965
Jon

Ich versuche, eine verschlüsselte Blu-ray-Sicherung zu erstellen. Ich habe das Bild mit dem folgenden groben Skript erstellt und gebrannt:

imgsize=23000M imgfile=~/backup.img imgloop=`sudo losetup -f` truncate -s $imgsize $imgfile sudo losetup $imgloop $imgfile sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop sudo cryptsetup luksOpen $imgloop mybackup sudo mkudffs /dev/mapper/mybackup if [ ! -d "/mnt/backup" ]; then sudo mkdir /mnt/backup fi sudo mount /dev/mapper/mybackup /mnt/backup  # Now copy all files that are part of the backup echo "Copy files to backup to /mnt/backup. Type 'ready' when done"; while read line; do echo "$line"; if [ "$line" == "ready" ]; then break; fi done  sudo umount /mnt/backup sudo cryptsetup luksClose /dev/mapper/mybackup sudo losetup -d $imgloop 

Wenn das Skript fertig ist, habe ich den folgenden Befehl verwendet, um es auf eine M-Disc BD-R zu brennen:

growisofs -dvd-compat -Z /dev/dvd=backup.img 

Die Verbrennung ist ohne Fehler abgeschlossen. Ich kann das Volume luks mit folgendem Befehl öffnen:

sudo cryptsetup luksOpen /dev/dvd mybackup 

Welche produziert das gerät /dev/mapper/mybackup; Wenn ich jedoch versuche, es mit zu montieren:

sudo mount -t udf /dev/mapper/mybackup /mnt/backup 

Ich erhalte folgende Fehlermeldung:

mount: /dev/mapper/mybackup is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup, missing codepage or helper program, or other error  In some cases useful info is found in syslog - try dmesg | tail or so. 

Syslog enthält den folgenden Fehler:

[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found [ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1) 

Update 1

Mit den folgenden Befehlen kann ich das vom Skript erzeugte Image mounten:

sudo cryptsetup luksOpen backup.img mybackup sudo mount -t udf /dev/mapper/mybackup /mnt/backup 

Es läuft also etwas schief, weil es auf der CD ist.

0

2 Antworten auf die Frage

3
Thomas Schmitt

Der wahrscheinlichste Grund für den Fehler ist die Nur-Lese-Beschränkung des Mediums, wenn es für LUKS geöffnet werden soll.

Die folgenden Experimente zeigen, dass die Option -r von cryptsetup den Trick erfüllt:

sudo cryptsetup luksOpen -r /dev/dvd mybackup sudo mount -t udf /dev/mapper/mybackup /mnt/backup 

Erste falsche Theorie:

Ein Hauptunterschied zwischen optischen Medien und Datendateien oder Plattengeräten ist die Blockgröße von 2048 Byte. Beispielsweise werden Partitions-Editoren dadurch verwirrt, dass sie die Partitionstabellen von Isohybrid-DVDs untersuchen. Möglicherweise hängt LUKS in ähnlicher Weise davon ab, dass die gleiche Blockgröße für Geräte mit Verschlüsselung und Entschlüsselung verwendet wird.

Wenn Sie BD-RE-Medien verwenden, können Sie versuchen, das verschlüsselte Dateisystem direkt unter / dev / dvd und nicht in der Datei ~ / backup.img zu erstellen. (Die Leistung bei starkem wahlfreiem Zugriff ist schlecht. Ihre RAM-Puffer können anderen virtuellen Speicher abschieben und dazu führen, dass die verwendeten Programme langsam arbeiten. Synchronisierung oder Umount können recht lange dauern.

Wenn Sie BD-R verwenden, können Sie ein BD-RE zum Erstellen des Bildes verwenden und es dann auf das BD-R-Medium kopieren.

Wenn nichts funktioniert, könnte ich die -external_filter-Funktion von xorriso anbieten, die den Dateiinhalt verschlüsseln würde, während er in ein ISO 9660-Dateisystem mit Klartext-Verzeichnisbaum eingefügt wird. Nicht die gleiche Privatsphäre wie bei LUKS, aber weniger exotisch.

(Warum in aller Welt entscheiden Sie sich für UDF? Haben Sie Solaris- oder BSD-Maschinen, auf denen UDF-Treiber möglicherweise besser sind als ihre unterirdischen ISO 9660-Treiber?

Die Spur, der ich hätte folgen sollen:

Einige Problemberichte im Internet über LUKS und CD / DVD / BD empfehlen die Verwendung der Option cryptsetup -r als Wundermittel. (Dh schreibgeschützt und nicht die Blockgröße wäre der Stolperstein.)

Sicherstellen, dass optische Medien mit LUKS funktionieren:

Ich habe versucht, den BD-RE-Teil meines Vorschlags auf einem Gerät mit 2K-Blöcken (auch als Sektoren bezeichnet) zu erstellen. Das BD-RE befindet sich in / dev / sr4. Einrichten als verschlüsselte Festplatte:

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4 sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre 

Um zu vermeiden, dass Sie beim Ausführen von xorriso ein Superuser sein müssen, gebe ich die aufgetauchte Gerätedatei der Gruppe "cdrom", in der ich Mitglied bin:

chgrp cdrom /dev/dm-0 

Mit xorriso eine ISO schreiben. Sie würden eine UDF erstellen und füllen:

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory / 

Dies ist verdammt langsam, möglicherweise aufgrund von BD-RE Defect Management, das Xorriso nicht durch die Crypto Device Layer beeinflussen kann. Ich checke von Teer und (weil ich es habe) von Xorriso:

sudo mount /dev/mapper/mybdre /mnt/iso tar cf - /mnt/iso | wc 

Keine E / A-Fehler, erwartete Größe des ISO-Inhalts wird gemeldet.

sudo umount /mnt/iso xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media -- 

meldet MD5-Übereinstimmung der ISO-Sitzung. Das würde also funktionieren. Nun müsste jemand eine BD-R investieren und die BD-RE darauf kopieren.

Der Unterschied der Blockgröße von Datenträgerdateien und BD spielt keine Rolle:

Ich hätte das zuerst probieren sollen. Nun folgte ich Ihrem Rezept, nur dass ich das verschlüsselte Bild auf ein BD-RE kopiert habe (für BD-R immer noch zu sparsam).

Es klappt. Ich kann das BD-RE mit -t udf mounten und den Inhalt der Datei in wc tar.

Das Hörensagen über die Option cryptsetup -r auf Nur-Lese-Medien scheint also die einzig mögliche Theorie zu sein.

Erfolg mit einer CD-RW als Ersatz für eine BD-R:

Ich habe es mit einer unformatierten CD-RW versucht, die von Linux als schreibgeschützt angesehen wird.

sudo cryptsetup luksOpen /dev/sr4 mybackup sudo mount -t udf /dev/mapper/mybackup /mnt/backup 

Werde es nie wieder tun Die Festplatte wurde vom Kernel abgeworfen. Eine der Zeilen in / var / log / messages besagt, dass Linux versucht hat, darauf zu schreiben. Nur gut ist es in einer USB-Box. So konnte ich es durch einen Power Cycle wiederherstellen.

Mit der Option -r funktioniert es gut:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup sudo mount -t udf /dev/mapper/mybackup /mnt/backup tar cf - /mnt/backup | wc 
Ich verwende eine [M-DISC] (https://en.wikipedia.org/wiki/M-DISC), die für die Langzeitspeicherung ein BD-R-Äquivalent ist. Ich befolge gerade [dieses Handbuch] (http://www.troubleshooters.com/lpm/201408/201408.htm). Der Grund für UDF ist die Unterstützung von Dateien> 4 GB, die bei der Sicherung von Heimvideos auftreten können. Unter Blockgröße ist das UDF-Dateisystem Blockgröße innerhalb des LUKS gemeint? Jon vor 7 Jahren 0
Die Aussage, dass BD-Dateisysteme UDF sein müssen, ist eindeutig falsch. Solaris und die BSDs verfügen über mehr als 20 Jahre alte ISO 9660-Lesetreiber, die nur Datendateien bis zu 4 GiB-1 lesen können. Linux und MS-Windows können Datendateien, die größer als 4 GiB sind, aus einem ISO 9660-Dateisystem lesen. Meine Blockgrößentheorie bezieht sich auf die Blockgröße des Geräts (oder der Datei), auf der die mit LUKS verschlüsselte UDF erstellt wird, im Vergleich zur Blockgröße des BD-Mediums. Ihr Unterschied könnte erklären, warum es auf der Festplatte funktioniert, aber nicht auf BD. Thomas Schmitt vor 7 Jahren 0
Der Leitfaden stimmt nicht mit der Aussage, dass ext4 nicht "mit optischen Medien kompatibel" sei (in "LUKS / Blu-ray-Objektiv"). Ich habe gerade ein ext4 auf BD-RE erstellt und es funktioniert (wenn auch laut). Die im Handbuch angezeigte Fehlermeldung für mount für ext4-in-LUKS ist die gleiche wie bei UDF-in-LUKS. Thomas Schmitt vor 7 Jahren 1
Ich habe meine Antwort aktualisiert. Die Blockgröße scheint nicht das Problem zu sein. Aber ein Nur-Lese-Medium könnte gut sein. Dh versuchen Sie Cryptsetup-Option -r (ich nehme an, mit luksOpen). Thomas Schmitt vor 7 Jahren 0
0
Jon

Endlich gelang es mir, den verschlüsselten Bluray zu mounten, indem ich den Leser zunächst einem Loop-Gerät zuordnet und Cryptsetup auf letzterem funktionierte:

sudo losetup /dev/loop0 /dev/dvd sudo cryptsetup luksOpen /dev/loop0 myvolume sudo mount /dev/mapper/myvolume /mnt/backup 

Der verschlüsselte Bluray wird dann an montiert /mnt/backup.

Ich entdeckte dies in einem alten Red Hat-Fehlerbericht. Ich habe keine Ahnung, warum das Loop-Gerät benötigt wird, und vermute, es könnte ein Fehler sein, da das automatische Mounten mit dem GUI in thunarfehlschlägt (man würde erwarten, dass es funktioniert), was auch der Rote ist Hat Fehlerbericht erwähnt, jedoch mit Gnome-Desktop. Es ist auch sehr seltsam, dass das Image, das auf dem bluray brennt, ohne das Loop-Gerät montiert werden kann.

Um das obige umzukehren, verwenden Sie Folgendes:

sudo umount /mnt/backup sudo cryptsetup luksClose myvolume sudo losetup -d /dev/loop0 

Ich habe einen Fehlerbericht mit Cryptsetup für den Fall geöffnet, dass es sich um einen Fehler handelt.