Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040803 Description of problem: The same CD-ROM fails mediacheck during install of FC3-re0903.0-i386 (and also when run via /usr/lib/anaconda-runtime/checkisomd5 after installation), but passes checkisomd5 under RHEL3 WS with kernel 2.4.21-20.EL.i686. Same physical CD-ROM, same hardware, multibooting fc3t2pre and RHEL3 WS within 10 minutes of each other. The RHEL3 version is anaconda-runtime-9.1.3-3.RHEL. Version-Release number of selected component (if applicable): anaconda-runtime-10.0.2-0.20040901235037.1 How reproducible: Always Steps to Reproduce: 1. Download and burn FC3-re0903.0-i386-disc4-ftp.iso (308781056 bytes) using no -pad argument to cdrecord. (Actual media: FujiFilm 48x CD-R [mfg by Taiyo Yuden]; actual burner: Sony CD-RW CRX175E2 Rev: S002 ["24X"].) 2. Run mediacheck (or /usr/lib/anaconda-runtime/checkisomd5) on /dev/hdc [after adjusting filesystem permissions, if necessary]. (Actual reader: SAMSUNG DVD-ROM SD-816B.) 3. Actual Results: mediacheck fails on FC3-re0903.0-i386, but passes on RHEL3 WS (kernel-2.4.21-20.EL.i686). Expected Results: Passes on FC3-re0903.0-i386, too. Additional info: Running checkisomd5 under strace on both systems, then diff-ing the strace output, shows that the FC3-re0903.0 system sees 24 fewer 2KB sectors. [So perhaps this is a kernel error for truncating the device.] Actual strace output (800KB) and diff (76 lines) will be attached.
Created attachment 103492 [details] diff between "strace checkisomd5 /dev/hdc" on RHEL3 WS vs. FC3-re0903.0-i386
I'll hold the 800KB actual output of "strace checkisomd5 /dev/hdc" for a few days until someone asks for it.
anaconda-10.0.2-0.20040901235037.1.i386.rpm is the version in FC3-re0903.0-i386-disc3-ftp.iso/Fedora/RPMS .
If SKIPSECTORS is 15 [30KB], then why is the buffersize equal to 32768 [32KB] for all the read() of data from the CD-ROM during checkisomd5? Shouldn't the buffersize be at most the SKIPSECTOR size, to avoid problems with "running off the end of data"? And why doesn't the "label" for the .iso (which lists the value of SKIPSECTORS) also list the total number of sectors, as another aid to help avoid attempting to read() past the end of recorded data? If "-pad" [the default value of which is 15 sectors @2KB/sector] is supposed to be a "mandatory" argument to cdrecord when burning .iso images that are encouraged to be subject to mediacheck, then why doesn't the download directory containing the .iso files have a README with a gentle reminder?
Any kernel I/O errors on the failed case?
Isn't this just a dupe of bug 106685?
Created attachment 103543 [details] /var/log/messages from FC3-re0903.0-i386 "checkisomd5 /dev/hdc" with CD-ROM media burn of FC3-re0903.0-i396-disc4-ftp.iso ( 301544 1K blocks accoring to "df") fails when run on FC3-re0903.0-i386, kernel-2.6.8-1.541.i686. /proc/ide/hdc/settings says using_dma is 1, and speed is 66 out of 70. Drive is SAMSUNG DVD-ROM SD-816B, ATAPI CD/DVD-ROM.
Created attachment 103545 [details] /var/log/messages from RHEL3 WS "checkisomd5 /dev/hdc" succeeds on media CD-ROM burned from FC3-re0903.0-i386-disc4-ftp.iso (301544 1K blocks when mounted, according to "df") when run on RHEL3 WS kernel-2.4.21-20.EL.i686. /proc/ide/hdc/settings says that using_dma is 1, and speed is 66 out of 70. Drive is SAMSUNG DVD-ROM SD-816B, ATAPI CD/DVD-ROM.
"end" is a bit undefined for a CD_RW (its +/- about 150 sectors). The 2.4 IDE code and the 2.6 IDE and SCSI code know about this and are smart about errors in the corner case. I don't know if the 2.6 IDE code does, if not the workaround is ide-scsi. Please verify what a checkisomd5 does with ide-scsi instead of ide-cd, at least as a debugging point. Also someone might want to file a bug that MD5 is broken and SHA1 shoudl be used ;) Alan
Created attachment 103551 [details] /var/log/messages with hdc=ide-scsi on FC3-re0903.0-i386 "checkisomd5 /dev/sr0" succeeds under FC3-re0903.0-i386 kernel-2.6.8-1.541 when booted with hdc=ide-scsi on the kernel command line. This is using the same physical CD-ROM burned from FC3-re0903.0-i386-disc4-ftp.iso (301544 1K-blocks according to "df" when mounted.)
Using FC3test2 (released yesterday), both the media check in default install ("boot: <Enter>") and the explicit "boot: linux mediacheck" FAIL on CD-ROMS 1,2,4 but PASS on CD-ROM 3. Also, ide-scsi does not work in the installer. Both "boot: linux hdc=ide-scsi mediacheck" and "boot: linux mediacheck hdc=ide-scsi" go directly to the "where are the installation files?" dialog, omitting the mediacheck phase. Furthermore, specifying Local CD-ROM results in "CD Not Found: The Fedora Core CD was not found in any of your CDROM drives" and on the screen <Alt><F3> the message is "trying to mount CD device hdc", even though FC3-test3-i386-disc1 is in the [DVD] drive and ready. So, from my perspective mediacheck is worthless in FC3test2.
Double checking, the physical CD-ROM with FC3-test2-i386-disc1.iso (2004-09-20) passes checkisomd5 in RHEL3 kernel-2.4.21-20.EL, but fails checkisomd5 in today's FC3test2 kernel-2.6.8-1.584. The error messages in /var/log/messages begin with: ----- Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error } Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: error=0x54 Sep 21 14:30:32 fc3t2pre kernel: ide: failed opcode was 100 Sep 21 14:30:32 fc3t2pre kernel: end_request: I/O error, dev hdc, sector 1305888 Sep 21 14:30:32 fc3t2pre kernel: Buffer I/O error on device hdc, logical block 326472 Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error } Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: error=0x54 Sep 21 14:30:32 fc3t2pre kernel: ide: failed opcode was 100 Sep 21 14:30:32 fc3t2pre kernel: end_request: I/O error, dev hdc, sector 1305892 Sep 21 14:30:32 fc3t2pre kernel: Buffer I/O error on device hdc, logical block 326473 Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error } Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: error=0x54 Sep 21 14:30:32 fc3t2pre kernel: ide: failed opcode was 100 Sep 21 14:30:32 fc3t2pre kernel: end_request: I/O error, dev hdc, sector 1305896 Sep 21 14:30:32 fc3t2pre kernel: Buffer I/O error on device hdc, logical block 326474 Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error } Sep 21 14:30:32 fc3t2pre kernel: hdc: command error: error=0x54 Sep 21 14:30:32 fc3t2pre kernel: ide: failed opcode was 100 Sep 21 14:30:32 fc3t2pre kernel: end_request: I/O error, dev hdc, sector 1305900 -----
I am seeing the same problem but with CORE 3 TEST 2. Having burnt two sets of disks and disk 1 on a different machine I have come to the following conclusion. If I boot from disk 1 on my i586 class machine (K6 III/450) i get reports of bad disks for 1,2,4 and the rescue CD but disk 3 is OK If I boot from disk 1 on my i686 class machine (Athalon Thunderbird/1200) all disks pass OK. If I boot from CORE 2 disk 1 on my i586 machine and do a media check of all 5 FC3 TEST 2 disks they then pass OK. So it would seem that ANACONDA checksums the disks deferently depending on the class of processor. Hope this helps and I will proceed with the install of CORE 3 TEST 2 on my K6 III machine tomorrow despite the reported media check errors and see what else is broken.
I realise that the two architecture's (i586 and i686 ) use different kernels but what I find a bit ODD is why disk 3 passes as OK at all. I am not shure exactly what sort of check is being done checksum of the disk or just a file by file integrity check.
Having read through all of the above and what is referenced it might not be an i586/i686 problem as on my i686 machine the boot device is a Pioneer SCSI DVD reader. So it just seems that it is probably just kernel related and not necessarily architecture related as I first thought.
Known bug see comment #9, it depends on the CD-ROM drive firmware behaviour and its an ide-cd bug. Its in the bugs.kernel.org database pending fixing
http://bugs.kernel.org does not exist (comment #16). Perhaps http://bugme.osdl.org/show_bug.cgi?id=3362 or http://bugzilla.kernel.org/show_bug.cgi?id=3362 [looks like the same; but hard to tell if identical, redirected, different front-end on same database, or ...]
i'm seeing this problem on five different models of hp/compaq desktops, from pentium II through pentium IV. Also seeing this on white box amd athlon computers using creative labs 52x cd burner. fc3-test2-i386-disc3.iso is the only one that passes
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Using kernel-2.6.12-1.1372_FC3 and anaconda-runtime-10.1.0.2-1 on FC3-re0903.0-i386-disc4-ftp.iso (308781056 bytes, burned with no -pad argument to cdrecord), the test "checkisomd5 /dev/hdc" still fails on SAMSUNG DVD-ROM SD-816B, ATAPI CD/DVD-ROM drive. The lines from /var/log/messages begin ----- Jul 16 08:32:27 fc3final kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error } Jul 16 08:32:27 fc3final kernel: hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } Jul 16 08:32:27 fc3final kernel: ide: failed opcode was: unknown Jul 16 08:32:27 fc3final kernel: ATAPI device hdc: Jul 16 08:32:27 fc3final kernel: Error: Illegal request -- (Sense key=0x05) Jul 16 08:32:27 fc3final kernel: Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) Jul 16 08:32:27 fc3final kernel: The failed "Read 10" packet command was: Jul 16 08:32:27 fc3final kernel: "28 00 00 02 4c c0 00 00 36 00 00 00 00 00 00 00 " Jul 16 08:32:27 fc3final kernel: end_request: I/O error, dev hdc, sector 602880 Jul 16 08:32:27 fc3final kernel: Buffer I/O error on device hdc, logical block 150720 Jul 16 08:32:27 fc3final kernel: Buffer I/O error on device hdc, logical block 150721 Jul 16 08:32:27 fc3final kernel: Buffer I/O error on device hdc, logical block 150722 ... ----- Using kernel-2.6.12-1.1398_FC4 and anaconda-runtime-10.2.1.5-2.i386 on the same physical CD-R(OM) but different box with drive PLEXTOR DVDR PX-712A, ATAPI CD/DVD-ROM, the test "checkisomd5 /dev/hdc" succeeds. The only related messages are ----- Jul 16 08:14:58 fc4final kernel: cdrom: hdc: mrw address space DMA selected Jul 16 08:15:01 fc4final kernel: SELinux: initialized (dev hdc, type iso9660), uses genfs_contexts -----
*** Bug 139213 has been marked as a duplicate of this bug. ***
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
Still fails in Fedora Core 5 test 2: original i386 DVD install: "linux mediacheck" Also fails with kernel-2.6.15-1.1826.2.10_FC5: anaconda-runtime-10.91.6-1 [/usr/lib/anaconda-runtime/checkisomd5] Still passes in RHEL3u5 (Taroon): kernel-2.4.21-32.EL anaconda-runtime-9.1.5.8-1.RHEL [/usr/lib/anaconda-runtime/checkisomd5] Drive: SAMSUNG DVD-ROM SD-816B, ATAPI CD/DVD-ROM drive CD-ROM: FC3-re0903.0-i386-disc4-ftp (downloaded and burned 2004-09-04 onto FujiFilm media [Taiyo Yuden]; 301544 1K-blocks in 'df'; 300848 in 'du')
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
It looks like progress has been made! An install DVD with volume label "FC/6-Pre i386 DVD" and date 2006092907093100 [Sept.29] was able to perform mediacheck on that CD (FC3-re0903.0-i386-disc4-ftp of 2004-09-04) and PASS it. One of the VT<n> screens had: ----- <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } <4>ide: failed opcode was: unknown <4>ATAPI device hdc: <4> Error: Illegal request -- (Sense key=0x05) <4> Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) <4> The failed "Read 10" packet commnad was: <4> "28 00 00 02 4c f0 00 00 06 00 00 00 00 00 00 00 " <4>end_request: I/O error, dev hdc, sector 603072 <4>Buffer I/O error on device hdc, logical block 75384 <4>Buffer I/O error on device hdc, logical block 75385 <4>Buffer I/O error on device hdc, logical block 75386 ----- so this looks like a successful detection of end-of-recorded-data.