Hello again
First of all, I tested all my BD backup discs now, and there are no problems
from #1 (2017) - #12 (05/2018) as well as #14 - #17 (2019-05/2020).
# 13 from 03/2019 fails.
#1 to #10 are all from 05/2017, they're the first BD backup at all and I assume
I used some manual workflow back th
to...@tuxteam.de (12022-07-10):
> But then, always doing sync twice looks like a very mild measure, and
> far cheaper than seeing a therapist. Especially given that the second
> sync will typically be very quick. If it's working, I'd go with that :)
>
> Since writing to USBs for me mostly involves
Hi,
B.M. wrote:
> Do I understand correctly, you say that this Pioneer drive doesn't work well
> with Verbatim BD-RE, i.e. their rewriteable BDs.
Yes. The problem is with the high reading speed of the drive and with
a physical flaw of Verbatim BD-RE (CMCMAG/CN2/0).
The flaw is that there are lett
> Good questions. Make some experiments. :))
> At least the manual intervention is a good suspect because it occurs exactly
> when you get undecryptable images.
Will do later.
> I see in your script:
>
> umount /mnt/BDbackup
> cryptsetup luksClose /dev/mapper/BDbackup
> losetup -d $IM
On 7/10/22 12:10, to...@tuxteam.de wrote:
... I do use sync much less these days after having discovered dd's oflag=sync.
+1
When doing pipelines involving 'dd bs=1M ...', I have also found
'iflag=fullblock' to be useful.
David
On Sun, Jul 10, 2022 at 07:01:49PM +0200, Nicolas George wrote:
> fxkl4...@protonmail.com (12022-07-10):
> > I would have nightmares about corrupt data haunting me :)
>
> Well, you can see a therapist, or you can conduct the experiment I
> suggested:
But then, always doing sync twice looks like a
fxkl4...@protonmail.com (12022-07-10):
> I would have nightmares about corrupt data haunting me :)
Well, you can see a therapist, or you can conduct the experiment I
suggested:
> > You can check for yourself: mount a slow USB stick, create file that is
> > just large enough to fit in memory with
On Sun, 10 Jul 2022, Nicolas George wrote:
> fxkl4...@protonmail.com (12022-07-10):
>> I'm just flapping my gums
>> As a systems administrator for UNIX systems I wrote more than a few scripts
>> Many time I found it necessary to put a sleep between operations
>> Several decades ago I was taught to
fxkl4...@protonmail.com (12022-07-10):
> I'm just flapping my gums
> As a systems administrator for UNIX systems I wrote more than a few scripts
> Many time I found it necessary to put a sleep between operations
> Several decades ago I was taught to type sync and then type sync again before
> unmo
I'm just flapping my gums
As a systems administrator for UNIX systems I wrote more than a few scripts
Many time I found it necessary to put a sleep between operations
Several decades ago I was taught to type sync and then type sync again before
unmounting a drive
The only reason I ever got was tha
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 ima
> No
> cryptsetup luksClose /dev/mapper/BDbackup
> between remove and burn ?
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?
> Andy Polyakov decided to format
Hi,
Tim Woodall wrote:
> cdromSHA=$( dd status=progress if=/dev/cdrom bs=1k count=$maxsize |
> sha1sum | cut -d' ' -f1 )
> [...]
> It's unusual, but I have had instances where the burn has completed
> without any issues but the verify has failed. When that happens I got
> several failures close to
On Sat, 9 Jul 2022, B.M. wrote:
Verifying that your procdure with two UDF images is not the culprit would
help even if the result is boringly ok, as we expect. (Or we are in for
a surprise ...)
I don't have two UDF images.
Not been following this closely, but I do something very similar and
On 7/9/22 08:41, B.M. wrote:
If you want you can have a look at my script, I attached it to this mail...
I have written several generations of such scripts in Bourne and Perl
over the past 3+ decades. They all have obvious and inobvious
limitations and bugs.
What we both have are progra
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 followi
> > > A UDF filesystem image is supposed to bear at its start 32 KiB of zeros.
>
> B.M. wrote:
> > This is indeed the case:
> > [...]
> > For a readable disk, this look like you said: Only zeros.
>
> So it looks like at least a part of the problem is decryption.
Agreed
> > > If UDF does not work
Hi,
i wrote:
> > A UDF filesystem image is supposed to bear at its start 32 KiB of zeros.
B.M. wrote:
> This is indeed the case:
> [...]
> For a readable disk, this look like you said: Only zeros.
So it looks like at least a part of the problem is decryption.
> > If UDF does not work even unen
> > file "$IMGFILE"
> > LUKS encrypted file, ver 2 [, , sha256] UUID:
> > 835847ff-2cb3-4c6d-aa04-d3b79010a2d3
> So it did not stay unencrypted by mistake.
> (I assume this is one of the unreadable images.)
It looks like this for both, the readable and the unreadable discs.
> > mount -t udf -o no
Hi,
B.M. wrote:
> file "$IMGFILE"
> LUKS encrypted file, ver 2 [, , sha256] UUID:
> 835847ff-2cb3-4c6d-aa04-d3b79010a2d3
So it did not stay unencrypted by mistake.
(I assume this is one of the unreadable images.)
> mount -t udf -o novrs /dev/mapper/BDbackup /mnt/BDbackup
> [62614.207920] UDF-f
On Montag, 4. Juli 2022 19:51:57 CEST Thomas Schmitt wrote:
> Hi,
>
> B.M. wrote that dmesg reports:
> > UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found
>
> That's a very early stage of UDF recognition.
> Given that you were able to copy files into that UDF image by help of
> the Linux k
On 7/4/22 05:36, B.M. wrote:
Hello
I create encrypted backups on blu-ray discs for some years now with a bash
script, but now I encountered a problem mounting some of these discs (but not
all of them - in fact, my last backups consist of two discs each, and I cannot
mount the first one but I can
Hi,
B.M. wrote that dmesg reports:
> UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found
That's a very early stage of UDF recognition.
Given that you were able to copy files into that UDF image by help of
the Linux kernel driver, i deem it improbable that the properly decrypted
UDF format
Hello
I create encrypted backups on blu-ray discs for some years now with a bash
script, but now I encountered a problem mounting some of these discs (but not
all of them - in fact, my last backups consist of two discs each, and I cannot
mount the first one but I can mount the second one for each
24 matches
Mail list logo
