Bug 447452 - F9 CD mediacheck problems
F9 CD mediacheck problems
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-19 19:09 EDT by Juha Leppänen
Modified: 2009-07-14 11:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 11:47:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Juha Leppänen 2008-05-19 19:09:59 EDT
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
Comment 1 Andre Robatino 2008-05-30 13:29:58 EDT
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!
Comment 2 Juha Leppänen 2008-06-01 10:22:40 EDT
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?
Comment 3 Juha Leppänen 2008-06-01 11:25:37 EDT
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?
Comment 4 J. Adrian Trezise 2008-06-11 18:24:35 EDT
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
Comment 5 Juha Leppänen 2008-06-22 11:32:20 EDT
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?
Comment 6 Juha Leppänen 2008-07-04 19:28:28 EDT
Is this bug reported against the right component?
Should I change this to kernel?

Ping .... Any redhatted viper, boa or anaconda listening?
Comment 7 Chuck Ebbert 2008-10-04 01:45:35 EDT
This should be fixed now. You can test the Fedora 10 beta or a respin of Fedora 9.
Comment 8 Juha Leppänen 2008-10-07 04:17:54 EDT
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?
Comment 9 David Tonhofer 2009-01-02 10:02:22 EST
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
Comment 10 Bug Zapper 2009-06-09 21:01:30 EDT
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
Comment 11 Bug Zapper 2009-07-14 11:47:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.