• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

SOLVED***RedHat 8: Continued problems MD5SUM***SOLVED

N

Need4Speed

Diamond Member
Well, my problems seemed to continue last night...For those that don't recall, I kept getting an error during installation that said something to the following effect:

"can't read package /temp/iso/xxxxxxx.rpm due to bad package or media"

I've tried installs from local cdrom and installs directly from the ISO files on the hdd using the boot disk.
I've verified that the hdd has no bad blocks/sectors.
I've tried installing from 2 different scsi discs
My system is not overclocked
I've tried iso's from several different FTP servers.

I've been downloading the iso files in Winxp using flashfxp and leechftp...i had thought that maybe the ftp client was causing some type of data corruption. I also noticed that when i check the md5sums using md5sum.exe, that they never pass. Furthermore, I can run md5sum in winxp once, and iso#1 will pass, and if I run it again iso#2 can come up failed. There seems to be no consistancy.

I've downloaded the iso files to different hdds, with the same result.

Then I decided to download the iso files using gftp from my redhat box. I ran md5sum and all 3 iso files came up OK.
I then transfered the ISO files to my winxp, which i am planning on dual booting from, using flashfxp....checked md5sum on winxp, and the files failed again.

I've fdisked and formated the drive im downloading to and installing to several times with no change in result.

Any one have some thoughts on this? what are you guys using to check md5sums in winxp?

im completely at my wits end with this one.....

thanks,
patrick
 
ftp install. Setup an ftp on your redhat machine using the isos (you should be able to mount them in the ftp root dir or something) and install off of that. If the MD5sums are working properly on that machine, use the power of Linux to get around the wierd XP problems...
 
I have considered that as well and will probably do just that. However, it wont help me figure out what's going on. And I am sure that you share the same thoughts as I do on unexplained errors 🙂

*Must....figure.....out...what's.....happening* 🙂

One thing I have thought about doing, is using a floppy distro on the winxp box to boot linux and check the md5sums on the winxp box locally using linux rather than winxp. The iso's reside on a fat32 partition (obviously) so mounting it will not be a problem.

Edit: I should add, that I never had these problems with RH7.3 when I dual booted this machine, but i never checked the md5sums at that time either.
 
Sounds like the RPMs may be corrupt somewhere. If you're loading it off an image and then just loading the same image to your hard drive, it would make sense that it would still be corrupt....just a thought. If you do an ftp install from somewhere else or download the images again from another source, that should take care of that possibility.
 
I'd agree with that, except that:

1. I've downloaded the iso's from at least a 1/2 dozen different sources with the same result
2. The md5's check out when I download the iso files with my redhat box, but as soon as i transfer them to winxp, they no longer pass.
3. none of my scsi disks have bad block/sectors.
 
ok, so i just got done mounting the fat32 partition using a floppy distro and run md5sum...all failed. yet the same isos check out on the linux box that i downloaded them to.


weird....
 
I got my isos from kickstart.linux.ncsu.edu and they all checked out fine on my WinXP box. I ran "MD5SUM -c md5sum" from command prompt to check them before burning. Good luck.

 
some further updates:

Things I know so far:
the iso files located on my redhat box all pass the md5sum, thus I can assume that they are good.

What I've done in the last half hour:
I am using a floppy linux distro in the windows xp box to connect to my redhat box via ftp
I grab the iso files from the redhat box and transfer them to a fat32 partition on the windows box. md5sum fail
I grab the iso files from the redhat box and transfer them to ext3 partition that i created with my floppy linux distro on the windows xp box. md5sum fail

so for some reason my iso files fail when i ftp to that box wether it be in linux or winxp. Possible ideas? bad nic? bad cable?

when i run ifconfig with the floppy distro, i get not errors on eth0.

I did notice that the iso files on the redhat box have the original date as it was when i downloaded them from a redhat mirror. the iso files on the winxp box have todays date...would that cause md5 to fail? but it certainly wouldnt corrupt the iso such that my install would fail....
 
