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"
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 ;-)
No answer within a week. Closing this bug as WONTFIX.
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.