Bug 432025

Summary: Bug in mkisofs causes dvd+-rw test to fail
Product: [Retired] Red Hat Hardware Certification Program Reporter: David Swegen <dswegen>
Component: Test Suite (tests)Assignee: YangKun <ykun>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5CC: gasmith, rick.hester, rlandry, shengliang.lv, tao, tellis
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: hts-5.2-16.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-20 17:10:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Fixes the issue none

Description David Swegen 2008-02-08 14:14:07 UTC 
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)
Comment 1 Peter Palmer 2008-02-26 17:55:30 UTC 
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...
Comment 2 YangKun 2008-02-29 08:09:10 UTC 
If I understand correctly, this is actually a mkisofs bug. Should we close it as
duplicate of bug#174667  ?
Comment 3 Peter Palmer 2008-02-29 10:07:52 UTC 
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.
Comment 8 YangKun 2008-03-05 06:57:05 UTC 
*** Bug 416011 has been marked as a duplicate of this bug. ***
Comment 9 Greg Nichols 2008-03-10 16:40:00 UTC 
Fixed HTS 5.2 R5
Comment 11 Jeremy West 2008-06-04 21:00:58 UTC 
*** Bug 450030 has been marked as a duplicate of this bug. ***
Comment 13 Hao Liu 2008-06-17 07:54:41 UTC 
Dave,
  would you please provide the exact NVR of the hts package, thank you.
  according to the comment #9, I assume it's the bug of hts5.2-4, but I can't
reproduce the bug with that package.
Comment 14 David Swegen 2008-06-17 10:08:52 UTC 
We're trying to get hold of that info now. Note that there may be problems
reproducing the problem, as it was always hardware and arch dependent.
Comment 15 Hao Liu 2008-06-18 06:04:42 UTC 
Dave,
  Good point, if you have a already setup environment for testing, please let me
know, thanks a lot.
Comment 16 David Swegen 2008-06-19 11:45:51 UTC 
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.
Comment 17 Lawrence Lim 2008-06-20 17:10:11 UTC 
Resolving as appropriate testing env cannot be set up.