I have a similar and probably related problem so I will describe it here and not create another bug in the hope it will help the devs pinpoint the causes. I recently upgraded a server from dapper to hardy after which my DVD-R burning archive script starting failing. The script for dapper ran overnight, used mkisofs and worked a treat. The script was designed for non-computer people - they would periodically put a blank DVD-R in the drive in the evening. The return code from mkisofs was detected by the script. If the mkisofs run succeeded (that is, a blank disk had been inserted the previous evening), the script ejected it ready to be removed and filed the next day. If it failed, the script presumed it was because no media had been loaded and failed quietly. The script needed to be changed for hardy - mkisofs was replaced by growisofs. I overcame bug 233942 by replacing genisoimage 1.1.6-1ubuntu6 with genisoimage 1.1.6-1ubuntu3. However, there are clearly still some other problems with DVD burning on hardy. Here are some of the symptoms I see: 1. The growisofs/genisoimage relationship does not seem quite right. An eject command after the growisofs command appears to be executed before genisoimage terminates. Indeed it seems to execute almost before genisoimage starts. See my thread here: http://ubuntuforums.org/showthread.php?t=963701 2. growisofs always seems to return zero. 3.. If I run the archive script manually after loading a blank DVD-R, it creates a legitimate burned disk which I can read successfully if removed from the drive at that point. 4. If the script is run via cron overnight, I believe the disk is OK just as the result from 2. above is. Here are the key parts of the log which is emailed to me: Executing 'genisoimage -r -J -joliet-long -V othona311008 -ldots /home/core/My Documents /home/othona_backups | builtin_dd of=/dev/dvd obs=32k seek=0' Warning: creating filesystem that does not conform to ISO-9660. I: -input-charset not specified, using utf-8 (detected in locale settings) Using BOOKI000.SBD for ./rr_moved/Bookings.sbd (Bookings.sbd) Using HOSTI000.SBD for ./rr_moved/Hosting stuff.sbd (Hosting stuff.sbd) Using ONGOI000.SBD for ./rr_moved/Ongoing stuff.sbd (Ongoing stuff.sbd) . . 99.15% done, estimate finish Fri Oct 31 03:39:11 2008 99.48% done, estimate finish Fri Oct 31 03:39:11 2008 99.81% done, estimate finish Fri Oct 31 03:39:10 2008 Total translation table size: 0 Total rockridge attributes bytes: 916985 Total directory bytes: 2508800 Path table size(bytes): 14310 Max brk space used 7bc000 1517890 extents written (2964 MB) /dev/dvd: flushing cache /dev/dvd: updating RMA /dev/dvd: closing disc However, if the disk is left in the drive and the script runs 24 hours later on the same disk, it appears to try to burn the disk again (and I think it partially succeeds - see below) but fails as follows: Executing 'genisoimage -r -J -joliet-long -V othona011108 -ldots /home/core/My Documents /home/othona_backups | builtin_dd of=/dev/dvd obs=32k seek=0' Warning: creating filesystem that does not conform to ISO-9660. I: -input-charset not specified, using utf-8 (detected in locale settings) Using BOOKI000.SBD for ./rr_moved/Bookings.sbd (Bookings.sbd) Using HOSTI000.SBD for ./rr_moved/Hosting stuff.sbd (Hosting stuff.sbd) Using ONGOI000.SBD for ./rr_moved/Ongoing stuff.sbd (Ongoing stuff.sbd) . . 16.45% done, estimate finish Sat Nov 1 03:42:29 2008 16.78% done, estimate finish Sat Nov 1 03:42:27 2008 17.10% done, estimate finish Sat Nov 1 03:42:24 2008 :-[ WRITE@LBA=3c2f0h failed with SK=3h/ASC=80h/ACQ=04h]: Input/output error :-( write failed: Input/output error /dev/dvd: flushing cache /dev/dvd: updating RMA /dev/dvd: closing disc What is very strange is if the DVD-R is examined in daylight, the originally burned (dark) circular area is visible but superimposed on it is a smaller circular area which is even darker as if that smaller central area has been burned again. After the second run, the DVD-R is not loadable or readable on any Linux or Windows system. 5. I have another recently-upgraded-from-dapper-to-hardy server which uses the same script to burn archive CD-Rs (note *not* DVD-Rs) and it does not have the double burning problem described above. I think it does however also have the eject-before-burning-complete problem. I too have concerns about how this problem can remain undiagnosed/unfixed for so long. growisofs appears to behave quite differently to the original mkisofs - it is a pity that there was not a transition period where both were available so that mkisofs could be used in situations where growisofs did not work properly.