Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.

Thomas Schmitt scdbackup at gmx.net
Sat Sep 22 10:04:50 UTC 2012


Hi,

Paul Menzel wrote:
> $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c
> ...
> 0000000   >  \0   0 034 001  \0  \0 001 034   0   F 034   +  \0  \0   +
> 0000020 034   F   p  \t 023 022   1   !  \0  \0  \0  \0 001  \0  \0 001
> 0000040 034  \0   I  \0   M  \0   G  \0   _  \0   2  \0   4  \0   2  \0
> 0000060   8  \0   .  \0   J  \0   P  \0   G  \0   ;  \0   1  \0   >  \0
> 0000100 224   ! 001  \0  \0 001   ! 224   @ 276   +  \0  \0   + 276   @
> 0000120   p  \t 023 022   1   !  \0  \0  \0  \0 001  \0  \0 001 034  \0
> 0000140   I  \0   M  \0   G  \0   _  \0   2  \0   4  \0   2  \0   9  \0
> 0000160   .  \0   J  \0   P  \0   G  \0   ;  \0   1  \0   >  \0  \f   '

This does not look like an ISO 9660 Primary Volume Descriptor but
rather like a snippet from a Joliet directory tree. Read as 16 bit
characters one can recognize "IMG_2428.JPG" and "IMG_2429.JPG".
They are announced to start at blocks 72752 (decimal) and 74132
(decimal). Sizes are 2825286 and 2866752 bytes.
... if i decoded these little endian 32-bit numbers correctly:
   0 034 001  \0   IMG_2428.JPG, Location of Extent
   F 034   +  \0   IMG_2428.JPG, Data Length
 224   ! 001  \0   IMG_2429.JPG, Location of Extent
   @ 276   +  \0   IMG_2429.JPG, Data Length
(The layout of directory records is documented in ECMA-119, 9.1.
 Joliet deviates from this layout mainly by using 16-bit characters
 for File Identifier.)

I really wonder how this could get to block 16 of the medium.
Brasero did order libisofs to produce a Joliet tree. But it should
be stored several blocks after block 16. Before Joliet there
should be volume descriptors and the ISO 9660 + Rock Ridge tree.

It is clear that no reader software wants to accept this as ISO 9660
filesystem.

Guessing from this single block content, i would expect that a
few hundred kilobytes of the image start have not been written
onto the medium. Most simple explanation for this would be that they
were not transmitted from libisofs to libburn. But i riddle how
this could be possible.


> PS: Is there any way to rescue the broken media, that means to correctly
> finish the burning process?

The medium is irreversibly closed.
The problem seems to be in lost data blocks.
(One could try to retrieve the JPEGs. If the loss is only about
 data at the image start, then it should be possible to guess names
 from the remaining part of the Joliet tree.)


> $ dvd+rw-mediainfo /dev/sr1

The output looks totally normal. Medium is ok.


> I think I forgot to add that the burner and the same DVD medium were
> used successfully with for example K3b and I also think xorriso.

We have no special indication of any malfunction of burner or medium.
There are just not the right bytes stored at the right block addresses.

A further test with xorriso would be welcome. Just to be sure.


Have a nice day :)

Thomas



More information about the pkg-gnome-maintainers mailing list