Re: Problem mounting encrypted blu-ray disc or image
Hi,
B.M. wrote:
> If you want you can have a look at my script, I attached it to this mail...
Will do. (There must be some rational explanation ...)
> "Filesystem full" is not handled at all. Typically if this happens it's
> quite late i.e. most folders are already backuped and I do the following:
> - remove the last lz-file, I never checked if it is corrupted
> - burn the image
No
cryptsetup luksClose /dev/mapper/BDbackup
between remove and burn ?
-----------------------------------------------------------------------
I wrote:
> > But growisofs formats it [BD-R] by default to 11,826,176 = 23098 MiB =
> > 23,652,352 KiB.
> I didn't know that growisofs gives away a few bytes... Do you know why
> that's the case?
Andy Polyakov decided to format BD-R by default. Possibly because he used
an operating system (IIRC, Solaris) which did not expect that BD-R can be
used for multi-session. So its mount program followed the volume descriptors
starting at block 16 rather than at 16 blocks after the start of the youngest
session.
Whatever, growisofs by default wants to update the volume descriptors at
block 16 of the BD-R and for this uses BD-R Pseudo-Overwrite formatting.
This special feature uses the Defect Management to replace old written blocks
by newly written blocks.
Formatted BD-R cause the drive to perform Defect Management when writing.
This means half write speed at best, heavy clonking with smaller write
quality problems, and often miserable failure on media which work well
unformatted.
> Never heard about xorriso before
It makes ISO 9660 filesystems and burns them to optical media.
I am its developer.
> - from my understanding I could use it instead of growisofs, but with
> larger images?
Be invited. :))
Image burning is handled by its cdrecord emulation mode.
growisofs -dvd-compat -Z /dev/dvd=$IMGFILE; eject
translates to
xorriso -as cdrecord -v dev=/dev/dvd -eject $IMGFILE
But xorriso (in particular: libburn) cannot write more bytes to a BD-R
than growisofs with option -use-the-force-luke=spare=none can do.
It's just a matter of program defaults, in this case.
(There are other cases where think to have outperformed growisofs.)
> > -use-the-force-luke=spare=...
> I didn't use these options.
That's why i riddle why your burns do not fail in the end.
What do you get from a run of
dvd+rw-mediainfo /dev/dvd
or
xorriso -outdev /dev/dvd -toc -list_formats
with the burnt DB-R medium in /dev/dvd ?
> General question:
> Do you think I should completely change my script such that it creates lz-
> files, encrypts each of them and then writes them on an unencrypted disc?
We should first find out why your procedure produces a bad encrypted image
when you do your manual overflow handling.
In the case of no overflow it looks perfectly ok. The result has some
advantages over a home-made encryption of file content or the whole
filesystem.
(I am still looking for a stream facility which produces encryption
which can later be put on a block device and decrypted by a /dev/mapper
device. Your way of creating a big image has the disadvantage of needing
extra disk space. Cool would be to write directly to the BD-R. But it
is a block device only for reading, not when it gets written.)
I have a backup use case where i define an encryption filter and apply
it to data file content. The filter makes use of an external encryption
program which can operate on data streams. (In this case it is self-made
from some published encryption algorithm. But any stream capable encryption
program which can read the key from a file should do.)
It is for multi-session. So the /dev/mapper approach will meet more
problems. I doubt that dm-crypt handles growing devices.
Have a nice day :)
Thomas
Reply to: