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 kernel driver, i deem it improbable that the properly decrypted > UDF format would be in such a bad shape. > > So it looks like decryption uses a wrong key when you mount it again. > > Consider to exercise the procedure without encryption to make sure > that the resulting $IMGFILE are recognizable UDF and contain the files > which you expect. Just to be sure. > > > my last backups consist of two discs each, and I cannot > > mount the first one but I can mount the second one for each of them > > Hard to explain. > > I see a theoretical race condition in the sequence of > IMGLOOP=`losetup -f` > and > losetup $IMGLOOP $IMGFILE > but cannot make up a situation where this would lead to silent failure > to encrypt. > > What does > file "$IMGFILE" > say ? > > Consider to use --verbose and/or --debug with the two runs of > cryptsetup luksOpen. Maybe you see a reason why they are at odds. > > > Have a nice day :) > > Thomas
Well, I can provide you with: file "$IMGFILE" LUKS encrypted file, ver 2 [, , sha256] UUID: 835847ff-2cb3-4c6d-aa04- d3b79010a2d3 and I also compared cryptsetup luksOpen -r --verbose --debug /dev/dvd BDbackup for two discs, one mounting without any problem, one with the above mentioned problem. Differences are only Checksums of the LUKS header, DM-UUIDs and udev cookie values - as expected, I would say. I also tried mounting again, and here is once again output from dmesg: mount -t udf /dev/mapper/BDbackup /mnt/BDbackup [62606.932713] UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found [62606.932717] UDF-fs: Scanning with blocksize 512 failed [62606.932860] UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found [62606.932862] UDF-fs: Scanning with blocksize 1024 failed [62606.932982] UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found [62606.932984] UDF-fs: Scanning with blocksize 2048 failed [62606.933111] UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found [62606.933113] UDF-fs: Scanning with blocksize 4096 failed and if I skip VRS (from man mount: Ignore the Volume Recognition Sequence and attempt to mount anyway.): mount -t udf -o novrs /dev/mapper/BDbackup /mnt/BDbackup [62614.207353] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor found [62614.207358] UDF-fs: Scanning with blocksize 512 failed [62614.207667] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor found [62614.207670] UDF-fs: Scanning with blocksize 1024 failed [62614.207920] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor found [62614.207922] UDF-fs: Scanning with blocksize 2048 failed [62614.208202] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor found [62614.208204] UDF-fs: Scanning with blocksize 4096 failed [62614.208205] UDF-fs: warning (device dm-10): udf_fill_super: No partition found (1) So now I'm stuck again, but maybe one little step later... Reply to David Christensen's comment: Thank you for your suggestions, well, most of them are not new to me and I'm following them already; especially as my solution is basically a bash script which I also put into git ;-) Years ago when I started with this solution, I tested it and I could restore all files successfully. Since the script is unchanged, I didn't expect that kind of problem now. Encrypting each file separately would be another way, but for me it has always been nice to just have to decrypt the whole disc once, on the cli, the same way as I can do it with my external hard disks and so on... My use case - by the way, and this might be of interest for others as well - is backuping up all the typical family stuff... files, images, mails and so on, and I do bi-weekly backups alternating on several encrypted HDDs, stored offsite (at my office desk). Additionally I started writing encrypted BD discs, just to have incremental read only backups, created every 3 - 6 months and stored offsite in the office as well... Thanks again for any hints... (Please add me to your reply in CC as I'm currently not subscribed to the list anymore.) Bernd
