Description of problem: Running currently FC 7, but wanting to install F9. Fedora-9-i386-disc2.iso thru Fedora-9-i386-disc5.iso media checks fail. Error messages seen on VT3 or VT4 only when checking Fedora-9-i386-disc6.iso, but check still pass on that disc. SHA1SUMS checked, downloaded ISOs from different mirrors, checked burned discs with sha1sum, used isoinfo and dd to verify sizes .... Then tried booting with FC2-i386-disc1.iso and running media check, all F9 discs PASS!!, no errors in VT3/4 during check, and checked 3 times the F9 6 disc set, on one session. Suspected FC2 media check, so made a copy of F9 disc 6 and changed one byte, burned resulting 'fake' and both F9/FC2 media checks correctly FAILED the 'fake'. Also noticed when mediachecking F9 discs 2-5 with Fedora-9-i386-disc1.iso that progress bar progressed normally until 95%(one about 98%) and then jumped quicly straight to 100% and then announced failure ... odd, no errors announced. (size calculated wrong???) Also burned Fedora-9-i386-disc6.iso to the disc that had Fedora-9-i386-disc1.iso and vice versa, swapped the two discs so to speak, but still got the same error messages seen on VT3 or VT4 when checking Fedora-9-i386-disc6.iso, and still that disc6 pass. I believe my CDRW burned discs are OK, but somehow F9 install kernel/anaconda/mediacheck is not correctly 'handling' my PC. Seen a lot install problems on bugzilla, so not so eager to try install anyway. No problems what so ever with FC2/FC7. Checked constantly FC7 dmesg for any error messages from relating to CD(RW)s or burning CDRWs, but never seen any. Latest CD install of my PC was FC2, FC7 I installed by copying DVD image to a spare hard disk and copying also the files needed to boot and then installed from the image. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Boot from Fedora-9-i386-disc1.iso 2. run media check on all install CD discs 3. discs 2 -5 fail the test Actual results: Oh sh**, did not pass the test, lets investigate ... Expected results: Oh glad, passed the test, can now start installing ... Additional info: ASUS A7V8X-X with bios rev 1011, LG GCC-4480B CDRW Used K3b to burn the discs. Errors reported on VT3/4 look like <3> end_request: I/O error, dev sr0, sector 567296 <3> Buffer I/O error on device sr0, logical block 70912 ...... snip, snip, repeated with growing block number upto .... <3> Buffer I/O error on device sr0, logical block 70921 If I understand correctly this sector is quite close tho the end of the CD, the CD size was something like 290MB. ????? when same disc checked again <3> end_request: I/O error, dev sr0, sector 567304 <4> printk: 22 messages supressed. <3> Buffer I/O error on device sr0, logical block 70913 ...... snip, snip, repeated with growing block number upto .... <3> Buffer I/O error on device sr0, logical block 70922 and again <3> end_request: I/O error, dev sr0, sector 567296 <4> printk: 21 messages supressed. <3> Buffer I/O error on device sr0, logical block 70912 ...... snip, snip, repeated with growing block number upto .... <3> Buffer I/O error on device sr0, logical block 70921 and once more <3> end_request: I/O error, dev sr0, sector 567296 <4> printk: 22 messages supressed. <3> Buffer I/O error on device sr0, logical block 70912 ...... snip, snip, repeated with growing block number upto .... <3> Buffer I/O error on device sr0, logical block 70921
Had the exact same problem with discs 1 and 6 passing and the rest failing. I didn't check the VT output, though. The problem is NOT the linux readahead bug, since I took all precautions to prevent that (zero-padding, DAO mode) and finally verified the discs by reading the ISO off the disc after burning. Furthermore, after doing a network install of F9, I installed anaconda-runtime and ran checkisomd5 on the discs, using the same machine, same drive, even same kernel that anaconda used, and all 6 discs passed!
I think the "install kernel" is not the same kernel that is installed and used normally in F9. So if you install anaconda-runtime/checkisomd5 after install and mediacheck the F9 6 install discs, maybe all you can say that checkisomd5 works regarding this problem? Is isolinux/syslinux the kernel used when booting F9 CD 1 and running mediacheck? Or the same kernel that is later installed as normal kernel? Regarding Andre's comment above, can you assume that checkisomd5 works? And the problem is install kernel? Some other component? Can I help to triangulate the reason?
Did some checking, isolinux and syslinux are just boot loaders. Question remains, is the kernel used when booting F9 CD 1 and running mediacheck the same as later installed as normal kernel?
Yes I concur! I too have had this problem with F9 cdrom disks. Namely the disk 1 is ok but 2-5 fail with the message "Unable to read the disc checksum from the primary volume descriptor. This probably means that the disc was created without adding the checksum". Well I check the that the discs were good with the sha1sum utility and with with the checkisomd5 utilities and the isos that I download were good. I burnt the discs several times using GnomeBaker, K3b and good old wodim and tried them on different machines. Same result everytime. All up I wasted 20+ hours on this problem. Strange, apart from this forum entry, http://forums.fedoraforum.org/showthread.php?t=191297, and this bug report I found no other comments on the web. Does nobody use CDs any more? :-( jatrezise
Hi, I just read from kernel.org : Linux 2.6.25.8 Changelog SCSI: sr: fix corrupt CD data after media change and delay ========================================================== If you delay 30s or more before mounting a CD after inserting it then the kernel has the wrong value for the CD size. http://marc.info/?t=121276133000001 The problem is in sr_test_unit_ready(): the function eats unit attentions without adjusting the sdev->changed status. This means that when the CD signals changed media via unit attention, we can ignore it. Fix by making sr_test_unit_ready() adjust the changed status. And in http://marc.info/?t=121276133000001 ========================================== --- snip snip ----- Nice first theory! Initially /sys/block/sr0/size is 2097151. After inserting the first CD, and mounting it, /sys/block/sr0/size is changed to the size of the first CD (in 512 byte blocks). After ejecting the first CD and inserting the second CD, the behavior is like this: 1. when immediately mounting the CD, /sys/block/sr0/size is updated to the size of the second CD, 2. when waiting more than 30 seconds before mounting the CD, /sys/block/sr0/size is not updated, and keeps the old value. Surprisingly, it doesn't behave like this when inserting the first CD. /sys/block/sr0/size is always updated, whether I wait 30 seconds before mounting it or not. --- snip snip ----- Hmmm, this made me think ... Symptoms seem somewhat similar in this mediacheck case. If you compare the sizes of F9 i386 CD install discs 1-6 : you boot with disc 1, which is smallest of discs 1-5, mediacheck OK. then check any of discs 2-5 and the progress bar jumps to 100% prematurely, and the mediacheck FAILS. The jump to 100% happens when bytes worth the size of the disc 1 have been read, 2:95%, 3:97-98%, 4:95%, 5:95%. If you calculate how many % the size of disc 1 is from the size of disc2, disc3 ... the %'s match. Or you check disc 6, the smallest disc, all bytes are read and check is OK. But some part of the install software thinks should read the size of disc 1, therefore the I/O errors ... So some parts of the software get the disc sizes OK, but some parts thinks all discs are the size of disc 1.(change of disc not detected properly?) Does this make sense? Kernel problem or anaconda problem? This happens only with certain hw combinations?
Is this bug reported against the right component? Should I change this to kernel? Ping .... Any redhatted viper, boa or anaconda listening?
This should be fixed now. You can test the Fedora 10 beta or a respin of Fedora 9.
Still using the same FC7 and same hardware as before. Downloaded Fedora 10 Beta i386 CD images 1-6, verified sha1sums, burned the CDs. Booted from F10Beta CD 1, all 6 discs PASS mediacheck. Also all previously mentioned and burned F9 i386 CDs 1-6 PASS F10Beta ediacheck. No progress bar jumping, no IO errors, mediacheck works. (Noticed two FATAL warnings : Module loop not found. Module ext3 not found. ??) With F9 mediacheck F9 i386 CDs 2-5 FAIL(1 and 6 PASS) as mentioned earlier. Checked F10Beta CDs also with F9 mediacheck : all 6 discs fail. (CDs 1-5 as expected.) CDs 1-5 have the progress bar jump as described earlier, CD 6 has the IO errors at the end of the CD, but also FAILS. Maybe the F9 mediacheck with F9 CD 6 PASSING was a lucky coincidence? So the problem seems to be fixed in F10Beta. Do you know what the cause was?
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
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
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.