more thoughts:

1. the os i dl the images with makes no difference
2. the filesystem the images are being dl to makes no diff
3. the nic and cable are good...no transmit/receive errors
4. no collisions on the switch
5. ftp client makes no diff
6. different scsi drives make no diff

so what is it then?

i also made a .tar files of the iso images and then grabbed the tar file instead of the 3 iso images...still no good.
 
Im not much in the "why is this happening mood?" lately. Im in more of a "How do I get this to work?" mood... Anyhow, under clock the processor and or swap ram.
 
youre right...how do i get this to work is more appropriate 🙂

Here are some other things and results:
I made my own md5sum file of some rar files i had on the redhat7.3 box, then logged in via ftp from the floppy distro box and grabbed the files....md5sum checked out ok.

So i decided to make my own md5sum for the three redhat8.0 iso files that reside on the redhat7.3 box. A quick comparision of the original md5 and the new md5 showed that they were identical...which i would have expected.

Once again I grabbed the iso files via ftp and checked md5sum...and again they failed. 🙁

As a last resort i will swap out the scsi drive on the xp box and drop in an ide drive and try again when i get home. for some reason i'm beginning to think it has something to do with the scsi controller....aha2940u2 in the xp box.
 
ok...so i decided to try one more thing and take ftp right out of the picture....I set up NFS and mounted a partition between the two boxes. I then copied the "OK" iso from the redhat7.3 box to the floppy distro box.

I ran a cmp between the two files and behold! they came up different. Here is the output:
differ: byte 198436341, line 716973

hmmmmm
 
rules of thumb

never keep an .iso that doesn't pass md5sum

burn .iso images at half (or slower) speed of what your burner is rated for


good luck!
 
yes of course thats true 🙂
but the whole problem is that they pass md5 until i move them to my other box.

Now that I think about it, could it be becuase I am using an intel pro10/100 managed nic? What else could be changing the file during transfer? If im not mistaken that nic has some type of onboard encryption...mmmm....i'll swap the nic before i do the SCSI to IDE swap tonight...
 
It's not even so much about redhat anymore as it its about what is changing the files when i transfer them to that specific box. The md5sums shouldn't be changing.

 
Good luck man, you got something really wierd hardware wise going on. Something is flippnig bits on transfer.

Have you tried setting up an SMB share and transfering the ISO's that way?
 
well ladies and gents..after much troubleshooting and swapping out of switches, cables, nics, scsi drives 🙂, ide drives....basically everyting that wasn't nailed down, it turned out to be:

A bad stick of RAM.

removed the stick and now md5sums are all good
 
Think that n0c wins the prize then..... If I had to guess I would say that there was a system load issue and as long as you didn't buffer up to the point on the bad stick you were getting the right MD5 sum. Use a little too much ram and bang off in the weeds
 
Originally posted by: Need4Speed
well ladies and gents..after much troubleshooting and swapping out of switches, cables, nics, scsi drives 🙂, ide drives....basically everyting that wasn't nailed down, it turned out to be:

A bad stick of RAM.

removed the stick and now md5sums are all good
Click to expand...

Told you 😉
 
that explains why i was able to transfer a crap load of 15mb files without a problem, but as soon as i transfered anything over 300mb it would bomb out.

the funny thing is that the ram passed all the mem tests that i threw at it. it wasnt until i decided that i had done everything possible and just started working with the bare minimum.

 
Originally posted by: Need4Speed
that explains why i was able to transfer a crap load of 15mb files without a problem, but as soon as i transfered anything over 300mb it would bomb out.

the funny thing is that the ram passed all the mem tests that i threw at it. it wasnt until i decided that i had done everything possible and just started working with the bare minimum.
Click to expand...

If you have a Promise Ultra66/100 card on either box, you may also be experiencing corruption from that.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top