Bug 140877 - md5sum valid disc test fail
Summary: md5sum valid disc test fail
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-26 01:57 UTC by E. Lewis
Modified: 2015-01-04 22:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-03 01:09:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description E. Lewis 2004-11-26 01:57:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1

Description of problem:
There is a possible error with the Fedora 3 installer.
We downloaded FC3-i386-disc1.iso, FC3-i386-disc2.iso,
FC3-i386-disc3.iso and FC3-i386-disc4.iso. All four MD5SUM (checksums)
were valid. I then expanded the files to CD's using 'cdrecord -v
-eject dev=0,0,0 <proper filename>.iso'. The creation of all four CD's
proceeded normally and showed no errors. Then, when installing Fedora
Core 3, I ran the recommended disc check mechanism, disc1 "passed".
Discs 2,3 and 4 all "failed". I then reexpanded the disc2 iso two
additional times, both times the disc check mechanism during install
reported "fail" for disc 2. I also ran a second MD5SUM utility to
verify the MD5SUM's on the iso images. I then proceeded to install
Fedora Core 3, ignoring the errors. Fedora Core 3 crashed on startup
suggesting that indeed discs 2, 3 and 4 were error prone.
I successfully installed Fedora Core 1 on the same machine many months
ago. I have used Fedora Core 1 ever since with no incidents at all.
It appears that either the installation documentation is incorrect or
the ISO images are incorrect.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Please see the above.
2.
3.
    

Actual Results:  Please see above. disc1 "passes", disc2, disc3 and
disc4 "fail". Proceeding with installation crashes entire Linux
installation.

Expected Results:  All four discs would pass given the valid MD5SUM's
of the iso images.

Additional info:

Installing the corrupt FC3 completely crashed my FC1 installation
causing a loss of all of the data on the ext3 drive.

Comment 1 Sitsofe Wheeler 2004-12-03 09:37:46 UTC
Might be a dup of bug 106685 . Does booting the first disk with "linux
cddma=off" parameters make all the disks pass the check?

Comment 2 E. Lewis 2004-12-03 22:11:49 UTC
No! This is what I did - please verify that I indeed passed the parameter correctly.
When booting from Fedora Core3, CD 1, the computer presented a screen to press
"enter" to boot in graphical mode as well as other choices. Beside the "boot:"
prompt, I typed "linux cddma=off" and then pressed "enter" to boot in the
graphical mode. Then, I proceeded with checking the CD's, starting with No. 2.
No. 2 failed. I then stopped, figuring that something is still improper.
Thanks in advance for your help with a rather vexing problem!

Comment 3 Sitsofe Wheeler 2004-12-03 23:24:00 UTC
What program did you use to burn these CDs?

Comment 4 E. Lewis 2004-12-04 16:10:33 UTC
My son burnt them from iso images downloaded to his hard drive using a built in program 
that is part of Microsoft XP "Professional". It was these images that I then copied onto my 
Fedora Box and checked the MD5SUMs of.
I then burnt the iso's from by Fedora box using cdrecord in a GNOME terminal session on 
a SONY USB CD Drive, the same drive I used to create my Fedora 1 discs many months 
ago.


Comment 5 Sitsofe Wheeler 2004-12-04 21:30:51 UTC
If you have a cdrw or something, can you reburn one of the failing
disks adding -pad to cdrecord and then verify it?

