Description of problem:
When running the dvd writer test the cdrom.py calls mkisofs (on line 354) to
find the amount of space that is going to be used. But due to bug #193916 extra
output appears, which the script doesn't cope with (the output is something like
"Unknown file type (unallocated) /usr/share/.. - ignoring and continuing." with
the actual required value on the next line).
Version-Release number of selected component (if applicable):
How reproducible:
On machines that have this occuring, every time, and so far only seen on rhel5.1
x86_64 on the dvd portion of the test (cd-rw testing works fine).
Steps to Reproduce:
1. Run cdrom test on affected machine/os
2.
3.
Actual results:
The test will fail on the dvd section of the test with the following output in
the cdrom test logfile:
Driver flags : SWABAUDIO BURNFREE
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `{ mkisofs -quiet -R /usr/share | cdrecord -v -sao driveropts=bu
rnfree dev=/dev/hda fs=32M tsize=Unknown file type (unallocated) /usr/share/.. -
ignoring and continuing.'
+++ Write options : -sao driveropts=burnfree
+++ Error: Write disk failed !
Expected results:
Test should complete successfully
Additional info:
Currently I'm having to work round this by obtaining the required value by hand,
calling 'mkisofs -quiet -R -print-size /usr/share' if the test being run is dvd,
and then hardcoding that value into the script, like this:
if deviceType == "dvd":
cdblocks = 12345
else:
cdblocks=commands.getoutput("mkisofs -quiet -R -print-size %s" % fileDir)

Created attachment 295965[details]
Fixes the issue
The issue is caused due to additional information being returned on the command
line. It appears (can anyone confirm for sure?) that all errors and other
diagnostic output are printed before the actual result i.e the size is printed
on a line of its own at the very end.
This code splits the output into an array and assigns the last item to
cdblocks. This works on both the machine that had the original issue and on a
machine that doesn't.
Hope this helps...

The bug in mkisofs causes the script to fail because the script does not check
the data returned from the mkisofs command. When working correctly mkisofs
should return one line of output contaning the correct size. However due to the
bug, an error line is returned before the line containing the size. The script
does not detect this and this causes the next mkisofs command to fail.
The patch I provided ensures that the script uses the last line returned. This
works perfectly well on machines that do not have the same mkisofs issue. The
patch fixes the problem and has no nasty side effects.
I see no good reason for not fixing the script so that it can cope safely with
badly returned data.

I've had a look, and I believe the version we used was hts-5.0-48 (so quite old).
Unfortunately the machines we were testing have since been returned to FSC, so
some other way of testing will have to be found. Apologies for this.