Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed

[Thomas Schmitt]

Hi,

Adalbert Hanßen wrote:
> BTW: Wenn Sie deutsch sprechen, können wir auch auf DE weitermachen.

Machen wir, wenn es auf englisch nicht mehr geht. But for now and on
the public mailing list, english is the language to use.


> What is the next step?

First we should examine the medium. Insert a blank one (it will not be
used up) and do:

  xorriso -outdev /dev/sr0 -list_profiles out -toc

Above run should report something about the general capabilities which
are advertised by the drive (and inquired by -list_profiles "out"):

  Drive type   : vendor 'HL-DT-ST' product 'BDDVDRW GGC-H20L' revision '1.03'
  Profile      : 0x0040 (BD-ROM)
  Profile      : 0x0050 (HD-DVD-ROM)
  Profile      : 0x0012 (DVD-RAM)
  Profile      : 0x0011 (DVD-R sequential recording)
  Profile      : 0x0015 (DVD-R/DL sequential recording)
  Profile      : 0x0016 (DVD-R/DL layer jump recording)
  Profile      : 0x0014 (DVD-RW sequential recording)
  Profile      : 0x0013 (DVD-RW restricted overwrite)
  Profile      : 0x001A (DVD+RW)
  Profile      : 0x001B (DVD+R)
  Profile      : 0x002B (DVD+R/DL)
  Profile      : 0x0010 (DVD-ROM)
  Profile      : 0x0009 (CD-R) (current)
  Profile      : 0x000A (CD-RW)
  Profile      : 0x0008 (CD-ROM)
  Profile      : 0x0002 (Removable disk)

Then xorriso command -toc tells about the drive, the medium, and its state:

  Drive current: -outdev '/dev/sr0'
  Drive type   : vendor 'HL-DT-ST' product 'BDDVDRW GGC-H20L' revision '1.03'
  Drive id     : 'K5C88LJ1616 '
  Media current: CD-R
  Media product: 97m34s23f/79m59s73f , Mitsubishi Chemical Corporation
  Media status : is blank
  Media blocks : 0 readable , 359846 writable , 359846 overall
  Media summary: 0 sessions, 0 data blocks, 0 data,  703m free

Because the medium is blank, no sessions and tracks are reported yet.

So: What does xorriso tell about your drive and medium ?

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

What we know so far from
  https://askubuntu.com/questions/1131646/xfburn-fails-burn-run-failed
is:

It looks like drive and medium do not work well together:

  ** (xfburn:12230): WARNING **: 18:12:50.707: [FATAL] 131357:
  SCSI error on write(32,16): [5 30 05] Illegal request. Cannot write medium,
  incompatible format.
  (0)

The text in middle two lines stems from libburn. First and last line text
was added by Xfburn.

"write(32,16)" tells that the error was reported by the drive when the
third SCSI command WRITE was sent to the drive. The first WRITE wrote to
block 0, the second WRITE wrote to block 16. Both were obviously accepted.
But at the third WRITE, the drive signalled error and gave the code 5,30,05.
The KEY value 5 means SCSI error class "Illegal request".
The ASC, ASCQ values are in the SCSI error list as
  30 05 CANNOT WRITE MEDIUM  INCOMPATIBLE FORMAT

A neighbor is
  30 06 CANNOT FORMAT MEDIUM  INCOMPATIBLE MEDIUM
which is the normal indication that a wrong medium type is in the drive.
E.g. a BD-R in a DVD-only drive.

So obviously the drive dislikes the medium state. But only after accepting
two WRITE commands. Probably the inspection of the medium gave the drive
a good feeling but the attempt to start physical writing yielded some
bad surprise.


> Today after rebooting and re-inserting this CD and after sudo blkid I
> see a line
>   /dev/sr0: UUID="2019-04-08-18-12-20-00" LABEL="Bilder 2019-03-1"
>   TYPE="iso9660"

This info stems from the ISO 9660 Primary Volume Descriptor at block 16
of the medium (2048 bytes per block). So the second WRITE at least
partially succeeded.


> $ badblocks -v /dev/sr0
> 60 61 62 63 64 ...

man 8 badblocks says:

  OPTIONS
       -b block-size
              Specify the size of blocks in bytes.  The default is 1024.

So it complains about CD blocks 30, 31, 32 ...
Block 30 and 31 were written by the same WRITE that wrote block 16.
Blocks 32 ff. would have been written by the failed third WRITE command.

So it looks like physical writing already failed during the second WRITE
command. The drive took notice some microseconds later.

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

Answers to your questions:

a) Is it possible to write CDs with xfburn with long filenames?

Yes. libisofs adds Rock Ridge information to the ISO 9660 directory tree,
which enables filenames up to 255 characters, paths up to 1024 characters,
POSIX attributes like timestamps and access permissions.
When an ISO 9660 is mounted by the Linux kernel, then Rock Ridge is
preferred over Joliet by default.

b) Is the presence of files with long file names or containing non-ASCII
characters an explanation for this failure?

No. Whatever is the reason, it is between drive and medium. Maybe libburn
is to blame by doing some wrong preparations. But ISO 9660 and your input
are clearly out of suspicion.

c) If the answer to a) is Yes: What do I have to do in order to write such
files to a CD?

The best hope for quick success is to use a different drive or media from
a different pack. If possible from other manufacturers.

Your drive (MATSHITA DVD-RAM UJ8C0) seems to be not overly old. It's a slim
drive. The fat ones are usually more reliable and endurant. Especially if
they are not carried around with a laptop.

About the media we will learn from xorriso -toc. The trade mark on the
pack is often quite unrelated to the actual manufacturer.

d) If there is an answer to c): Isn't it a bug of xfburn that it does not
provide an error message before it actually tries to burn such files and
destroys the CD blank in doing so?

For now it looks as if the drive is surprised itself. Let's see what it
says about the perceived medium type and state.

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

About the thread
  https://forums.gentoo.org/viewtopic-t-819687-start-0.html
i can say that it is good only for learning how to get to see the error
message of Xfburn.
The original poster states to have repaired Xfburn by installing wodim.
That's nonsense, as Xfburn only can use libburn. Brasero or K3B can use
wodim, cdrecord, growisofs, cdrdao, cdrskin, xorrecord, ...

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

Probably futile attempts:

We could try with xorriso to perform your burn job.

Tell me which directory trees or single data files you want to put
to which file addresses on the CD. I will then propose a run like

  xorriso -for_backup -outdev /dev/sr0 \
          -map /path/on/disk /path/in/iso \
          ... more -map commands if needed ...

But for now i have few hope that it would work better if nothing changes
with drive and medium.


You could install "wodim", let xorriso make an ISO image file, and use
wodim for burning to CD. wodim is a clone of cdrecord, still well suitable
for CD burning. Both do not use libburn but rather Joerg Schilling's
program code to control the drive by SCSI commands.

  xorriso -for_backup -outdev image.iso \
          -map /path/on/disk /path/in/iso \
          ... more -map commands if needed ...

When the file "image.iso" is produced, the burn run would look like

  wodim -v dev=/dev/sr0 fs=8m -sao -eject padsize=300k image.iso

It would be a surprise to me, if this burn run succeeds.
If so, then i'd ask you for deeper experiments, like comparison of wodim's
SCSI commands with those of libburn. (wodim option -V, xorriso command
-scsi_log "on". I will give preciser instructions if needed.)

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

Have a nice day :)

Thomas