Bug 448291

Summary: cdrecord -pad is too short
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: cdrkitAssignee: Roman Rakus <rrakus>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: bughunt, proski, robatino, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 12:14:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jan Kratochvil 2008-05-25 10:22:36 EDT
Description of problem:
If I create a CD-RW image with -pad the bytes near the end are later randomly
unreadable.

Version-Release number of selected component (if applicable):
wodim-1.1.6-11.fc9.x86_64
kernel-2.6.25.3-18.fc9.x86_64

How reproducible:
Sometimes.

Steps to Reproduce:
1. cdrecord -v -data -pad /tmp/79uj28uc.iso # tried even with -dao
2. Eject, insert the media.
3. Many times: Many times: cmp /dev/cdrom /tmp/79uj28uc.iso
  
Actual results:
cmp: EOF on /tmp/79uj28uc.iso
/dev/cdrom /tmp/79uj28uc.iso differ: byte 4837377, line 14223
/dev/cdrom /tmp/79uj28uc.iso differ: byte 4847633, line 14223
cmp: EOF on /tmp/79uj28uc.iso

Expected results:
Always: cmp: EOF on /tmp/79uj28uc.iso

Additional info:
It works fine if I write instead:
(cat /tmp/79uj28uc.iso;head -qc1m /dev/zero) >image.iso

Lenovo T60:
Vendor_info    : 'HL-DT-ST'
Identification : 'DVDRAM GSA-4083N'
Revision       : '1.08'

# hdparm -v /dev/cdrom

/dev/cdrom:
 IO_support    =  0 (default) 
16-bit)
 HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
 readonly      =  0 (off)
 readahead     = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
(default Fedora settings)

DVD media do not have any problems with the data at the end.
Comment 1 Jan Kratochvil 2008-05-25 10:25:03 EDT
Forgot the kernel message while trying to read the data written with just -pad:

==> /var/log/messages <==
May 25 16:18:14 host0 kernel: end_request: I/O error, dev sr0, sector 0
May 25 16:18:14 host0 kernel: printk: 49 messages suppressed.
May 25 16:18:14 host0 kernel: Buffer I/O error on device sr0, logical block 0
May 25 16:18:14 host0 kernel: Buffer I/O error on device sr0, logical block 1
May 25 16:18:14 host0 kernel: Buffer I/O error on device sr0, logical block 2
May 25 16:18:14 host0 kernel: Buffer I/O error on device sr0, logical block 3
May 25 16:18:14 host0 kernel: end_request: I/O error, dev sr0, sector 0
May 25 16:18:14 host0 kernel: Buffer I/O error on device sr0, logical block 0
May 25 16:18:17 host0 kernel: end_request: I/O error, dev sr0, sector 0
May 25 16:18:17 host0 kernel: Buffer I/O error on device sr0, logical block 0
May 25 16:18:17 host0 kernel: Buffer I/O error on device sr0, logical block 1
May 25 16:18:17 host0 kernel: Buffer I/O error on device sr0, logical block 2
May 25 16:18:17 host0 kernel: Buffer I/O error on device sr0, logical block 3
May 25 16:18:17 host0 kernel: end_request: I/O error, dev sr0, sector 0
May 25 16:18:17 host0 kernel: Buffer I/O error on device sr0, logical block 0
May 25 16:18:17 host0 kernel: end_request: I/O error, dev sr0, sector 0
May 25 16:18:17 host0 kernel: end_request: I/O error, dev sr0, sector 0
Comment 2 David Tonhofer 2009-01-02 10:05:15 EST
Crosslinking to potentially relevant stuff:

bug#447452 - F9 CD mediacheck problems
bug#448291 - cdrecord -pad is too short
bug#440343 - k3b fails to verify written data
bug#444344 - k3b problem verifying burned CD iso image
Comment 3 Andre Robatino 2009-01-02 14:37:13 EST
Looks like a duplicate of #186512.  Nice to see someone else finally confirming this, since we've been told since F7 that this was fixed.  (Although I discovered later that even with the original F7 kernel, the problem existed with CD-RWs, though not with CD-Rs.).  It still exists with F10, and on both 32- and 64-bit.
Comment 4 Andre Robatino 2009-01-02 14:38:10 EST
(Actually, if the readahead bug had been fixed, the -pad wouldn't be necessary at all.)
Comment 5 Andre Robatino 2009-01-02 16:56:34 EST
Actually, this shouldn't be considered a duplicate, since the purpose of -pad is to work around the readahead bug.
Comment 6 Jan Kratochvil 2009-01-03 03:23:53 EST
(In reply to comment #5)
> since the purpose of -pad is to work around the readahead bug.

I always assumed it is there to workaround a CD-ROM drive firmware bug, or possibly even just required for the principle of media reading (although in such case it could be considered a bug in the write mode part of the firmware).

In fact the cdrecord man page says it explicitely:
padsize=#
Use this option if your CD-drive is not able to read the last sectors of a track or if you want to be able to read the CD on a Linux system with the ISO-9660 filesystem read ahead bug.

So it is a combination of both and still longer `-pad' may (or may not - if padsize=15 is enough for the drive part of the bug) be required even if the kernel readahead bug gets fixed.
Comment 7 Andre Robatino 2009-01-03 04:29:47 EST
http://www.troubleshooters.com/linux/coasterless.htm

advises padsize=63s to work around the readahead bug.  It doesn't say where he got this value from but I remember reading the reason somewhere.  I've never seen the bug manifest when padding using this value.
Comment 8 David Tonhofer 2009-01-03 19:14:18 EST
I seem to have hit this bug on Fedora 10. I thought the SCSI/SATA drivers had a bug until I found this report. Here we go:

With an LG GDRH20N SATA DVD-ROM:

-- Media Check fails 100% (tested DVDs, (live) CDs, several burns...)
-- "Independent Media Check" using another system works (dump the ISO
   image, see below, then check the SHA1 sum against the official sum)
-- Installation fails in a totally weird manner
   (e.g. at the very end, anaconda says "no kernel images installed" or
    arbitrary packages are not found)
-- Starting the same system from a PATA drive found in the attic with
   the same media works nicely (installation not yet tried, will try)
-- Media check passes if "ide=nodma" kernel option is given. Yowza!

Additionally:

-- Booting the system to Fedora 10 Live CD using aforementioned PATA
   drive, then dumping an ISO image (in this case, F10-x86_64-Live.iso)
   off the DVD-ROM if "ide=nodma" has NOT  been set results in a: 

   -- correctly-sized
   -- but slightly corrupted image

   The dump was done with "dd if=/dev/sr0 of=/tmp/corrupted.iso"
   It is probably not of big interest to know the exact differences,
   but a little perl program to cut the dump into 10K blocks and hash
   these, applied tp both original ISO and dumped ISO reveals 61 10K
   blocks with differences, *spread throughout the image* (not only the
   end affected).

Now going to have drink or two.

How to hash 10K blocks:

#!/usr/bin/perl
use Digest::MD5 qw(md5 md5_hex md5_base64);
$file = $ARGV[0];
open(FILE,$file) or die "Could not open $file: $!\n";
binmode FILE;
my $buffer;
my $size = 1024*10;
my $read;
my $pos = 0;
while (($read = read(FILE, $buffer, $size)) > 0) {
   my $digest = md5_hex($buffer);
   my $end    = $pos + $size - 1;
   print "$digest [$pos,$end] $size\n";
   $pos += $size;
}
close(FILE);
Comment 9 David Tonhofer 2009-01-03 19:17:14 EST
Oh DUH, facepalm. Comment#8 should go to bug#186512. Sorry, sorry. One cannot delete it unfortunately.
Comment 10 Bug Zapper 2009-06-09 21:09:50 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2009-07-14 12:14:50 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 12 Andre Robatino 2010-11-07 04:27:58 EST
Can this bug be marked as a duplicate of bug 186512? That bug still exists (just updated the Version to 14) and it's nice to have a record of someone else being able to duplicate it.
Comment 13 Pavel Roskin 2014-02-16 21:01:10 EST
I believe using -pad is a poor workaround.  wodim should not create any bad sectors, period.  Besides, if writing an HFS image, the kernel would read the padding area and get errors, unless the loop device with sizelimit is used.  Please see bug 1065802, I made some research and found when the bad sectors appear.