Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 36187 - Dumping an iso images burned with cdrecords result in different length on different drives.
Summary: Dumping an iso images burned with cdrecords result in different length on dif...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Lars Weiler (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-20 09:56 UTC by Mikael Rosbacke
Modified: 2004-02-19 02:33 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Rosbacke 2003-12-20 09:56:54 UTC
Hi.

I have successfully burned the amd64 live cd on two different cdrom drives.
Reading back the image using 'cat /dev/hdd' > image.iso' give me a different size compared to the original iso image.

I've done some research. I have two different CD burners. One Acer 10x8x32 (/dev/hdc) CDRW with the latest BIOS installed and one LiteOn LDW-411S (/dev/hdd) CD/DVD burner with BIOS 0F

The original size of the iso file is: 93 814 784
I burned two CD:s:
cdrecord -dev=ATAPI:/dev/hdc image.iso   (call it CD-C)
cdrecord -dev=ATAPI:/dev/hdd image.iso   (call it CD-D)

and read each back with each drive: (b=burned, r=read)
cat /dev/hdc >test_bhdc_rhdc.iso (Using CD-C)
cat /dev/hdd >test_bhdc_rhdd.iso (Using CD-C)
cat /dev/hdc >test_bhdd_rhdc.iso (Using CD-D)
cat /dev/hdd >test_bhdd_rhdd.iso (Using CD-D)

Listing our different iso images:
93 814 784  image.iso (original)
93 818 880  test_bhdc_rhdc.iso   (1)
93 812 736  test_bhdc_rhdd.iso
93 818 880  test_bhdd_rhdc.iso   (2)
93 812 736  test_bhdd_rhdd.iso

We can see that when _reading back_ the iso images i get different sizes of the iso images. I compared the contents of all the images an the intersection of each pair was identical with the exception of (1) and (2). They differed on byte  93 814 785 which is one beond the original iso image.
My main worry is that hdd does not get all the data back. This drive is modern so it should handle CD-R writes flawlessly. Even if this is normal, it will remove all chances of a good verification using eg. k3b.
 
Program versions:
[ebuild   R   ] app-cdr/cdrtools-2.01_alpha20

Im' not sure this is the correct forum for this bug, but I'll start here.

Note: The same fault occurs on my old AMD Thunderbird system.


Reproducible: Always
Steps to Reproduce:
1. Burn an image with 'cdrecord -dev=ATAPI:/dev/hdd image.iso
2. cat /dev/hdd > image_read.iso
3. Size of image_read.iso and image.iso differs.
4. cmp image_read.iso image.iso //Same contents up to the length of the shorter.


Expected Results:  
The sise of the iso image should be the same as the one used for burning.

'Portage 2.0.49-r15 (default-amd64-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.0-gentoo)
=================================================================
System uname: 2.6.0-gentoo x86_64 4
Gentoo Base System version 1.4.3.12
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config
/usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS=""
DISTDIR="/usr/portage/distfiles"
FEATURES="sandbox ccache autoaddcvs"
GENTOO_MIRRORS="http://gentoo.linux.no/ ftp://gentoo.linux.no/pub/gentoo/
http://trumpetti.atm.tut.fi/gentoo/ http://ds.thn.htu.se/linux/gentoo
http://mirror.pudas.net/gentoo ftp://ftp.rhnet.is/pub/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 oss 3dnow apm arts avi crypt encode foomaticdb gif gtk2 imlib jpeg
kde gnome libg++ libwww mikmod mmx mpeg ncurses nls oggvorbis pdflib png
quicktime sdl spell sse truetype xml2 xmms xv zlib gdbm berkdb slang readline X
gpm tcpd pam ssl perl python esd gtk opengl cdr multilib --cups --java -motif --qt"
Comment 1 Lars Weiler (RETIRED) gentoo-dev 2004-02-11 19:01:59 UTC
I guess, that the two CD-writers have different ways to close a session.  At least it looks so.  Or one drive writes in raw-packet mode.  There are several options.

Is the image corrupted after burning or does it work correctly?

You can try to upgrade to the recent cdrtools, but I guess you won't have luck with this problem.

As long as this strange problem does not harm in a hard way, I'll close this bug as WONTFIX.  But first, you should get time for further testings ;-)
Comment 2 Lars Weiler (RETIRED) gentoo-dev 2004-02-18 21:04:26 UTC
No answer within a week.  Closing this bug as WONTFIX.
Comment 3 Mikael Rosbacke 2004-02-19 02:33:49 UTC
I have limited access to my computers at the moment so I can't really make any tests the coming month. What kind of tests would be requested? As far as I can see, the reading of the images seems to be drive related, and therefore kernel related.
I have access to 3 different CD/DVD drives. What can I do more to test this in addition to the initial testing?
The images read back are byte identical to the original. The difference is that the image from one drive lack some data in the end (and therefore loose data) while the image from the other drive have some garbage at the end.