Re: growisofs fail to burn second session: why and how to solve?

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> 1st session: burnt successfully.

How many bytes is it supposed to contain ?


> newly purchased DVD+R DL (from TDK) burnt in the newly purchased LG
> Portable Super Multi GP08NU20 by first generating iso image

So far this is a conventional approach.

> and then wodim -multi

This is somewhat courageous.
wodim is more into DVD-R. Option -multi is normally not in its DVD repertoire.


> mount the DVD+R DL, I got a lot of error message [1] in kernel dmesg
> ...
>     READ TRACK INFORMATION[#1]:
>     Track Size:            812352*2KB
> ...
>   [  786.682739] sr 4:0:0:0: [sr1] CDB: Read(10): 28 00 00 0c 65 44 00 00
02 00
>   [  786.682768] end_request: I/O error, dev sr1, sector 3249424
>   [  786.682789] Buffer I/O error on device sr1, logical block 812356
>   ...
>   [  821.402220] ISO 9660 Extensions: RRIP_1991A

For some reason the ISO image points to an address outside of the first
track. Thus my question how large that first session is supposed to be.
Did all data of the ISO image get written ?


The next track is reserved to the very same size as number 1.
But yet completely unwritten:

>    READ TRACK INFORMATION[#2]:
>     Track State:           reserved
>     Track Start Address:   812368*2KB
>     Next Writable Address: 812368*2KB
>     Free Blocks:           812352*2KB
>     Track Size:            812352*2KB

This seems to confuse growisofs:

>     almustafa@orphalese:~$ growisofs -M /dev/sr1 -iso-level 3 -old-root / -R
> -exclude-list .exclude.lst -v -V ZWW_BKUP -dry-run .
>     :-[ READ SESSION INFO failed with SK=5h/INVALID FIELD IN CDB]:

(Note: -dry-run will not prevent real burning with DVD+R. )

In source code growisofs_mmc.cpp, Andy Polykov states:

    // All manuals say the data is fabricated, presumably implying
    // that one should use another command. But we stick to this one
    // because kernel uses this very command to mount multi-session
    // discs.
    //
    cmd[0] = 0x43;              // READ TOC
    cmd[2] = 1;                 // "Session info"
    cmd[8] = 12;
    cmd[9] = 0;
    if ((err=cmd.transport (READ,buf,12)))
        sperror ("READ SESSION INFO",err),
        exit (FATAL_START(errno));

Well, Andy, it was not the right choice of command in this case. :))
READ DISC INFORMATION and READ TRACK INFORMATION throw no error.
Nevertheless, the reported track structure looks strange.


I am unsure whether my own software would cope better with this media
if not being helped by the user.
The reserved but unused track would probably lure it into an attempt
to read at block 812368.
This could probably be avoided by
   xorriso -load session 1 ...other.options...

Next stumblestone could be the answer to READ TRACK INFORMATION for track
0xff. Will it yield 812368 or 1624736 ? 812368 would be rather bad.
With 1624736 one could probably append another session and thus just waste
the 1.6 GB of track 2 inbetween.

If you want to give xorriso or cdrskin a try then first post the outcome
of their track catalog commands
  xorriso -outdev /dev/sr2 -toc
  cdrskin -v dev=/dev/sr2 -minfo
which both will tell the perceived next writeable address. 1624736 would
give hope.


> Executing 'genisoimage -C 16,0 -M /dev/fd/3 -iso-level 3 -old-root / -R
> -exclude-list .exclude.lst -v -V ZWW_BKUP . | builtin_dd of=/dev/sr1 obs=32k
> seek=0'
>
> The error message is specially confusing for the unreasonable -C 16,0
> part.

It seems that growisofs now got a different reply to the request for a
fabricated Table-Of-Content.
At least it now decided to base the new session on track 0.

last_session_start 16 is a growisofs peculiarity because mkisofs and
its clones begin searching for volume descriptors 16 blocks too early.

But next_sess_start 0 is clearly nonsense.
So the fabricated TOC from that drive was not digestible either.

> genisoimage: No such file or directory. Cannot open '/dev/fd/3'. Cannot
> open SCSI driver.

growisofs is supposed to have opened file descriptor 3 to /dev/sr2
before forking genisoimage. Obviously there is no placeholder file for
that open descriptor in /dev/fd/. So i assume it was not opened.


Normally growisofs works well with DVD+R (DL).
So for now i would assume the problem stems from the wodim run.

What happens if you treat a fresh DVD+R DL by growisofs only ?


Have a nice day :)

Thomas