Re: Problem mounting encrypted blu-ray disc or image
Hi,
i wrote:
> > No
> > cryptsetup luksClose /dev/mapper/BDbackup
> > between remove and burn ?
B.M. wrote:
> To be honest, I cannot say for sure, so maybe yes. But: what would be the
> implication? The fs inside is already unmounted, is cryptsetup luksClose
> modifying anything within the image?
Good questions. Make some experiments. :))
At least the manual intervention is a good suspect because it occurs exactly
when you get undecryptable images.
I see in your script:
umount /mnt/BDbackup
cryptsetup luksClose /dev/mapper/BDbackup
losetup -d $IMGLOOP
#
# Step 5: Burn to BD-R
#
and would expect that the three lines are there for a reason.
Do i understand correctly that the overflow happens in line 173
with the tar run ?
tar cf - -C "`dirname "$line"`" "`basename "$line"`" | plzip > "$zipfilename1"
If so: What happens next ? Does the script abort without cleaning up ?
(I.e. no unmounting, closing, and de-looping by the script ?)
> > dvd+rw-mediainfo /dev/dvd
> INQUIRY: [PIONEER ][BD-RW BDR-209D][1.30]
That's the killer of Verbatim BD-RE. (If you buy BD-RE, then take any other
brand, which will probably be made by Ritek.)
It's also a super fast BD-R burner and super loud with 10x speed.
If you ever use it with unformatted BD-R by
growisofs -use-the-force-luke=spare=none ...
then consider to curb its speed by e.g. -speed=6
> Mounted Media: 41h, BD-R SRM+POW
So it is a BD-R in the default formatting state of growisofs.
> Speed Descriptor#0: 00/12088319 R@12.0x4495=53940KB/s
The speed descriptor says that it is valid from block 0 to 12088319.
That would be the size of 23610 MiB achieved by growisofs option
-use-the-force-luke=spare=min
I have no idea from growisofs source code in
https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/growisofs_mmc.cpp/#L713
why it has chosen this size. I'd expect it came to line 738
i = 8; // grab default descriptor
and not to the lines under 721
if (spare == 0) // locate descriptor with maximum capacity
But it explains why your burn runs succeeded.
(Looking at the patches confuses me even more. One by me is present twice:
https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/10-blue-ray-bug713016.patch/
https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/fix_burning_bd-r_discs.patch/
and one other aims to prevent the SRM+POW formatting which you get
https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/ignore_pseudo_overwrite.patch/
)
> READ TRACK INFORMATION[#1]:
> Track State: partial incremental
> Track Start Address: 0*2KB
> Free Blocks: 0*2KB
> Track Size: 12032000*2KB
That's the 24064000K of your image file. All seems well, as far as the BD-R
is concerned.
> READ TRACK INFORMATION[#2]:
> ...
> Next Writable Address: 12032000*2KB
> Free Blocks: 56320*2KB
There would still be 100 MB free for another session.
(But don't mess with good backups which are not intended as multi-session.)
> I went for the image file solution, which
> - while not being "pretty" - should at least work and I'm not disk space
> limited (at least as far as the size of a BD is concerned).
With BD-RE media and the patience for <= 4.5 MB/s write speed you could
install /dev/mapper/BDbackup directly on /dev/dvd, mount and populate it
like the encrypted image, umount, execute sync(1), cryptsetup luksClose,
and another sync just to be sure.
The BD-RE has to be already formatted.
Default size by growisofs' companion:
dvd+rw-format /dev/dvd
(To request other sizes you'll have to study
https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/dvd%2Brw-format.cpp/#L258
from where i guess that option -spare=min brings 23610 MiB.)
With xorriso i would do:
xorriso -outdev /dev/dvd -format by_size_23610m
Afterwards the Linux kernel should be able to handle it without the need
for a burn program. But also without the neat streaming of image writing
and without the opportunity to get full 2x speed (9 MiB/s) by disabling
Defect management.
Have a nice day :)
Thomas
Reply to: