[How-To] Daten verschlüsselt auf DVD speichern

[schachti]

Hallo,

ich habe ein kleines How-To geschrieben, wie man Daten verschlüsselt auf DVD speichern und später wieder auf diese Daten zugreifen kann (transparente Entschlüsselung mittels dm-crypt). Vielleicht guckt Ihr es Euch mal an, ich bin für jeden Hinweis, wie ich es verbessern/ergänzen kann, dankbar!



1. Einleitung

Im folgenden Text werde ich beschreiben, wie man Daten in verschlüsselter Form auf eine DVD brennen und später wieder auf diese Daten zugreifen kann.

Die Verschlüsselung beruht auf dm-crypt (http://www.saout.de/misc/dm-crypt/), einer im Kernel eingebauten Verschlüsselungs-Schnittstelle, mit der sich eine für den Nutzer transparente Entschlüsselung realisieren läßt (transparente Entschlüsselung bedeutet, daß man das Paßwort nur ein einziges Mal eingeben muß und dann mit den Daten ganz normal arbeiten kann, weil alles vom System im Hintergrund automatisch entschlüsselt wird). Man könnte die zu brennenden Dateien natürlich auch einzeln mit z. B. GnuPG verschlüsseln, aber das ist gerade bei sehr vielen Dateien lästig (jede einzelne Datei muß vor Gebrauch entschlüsselt werden und belegt dann zusätzlichen Speicherplatz auf der Festplatte, man muß die entschlüsselten Dateien nach Gebrauch wieder löschen, und außerdem muß man für jede einzelne Datei das Paßwort erneut eingeben).

Daher wird in diesem How-To erklärt, wie man eine große Datei auf die DVD bekommt, die ein verschlüsseltes Dateisystem entählt, das nach einmaliger Eingabe des Paßwortes gemountet wird und dann wie jedes andere Dateisystem gelesen werden kann.



2. Voraussetzungen

Ich habe alle Schritte dieses How-To selbst mehrfach getestet und keine Probleme feststellen können. Die folgende Software kam zum Einsatz:

• sys-kernel/gentoo-dev-sources-2.6.10-r6
• sys-fs/udftools-1.0.0b-r4
• sys-fs/e2fsprogs-1.35-r1
• sys-fs/cryptsetup-0.1
• app-cdr/dvd+rw-tools-5.21.4.10.8

Sollte ein Schritt dieser Anleitung nicht wie erwartet funktionieren, könnte das daran liegen, daß eine andere Version eines der oben genannten Programme zum Einsatz kommt, die sich anders verhält als die von mir getestete Version.

Die folgenden Optionen müssen im Kernel selektiert sein:

Code: Select all

Device Drivers  --->
  Block devices  --->
    <*> Loopback device support
  Multi-device support (RAID and LVM)  --->
    [*] Multiple devices driver support (RAID and LVM)
    <*>   Device mapper support
    <*>     Crypt target support

File systems  --->
  CD-ROM/DVD Filesystems  --->
    <*> UDF file system support

Cryptographic options  --->
  <*>   AES cipher algorithms (i586)

Wichtig: Werden diese Funktionalitäten nicht fest in den Kernel, sondern als Module kompiliert, muß man diese Module vor Benutzung ggfs. mittels modprobe nachladen. Vor allem cryptsetup funktioniert nur nach einem modprobe dm-crypt, falls man die Unterstützung für dm-crypt als Modul kompiliert hat!

Falls man in der verschlüsselten Containerdatei ein anderes Dateisystem als UDF haben möchte (siehe unten), muß dieses Dateisystem natürlich auch im Kernel ausgewählt sein. Falls man einen anderen Algortihmus zur Verschlüsselung verwenden möchte (siehe unten), muß dieser natürlich anstatt von (oder zusätzlich zu) AES gewählt werden.

Die folgenden Pakete werden benötigt:

Code: Select all

emerge sys-fs/udftools sys-fs/cryptsetup app-cdr/dvd+rw-tools

3. Das Image erzeugen und brennen

Zuerst die Image-Datei erzeugen - einfach eine 4.700.000.000 Byte große Datei mit Nullen füllen:

Code: Select all

dd if=/dev/zero of=/mnt/image.udf bs=1kD count=4700000

Die Image-Datei an ein Loop-Device binden:

Code: Select all

losetup /dev/loop0 /mnt/image.udf

Ein UDF-Dateisystem in der Image-Datei erzeugen:

Code: Select all

mkudffs --media-type=dvd /dev/loop0

Das erzeugte Dateisystem nach /mnt/image mounten:

Code: Select all

mount /dev/loop0 /mnt/image

Den Ordner lost+found brauchen wir auf der DVD nicht und können ihn löschen:

Code: Select all

rm -r /mnt/image/lost+found

Im Verzeichnis /mnt/image/ erzeugen wir eine Containerdatei, die später das verschlüsselte Dateisystem enthält. Die Größe der Datei hängt vom freien Platz im Image ab, der sich mit dem folgenden Befehl ermitteln läßt:

Code: Select all

df /mnt/image

Hinweis: Bei dieser Anzeige ist 1 kB = 1 024 Byte, während wir durch die Angabe im dd-Befehl oben durch das D in "bs=1kD" festgelegt haben, daß 1 kB = 1 000 Byte im dd-Befehl sein soll. Bei meinem Test waren 4 588 492 kB frei (evtl. variiert diese Zahl auf anderen Architekturen oder mit anderen Kernel-Versionen, ich weiß es nicht). Da für verschiedene Informationen im Dateisystem noch Speicherplatz verwendet wird, muß man die Dateigröße entsprechend kleiner wählen als den eigentlich freien Platz (meiner Erfahrung nach reicht ca. 1 MB dafür aus, sicherheitshalber lassen wir ein bißchen mehr frei, nämlich ca. 3.5 MB). Aus Sicherheitsgründen (um Kryptoanalyse zu erschweren) wird die Containerdatei mit Zufallswerten vollgeschrieben:

Code: Select all

dd if=/dev/urandom of=/mnt/image/encrypted.image bs=1k count=4585000

(das dauert eine ganze Zeit, 30 Minuten sind nicht ungewöhnlich - das sind nunmal die Kosten der gewonnenen Sicherheit!).

Nun: Die Containerdatei an ein (anderes als das bereits benutzte!) Loop-Device binden:

Code: Select all

losetup /dev/loop1 /mnt/image/encrypted.image

Zur Verschlüsselung über dm-crypt auf dieses Loop-Device zugreifen:

Code: Select all

cryptsetup -c aes-cbc-essiv:sha256 -y create encrypted /dev/loop1

(man kann auch jeden anderen Verschlüsselungs-Algorithmus wählen, der entweder fest in den Kernel hinein oder als Modul kompiliert ist, siehe oben). Da es gegen die Standard-Implementierung von AES im Kernel eine theoretische Angriffsmöglichkeit gibt, habe ich als Algorithmus nicht Standard-AES gewählt, sondern aes-cbc-essiv:sha256 - mehr Informationen dazu gibt es auf http://www.saout.de/misc/dm-crypt/ unter dem Punkt "cryptsetup". Wichtig: aes-cbc-essiv:sha256 funktioniert erst ab Kernel 2.6.10!

Nach Eingabe des obigen Befehls wird das Paßwort für die Verschlüsselung abgefragt. Wenn man dieses Pawort vergißt, besteht keine Möglichkeit mehr, an die Daten, die verschlüsselt werden, heranzukommen (es sei denn, man hat ein so einfaches Paßwort gewählt, daß es sich mittels Brute Force knacken läßt - aber das sollte man sowieso nie tun)!

Nun werden wir ein Dateisystem in der Containerdatei erzeugen - welchen Typ man nimmt, hängt davon ab, was für Daten man speichern möchte (und welche Dateisysteme vom Kernel unterstützt werden), prinzipiell ist hier jedes Dateisystem möglich. Ich nehme hier UDF, aber man kann genausogut ext2, ext3, reiserfs, jfs, xfs oder irgend ein anderes Dateisystem wählen:

Code: Select all

mkudffs /dev/mapper/encrypted

Möchte man ein bewährtes Standard-Dateisystem, das für wenige große Dateien optimiert ist, so bietet sich ein speziell präpariertes ext2 an:

Code: Select all

mke2fs -m 0 -O sparse_super -T largefile4 /dev/mapper/encrypted

(dafür wird evtl. das Paket sys-fs/e2fsprogs benötigt).

Das gerade erzeugte Dateisystem wird nun nach /mnt/encrypted gemountet:

Code: Select all

mount /dev/mapper/encrypted /mnt/encrypted

Auch hier benötigen wir das Verzeichnis lost+found nicht, da wir die Daten nur ein Mal schreiben und das Dateisystem anschließend immer nur readonly gemountet wird:

Code: Select all

rm -r /mnt/encrypted/lost+found/

Nun können die gewünschten Daten nach /mnt/encrypted kopiert bzw. verschoben werden. Sobald man fertig ist, muß man alle Bindungen in der umgekehrten Reihenfolge wieder lösen:

Code: Select all

umount /mnt/encrypted
cryptsetup remove encrypted
losetup -d /dev/loop1
umount /mnt/image
losetup -d /dev/loop0

Nun kann die Datei /mnt/image.udf auf DVD gebrannt werden (in diesem Beispiel ist /dev/cdroms/cdrom0 der DVD-Brenner):

Code: Select all

growisofs -dvd-compat -Z /dev/cdroms/cdrom0=/mnt/image.udf

Anschließend wird die Imagedatei /mnt/image.udf nicht mehr benötigt und kann gelöscht werden.



4. Die DVD mounten / Daten auslesen

Das Mounten der DVD und das Auslesen der Daten geschieht ähnlich wie das Erstellen, aber etwas einfacher. Zunächst wird die DVD gemountet (dazu muß das Verzeichnis /mnt/dvd natrlich existieren - /dev/cdroms/cdrom0 ist wieder das Laufwerk, in dem die DVD liegt):

Code: Select all

mount -t udf /dev/cdroms/cdrom0 /mnt/dvd

Nun kann die verschlüsselte Containerdatei an ein Loop-Device gebunden

Code: Select all

losetup /dev/loop0 /mnt/dvd/encrypted.image

und anschließend gemountet werden:

Code: Select all

cryptsetup -c aes-cbc-essiv:sha256 create encrypted /dev/loop0
mount /dev/mapper/encrypted /mnt/encrypted

Nun kann man wie gewohnt aus dem Verzeichnis /mnt/encrypted lesen, die gesamte Entschlüsselung erfolgt transparent! Nach Gebrauch löst man die Bindungen wie gewohnt in umgekehrter Reihenfolge wieder:

Code: Select all

umount /mnt/encrypted
cryptsetup remove encrypted
losetup -d /dev/loop0
umount /mnt/dvd

[ZX-81]

Supergenial !!!

Wollte gerade beginnen dahinterzukommen wie man das macht, dann sehe ich Dein Howto.

Da hast Du mir eine Menge Arbeit erspart, ist sogar noch etwas mehr zu tun, als ich dachte. Und das hätte mich bestimmt Tage gekostet.

Sieht auch sehr gut aus Dein Howto, bin gerade dabei es durchzuziehen.

Eine Frage stellt sich mir Allerdings: In vielen Crypt-Howtos wird das Device mit Zufallswerten (/dev/random oder so) initialisiert (=vollgeschrieben) um "known plaintext"- Angriffen zu entgehen, ist das in diesem Fall nicht notwendig oder hätte es andere Nachteile?
EDIT kurz nach Einstellen meines Beitrag, habe ich gesehen, dass es ja auf dem verschüsselten Device gemacht wird, sorry

Tausend Dank für das tolle Howto.

ZX

[schachti]

Supergenial !!!

Danke, nicht nur über Kritik freut man sich.

Wollte gerade beginnen dahinterzukommen wie man das macht, dann sehe ich Dein Howto.

Da hast Du mir eine Menge Arbeit erspart, ist sogar noch etwas mehr zu tun, als ich dachte. Und das hätte mich bestimmt Tage gekostet.

Ich wünsche Dir viel Erfolg. Falls Dir eine Stelle auffällt, die detaillierter beschrieben werden sollte, oder wenn Du Fehler findest oder etwas nicht klappt, würde ich mich über Feedback sehr freuen.

Eine Frage stellt sich mir Allerdings: In vielen Crypt-Howtos wird das Device mit Zufallswerten (/dev/random oder so) initialisiert (=vollgeschrieben) um "known plaintext"- Angriffen zu entgehen, ist das in diesem Fall nicht notwendig oder hätte es andere Nachteile?

Wird ja in meinem How-To auch gemacht:

Aus Sicherheitsgründen (um Kryptoanalyse zu erschweren) wird die Containerdatei mit Zufallswerten vollgeschrieben:

Code: Select all

dd if=/dev/urandom of=/mnt/image/encrypted.image bs=1k count=4585000

(das dauert eine ganze Zeit, 30 Minuten sind nicht ungewöhnlich - das sind nunmal die Kosten der gewonnenen Sicherheit!).

Was man dagegen nicht mit Zufallswerten vollschreiben muß, ist die erste Image-Datei für das UDF-Dateisystem - denn das wird ja unverschlüsselt gebrannt und darüberhinaus bis auf die übriggebliebenen 2-3 MB von der verschlüsselten Containerdatei überschrieben.

[ZX-81]

Absolute Spitzenklasse, hat alles geklappt!

Glücklicherweise hatte ich schon alle notwendigen Module im Kernel konfiguriert (mit development-sources-2.6.10-r1 geht es also auch), so dass ich keinen neuen bauen musste.

Dabei hatte ich aber alles als Modul konfiguriert und cryptsetup hat sich beschwert dass das Modul dm-crypt fehlt. Verraten hat mir cryptsetup den Fehler über die -v (verbose) Option.

Ich wollte die erzeugte DVD dann auch noch mit einem anderen Rechner testen. Dabei hat sich gezeigt dass die von Dir gewählte Verschlüsselung mit den development-sources-2.6.8.1 noch nicht möglich ist (Nach update auf 2.6.10-r1 ging es).

Für mich war das jetzt eine grosse Erleichterung, wenn man weis, wie es funktioniert ist es keine Hexerei mehr, aber bis man da dahinterkommt schon. Wie lange hast Du denn gebraucht, bis du alles zusammen hattest?

Das ist doch jetzt was für die "Jäger und Sammler" unter den Gentoo-Usern, die große Probleme mit dem Backup Ihrer auf Festplatte verschlüsselten Schätze haben

Nochmal Vielen Dank!

ZX

[schachti]

Dabei hatte ich aber alles als Modul konfiguriert und cryptsetup hat sich beschwert dass das Modul dm-crypt fehlt. Verraten hat mir cryptsetup den Fehler über die -v (verbose) Option.

ok, ich habe es nur mit fest in den Kernel einkompilierter Funktionalität getestet, da hatte ich das Problem nicht. Ich werde das im How-To an den entsprechenden Stellen ergänzen.

Ich wollte die erzeugte DVD dann auch noch mit einem anderen Rechner testen. Dabei hat sich gezeigt dass die von Dir gewählte Verschlüsselung mit den development-sources-2.6.8.1 noch nicht möglich ist (Nach update auf 2.6.10-r1 ging es).

Ah, das sollte ich auch anmerken: aes-cbc-essiv:sha256 ist erst ab Kernel 2.6.10 möglich. Werde ich auch gleich ergänzen.

Für mich war das jetzt eine grosse Erleichterung, wenn man weis, wie es funktioniert ist es keine Hexerei mehr, aber bis man da dahinterkommt schon. Wie lange hast Du denn gebraucht, bis du alles zusammen hattest?

Ach, so lange nicht, ich habe mich vor einem halben Jahr schonmal mit dm-crypt beschäftigt, um eine Datenfestplatte zu verschlüsseln, daher mußte ich nur noch herausfinden, wie man das auf DVD macht (denn ISO9660, das auf CDs und auch auf DVD momentan Standard-Dateisystem ist, unterstützt keine Dateien mit mehr als 2 GB - da bräuchte man 3 Container-Dateien auf der DVD, das wäre sehr lästig...).

[MrIch]

hier mein Skript:

Code: Select all

#!/bin/bash
# Backup auf DVDRAM
# skript by MrIch
#
#
# Tutorial http://forums.gentoo.org/viewtopic-t-295727.html


BURNDEV=/dev/cdroms/cdrom0
BURNMNT=/mnt/cdrw
LOOP1=/dev/loop1
LOOP2=/dev/loop2
UDFIMAGE=/mnt/image.udf
UDFMNT=/mnt/image
ENCIMAGE=$UDFMNT/encrypted.image
ENCMNT=/mnt/encrypted

SOURCE=/home/mrich/
TARGET=/mnt/encrypted/

EXCLUDE=/home/mrich/.backup_exclude

echo "=============================================="
echo "| Backup nach DVD                            |"
echo "=============================================="

echo "$SOURCE soll nach $BURNDEV gesichert werden"

# do not edit below this line
#############################################################

if [ -w $UDFIMAGE ]; then
	echo "$UDFIMAGE wird gelöscht!"
	rm $UDFIMAGE
fi

# Platten Check
FREE=`df / | tail -n 1 | awk '{ print $3}'`
SPACE=5000000
if [ $FREE -le $SPACE ]; then
	echo "$SPACE needed"
	echo "$FREE found"
	echo "Plattenplatz reicht nicht aus!"
	exit 1
fi

# image erzeugen
dd if=/dev/zero of=$UDFIMAGE bs=1kD count=4500000 && echo "$UDFIMAGE erzeugt" 

# image einbinden
losetup $LOOP1 $UDFIMAGE && echo "$LOOP1 $UDFIMAGE eingebunden"

# udf Dateisystem für DVD erzeugen
mkudffs --media-type=dvd $LOOP1 && echo "udf Dateisystem für DVD erzeugt"

# udf Dateisystem mounten
mount $LOOP1 $UDFMNT && echo "udf Dateisystem gemountet"

# l+f entfernen
rm -fr $UDFMNT/lost+found/ && echo "lost und found entfernt"

# image für loop-aes erstellen
dd if=/dev/urandom of=$ENCIMAGE bs=1k count=4500000 && echo "image $ENCIMAGE für loop-aes erstellt"

# image per loop-aes einbinden
losetup -e AES256 $LOOP2 $ENCIMAGE && echo "image $ENCIMAGE per loop-aes $LOOP2 eingebunden"

# Dateisystem auf loop-aes image device anlegen
mkfs.ext2 $LOOP2 && echo "Dateisystem auf loop-aes $LOOP2 image device erzeugt"

# loop-aes image device mounten
mount $LOOP2 $ENCMNT && echo "loop-aes $LOOP2 image device nach $ENCMNT gemountet"

# l+f entfernen
rm -r $ENCMNT/lost+found/ && echo "lost und found entfernt"

# clean
rm -fr $SOURCE.thumbnails
rm -fr $SOURCE.kdebackup/share/cache
rm -fr $SOURCE.kde/share/cache
rm -fr $SOURCE.kdebackup/share/cache
rm -fr $SOURCE.mozilla/firefox/*/Cache/*
rm -fr $SOURCE.mozilla.org/firefox/*/Cache/*

# backup
rsync -av --exclude-from=$EXCLUDE $SOURCE $TARGET && echo "$SOURCE nach $TARGET gesichert"

# image ausbinden
umount $ENCMNT && echo "$ENCMNT ausgehangen" 
losetup -d $LOOP2 && echo "$LOOP2 entfernt" 
umount $UDFMNT && echo "$UDFMNT ausgehangen"
losetup -d $LOOP1 && echo "$LOOP1 entfernt"

# image auf dvd brennen
growisofs -dvd-compat -Z $BURNDEV=$UDFIMAGE && echo "$UDFIMAGE nach $BURNDEV gebrannt"

# Test md5
md5sum $UDFIMAGE
md5sum $BURNDEV
echo "====================================="
echo "Bitte md5sum vergleichen"

# Testmount
mount -t udf $BURNDEV $BURNMNT
ls -la $BURNMNT
umount $BURNMNT

ist glaube ich ganz gut geworden... arbeitet mit loop-aes. Noch ungetstet.


Was ich nicht verstehe:

Code: Select all

plinux011 mnt # md5sum /dev/cdroms/cdrom0
64bf0d9eb9d3834063d2c96fcce157d5  /dev/cdroms/cdrom0
plinux011 mnt # md5sum image.udf
3258185913ee86a896b754136168a276  image.udf

müssten da nicht die selben md5 summen rauskommen?

[manuels]

Was ich nicht verstehe:

Code: Select all

plinux011 mnt # md5sum /dev/cdroms/cdrom0
64bf0d9eb9d3834063d2c96fcce157d5  /dev/cdroms/cdrom0
plinux011 mnt # md5sum image.udf
3258185913ee86a896b754136168a276  image.udf

müssten da nicht die selben md5 summen rauskommen?

Ich schätze, dass das durch lead-in/lead-out kommt.

[spx]

Aber warum macht Ihr das so kompliziert mit Container-Datei mit filesystem auf einem anderem Filesystem und
verschlüsselt nicht nicht gleich das 1. Dateisystem mit 65 verschiedenen Schlüsseln ? Ist eh sicherer, oder ?

Hier mal ein Auszug aus der aespipe.README:

3.3. Example 3 - Encrypted CD-ROM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create 65 random encryption keys and encrypt those keys using gpg. Reading
from /dev/random may take indefinitely long if kernel's random entropy pool
is empty. If that happens, do some other work on some other console (use
keyboard, mouse and disks). Use of gpg encrypted key file depends on
encrypted swap.

gpg encrypted key file is recorded to first 8192 bytes of the CD-ROM. Key
file does not use all of 8192 bytes so remaining part of the 8192 bytes is
padded with newlines.

yes "" | dd of=image.iso bs=512 count=16
head -c 2925 /dev/random | uuencode -m - | head -n 66 | tail -n 65 \
| gpg --symmetric -a | dd of=image.iso conv=notrunc

Create encrypted ISO9660 CD-ROM image that can be mounted using Linux
loop-AES crypto package version 3.0a or later:

mkisofs -r directory-tree | aespipe -w 10 -K image.iso -O 16 >>image.iso

This image file can then be mounted under Linux like this:

mount -t iso9660 image.iso /cdrom -o loop=/dev/loop0,encryption=AES128,gpgkey=image.iso,offset=8192

Or, after writing image.iso to CD-ROM, like this:

mount -t iso9660 /dev/cdrom /cdrom -o loop=/dev/loop0,encryption=AES128,gpgkey=/dev/cdrom,offset=8192

Or, if this line is added to /etc/fstab file:

/dev/cdrom /cryptcd iso9660 defaults,noauto,loop=/dev/loop0,encryption=AES128,gpgkey=/dev/cdrom,offset=8192 0 0

Then encrypted CD-ROMs can be mounted and unmounted like this:

mkdir /cryptcd
mount /cryptcd
umount /cryptcd

In above mount cases the mounted device name must be identical to gpgkey=
definition and offset= must be specified. That condition is special cased
inside mount and losetup programs to prevent gpg from reading all of cdrom
contents when gpg is decrypting the key file.

If you ever need to extract unencrypted image of encrypted CD-ROM, you can
do that like this:

dd if=/dev/cdrom bs=8192 count=1 of=key.gpg
dd if=/dev/cdrom bs=8192 skip=1 | aespipe -d -K key.gpg -O 16 >clear.iso

Latter of above dd commands may cause some kernel error messages when dd
command attempts to read past end of CD-ROM device.

[Sodom]

Schönes Howto.

Es gibt aber eine Sache, die mir Sorgen bereitet. Wenn diverse Verschlüsselungs-Methoden zB erst ab kernel 2.6.10 funktionieren... wie kann ich da sicher sein, in 3 oder gar in 10 Jahren noch an die Daten kommen zu können, ohne eine Live-CD zu bauen und die zu archivieren? Da hilft dann doch wieder nur gnupg. Oder ist das ein Trugschluß?

[l3u]

Alternativer Vorschlag: Auf der Festplatte ein encfs-Verzeichnis anlegen, Daten ins FUSE-Verzeichnis und das verschlüsselte Verzeichnis direkt brennen. Funktioniert einwandfrei :-)

[phatmaxx]

@Sodom:

Wie Recht Du doch hast

Ich habe da irgendwie ein flaues Gefühl im Magen, wenn ich daran denke, meinen großen Raid5-Verbund zu crypten, arbeite grade an einer passablen Lösung. Da gibt es wahrlich so einige Möglichkeiten das Ganze ans Laufen zu bekommen. Wenn die Sache so weit läuft werde ich berichten.

[kernelOfTruth]

@schachti:

klasse Howto

genau sowas brauch ich

[schachti]

Ist nicht mehr ganz aktuell - daher ist Feedback, was noch unverändert geht, was Probleme macht und was man aktuell lieber anders machen sollte, sehr willkommen.

[s|mon]

Danke auch nochmal für das Howto.
Heute bin ich auch mal wieder dazugekommen ein verschluesseltes Image (ca 4.2GB) zu brennen - interessanterweise klappte das nun wieder ohne das ich die Datei splitten musste. In einer der letzten Kernel Versionen wurde die Limitierung auf 1GB Dateien (in UDF Dateisystemen) wieder entfernt. Vielleicht hat ja ausser mir noch jemand darauf gewartet

Erwähnenswert ist vielleicht das ich bei mkudffs dvdram als media-type angeben musste um das ganze zu befülllen.
Habe ich nur dvd angegeben wollte er partout nur read-only mounten.

Code: Select all

[63343.944045] UDF-fs: Partition marked readonly; forcing readonly mount
[63343.944514] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/12/27 11:19 (103c)

Da stellt sich mir nur die Frage wie den ein solches dateisystem dann zu befüllen wäre?

[schachti]

Da scheint sich etwas geändert zu haben...

Was bei mir seltsamerweise funktioniert: Erst "normal" mounten:

Code: Select all

losetup /dev/loop0 /mnt/image.udf 
mount /dev/loop0 /mnt/image 

Nun wird das Image zunächst read-only gemount; mittels

Code: Select all

mount -o remount,rw /mnt/image

kann man dann auch drauf schreiben.