Comment 6 E. Lewis 2004-12-06 16:52:18 UTC
Adding the -pad parameter to cdrecord (e.g. 'cdrecord -pad -v -eject
-driveropts=burnfree dev=1,0,0 <proper file name.iso>') does nothing.
Further, I tried cdrecord using a different CDRW drive and observed
the same results: media check reports "fail".
Previous to writing each new CD, I again verified the MD5SUM to
eliminate any possibility of using a corrupt source file.

The process of booting off the (valid) Fedora Core 3 CD No. 1 and then
checking the validity of the remaining Fedora Core 3 discs also does
something to the hardware probe of the startup sequence of my Fedora
Core 1 box that may or may not be related to the reported bug.
Specifically, after observing the report of CD Fail, I depress
<ctrl><alt><delete> to reboot the machine. The machine shuts down and
reboots as expected. It takes however, upwards to 10 minutes for the
machine to reboot to the login screen. Most of the 10 minutes time is
occupied with "probing for new hardware". Then the machine demands
another 30 minutes or so to boot back into a user mode. At this point,
the system is very unstable; it is prone to periodic hanging. Logging
out, shutting down and then rebooting a second time is needed to
restore normal operation. Normally it takes about a minute to boot to
the login screen and another minute or so to boot back into a user
mode. All of the applicatons I have run with Fedora Core 1 (as well as
many others I have compiled from source code) are stable, the machine
never hangs nor complains!



Comment 7 E. Lewis 2004-12-07 17:46:59 UTC
Searching for this bug through Google indicates that many other users
are experiencing the problem this bug describes. One suggested
workaround was to boot from the Fedora Core 3 CD passing the parameter
ide=nodma (e.g. 'linux ide=nodma').
This workaround is ineffectual. The discs still report errors; the
time required for startup after the media check operation continues to
be abnormally protracted.

Comment 8 Sitsofe Wheeler 2004-12-11 21:09:19 UTC
Can you try verifying one of your "failing" disks using the following command
line with the FC3 install CD:
linux mediacheck nocddma

Please dont' burn any new disks though! I feel bad that you have a small
mountain of things stacking up...

Comment 9 E. Lewis 2004-12-13 03:51:54 UTC
Here is a workaround that I came up with. It shows that FC3 will install and run
very well if it is installed from media other than from CD.

Time required: 9 - 10 hours. Intervention: 20 minutes.

Prerequisite: Hard disc drive with partition not to be formatted with capacity
of 3 GIG. Hard disc drive with partition to be formated with a capacity of at
least 6 GIG. CDRW drive and bootable CD drive. The "not to be formatted"
partition I used was a Microsoft Factor Allocation Table (FAT) partition
(actually a separate disc, simply a Unix partition).

Have on hand: Fedora Core 1 (FC1) consisting of three discs consisting of
expanded ISO files. Note that FC1 installs from CD, FC3 does not in my experience.

Download FC3 CD ISO Files and copy to CD. Check MD5SUMS to verify integrity
before leaving the site with high speed internet access where you did the
downloads! (Internet Cafe &c.).

Copy the 4 image files to the HD Partition that will not be formatted. DO NOT
EXPAND the iso files. Check MD5SUMS to verify integrity.

Expand the boot image from FC3 CD No. 1 onto a blank CD. You will need to mount
the iso image, copy the file boot.img to a separate location. Use cdrecord to
expand the boot.img to a blank CD.

Install FC1 from CD. Takes about 15 minutes to pick installation choices and
launch. Follow all prompts. It takes additional 20 minutes for CD1 to finish
itself. Install CD2 with prompt. Wait 35 minutes. Install CD3 with prompt. Wait
10 minutes. At this point, you are about 80 minutes (call 1 1/2 hours) into it.
Once FC1 is up and running, configure network, printers &c.

Shut down and restart machine as directed. Initial restart takes about 45
minutes with most time consumed with "probing hardware". Subsequent starts take
about 2 minutes. 

When shutting down and restarting, it is best to leave the machine shut down for
at least 30 seconds before restart. This will expedite the restart process.

Shut down the machine again. Restart, booting off the FC3 boot CD.

Elect to install FC3 from hard disc. DO NOT ELECT TO INSTALL FROM CD, FC3 DOES
NOT INSTALL FROM CD.

Elect to UPGRADE FC1 (do not install new, the FC3 file format utility has bugs
and will crash, wiping out your FC1 installation and forcing you to start all
over!).

Once you see "preparing to install" dialogue take a break, leave and do
something else.  Wait about 5-6 hours. The FC1 RPM packages will all be upgraded.

Shut down and restart FC3. Restart could take upwards to 1 hour. The screen will
be blank and will offer no feedback most of the time. After this one long
restart, subsequent restarts take about 2 minutes.

Note: I am installing this to a (very) old Pentium II-233 machine with about 150
MEGS of RAM (less than Fedora team recommendation). The wait times may be less
with a more modern machine. Also note that FC1 has been VERY RELIABLE on this
machine, I have a lot of operating hours on it!

A couple days later ... FC3 is running very well. GIMP, Open Office, GRASS (not
part of the FC3 distro), XNView (not part of FC3 distro) and Wine (not part of
distro) all run flawlessly in my experience.

Comment 10 Dan Hollis 2005-02-03 23:26:27 UTC
using -pad with cdrecord doesnt fix it.
using cddma=off doesnt fix it.

it fails at 99% always.

Comment 11 Dave Jones 2005-07-15 18:59:51 UTC
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.

Comment 12 Dave Jones 2005-10-03 01:09:53 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.


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