Re: Burning and mounting written BDs

[Thomas Schmitt]

Hi,

happy new year !


> libisofs: FATAL : Image is most likely damaged. Calculated/written tree end
> address mismatch.
> libisofs: FATAL : Image is most likely damaged. Calculated/written image end
> address mismatch.
> ...
> checking that, I only get
> libburn : WARNING : Last session on media is still open.
> xorriso : FAILURE : Cannot read ISO image tree

Regrettably the metadata of the ISO filesystem are unusable by a difference
between predicted block addresses and really written block addresses of the
files and at least some of the directories.
This matches a bug which was fixed a year ago.

Other than stated yesterday, -for_backup was not the only possible way to
trigger that bug. If experiments show it even without -for_backup, then
this does not disprove the theory that you lost a BD-R DL to this bug.
(Grrr ... i should have remembered and warned.)

So in any case please try whether xorriso-1.5.6 works better for you.
This experiment is possible without interfering with the installed
version of xorriso and its main libraries.

Getting and building GNU xorriso-1.5.6:

1: Create a work directory, download tarball, and verify it:

    cd "$HOME"
    mkdir xorriso_dir
    cd xorriso_dir

    wget https://www.gnu.org/software/xorriso/xorriso-1.5.6.pl02.tar.gz
    wget https://www.gnu.org/software/xorriso/xorriso-1.5.6.pl02.tar.gz.sig

    gpg --keyserver keyserver.ubuntu.com --recv-keys ABC0A854
    gpg --with-fingerprint --verify xorriso-1.5.6.pl02.tar.gz.sig

  gpg --verify should then say:
    gpg: Good signature from "Thomas Schmitt <scdbackup@gmx.net>"
    Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D D029 E9CB DFC0 ABC0 A854

2: Build the binary:

    tar xzf xorriso-1.5.6.pl02.tar.gz
    cd xorriso-1.5.6
    ./configure --prefix=/usr
    make

3: Test the result for willingness to run:

    ./xorriso/xorriso -version

  should say:

    GNU xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project.

  Running the installed xorriso should still tell version 1.5.4:
    xorriso -version

4: Now test whether version 1.5.6 does a better job with your input

    "$HOME"/xorriso_dir/xorriso-1.5.6/xorriso/xorriso \
       -outdev "stdio:/dev/null" \
       -for-backup \
       -blank as_needed \
       -speed 4b \
       --map ./bildebackup-2023/ /Bilder \

If this runs without the error message about "Calculated/written"
addresses, then you may either make another test with a data file as
output, like
    -outdev "$HOME"/bildebackup.iso
and mount this data file afterwards:

    sudo mount "$HOME"/bildebackup.iso /mnt/test/

Or you may try a real burn run with
    -outdev /dev/sr0
and the trailing tray dance commands
    -commit -eject all -outdev /dev/sr0

If xorriso-1.5.6 works without problems, then consider to uninstall the
Debian provided xorriso and run as superuser:

    cd "$HOME"/xorriso_dir/xorriso-1.5.6
    make install

(Years later you might have to remember that you need to uninstall GNU
xorriso before you can install an even newer version of Debian's
dynamically linked xorriso.)

(I did not make cosmetic corrections to your original xorriso arguments,
although it would be better to have -for_backup as first argument, just
in case you ever do multi-session by using -dev instead of -outdev.)

------------------------------------------------------------------------
Bug Background:

In the commit list of libisofs i find this candidate:

  13 Dec 2022  [d35435b]
  libisofs/rockridge.c
  Bug fix: Size of further CE area was calculated wrong if its CE entry ended
           exactly at a block boundary

It would match the fact that already the end of the file tree data shows
a mismatch of prediction and actual writing.

CE entries are produced when directory records get longer than 255 bytes.
An ISO 9660 directory record is a combination of inode and dirent. It
describes a single file or a part of it.
xorriso before version 1.5.6 offered an oppurtunity for miscalculation if
more than one block per directory was filled by CE entries. Chances to get
hit are in the range of 1:50 for each further CE block needed by the
directory.

Reason for long directory records and thus for multiple CE blocks per
directory can be peculiarities of the metadata of the input files:
- Long file names
- Long target paths of symbolic links
- Many extended file attributes (attr(5), acl(5))
The first two reasons happen without -for_backup. The third one is only
possible if -for_backup (or -hardlinks, -acl, -xattr, -md5) is given.

I encountered the problem a year ago after many years of happy backuping.
Hopefully i fixed it in xorriso-1.5.5 which led to release xorriso-1.5.6.
(Present in Debian Testing. Thus expected for Debian 13.)

------------------------------------------------------------------------

I will next write a reply to the other aspects of your mail of yesterday.


Have a nice day :)

Thomas