Bug 447452
Summary: | F9 CD mediacheck problems | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Juha Leppänen <juha_motorsportcom> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 9 | CC: | atrezise, bughunt, kernel-maint, robatino |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-07-14 15:47:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Juha Leppänen
2008-05-19 23:09:59 UTC
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. |