Image checksum not matching

A few times last week (as recently as this past Friday) I downloaded
https://download.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.4-x86_64-dvd.iso
and
https://download.rockylinux.org/pub/rocky/9/isos/x86_64/CHECKSUM

When I ran sha256sum to verify the checksum, it failed. For what it is worth, I also attempted to do the same actions with the 8.x iso but had the same result.

I have had this happen in the past, but usually within a day or so, the problem would correct itself; but since it seemed to persist for a full week I figured I would ask for help.

I have seen posts here about this before, and it would suggest that the download hasn’t been downloaded successfully hence the checksum mismatch. I’m currently downloading the minimal iso and will also download the dvd one to check/verify. The download is taking some time, like 40mins for 1.7GB, so will update when it’s been successful. Obviously the DVD download will take somewhat longer, but will update when I get a chance to see if I have been able to download it successfully or not.

You may wish to attempt using wget to download it, since if it fails, you should easily see from the console if this is the case. You can even use the -c parameter with wget to continue a previously failed download. Might be a better way if seeing where the problem lies, as it’s easier to tell if the download failed or not.

This one has matched for me:

# Rocky-9.4-x86_64-minimal.iso: 1829634048 bytes
SHA256 (Rocky-9.4-x86_64-minimal.iso) = ee3ac97fdffab58652421941599902012179c37535aece76824673105169c4a2

Will post about DVD image shortly when it finishes downloading.

In fact now, when downloading the DVD image via wget, I had it time out after only downloading 7%. So I expect that what you have is an unfinished download and that is why the checksum doesn’t match. I restarted the download using wget -c url and it’s continuing from 7%.

It would be easy enough to assume that the download finished, if not paying enough attention to it like I have done via the console with wget.

I also downloaded the DVD image, and it’s also fine:

# Rocky-9.4-x86_64-dvd.iso: 10916397056 bytes
SHA256 (Rocky-9.4-x86_64-dvd.iso) = e20445907daefbfcdb05ba034e9fc4cf91e0e8dc164ebd7266ffb8fdd8ea99e7

I would suggest going to a mirror near you from this link: Mirrors - Mirror Manager you will most likely have more success. The mirrors are (or should be) browseable, which means you can go to the iso’s directory and download there.

Using wget from the console like I was doing also means it’s easy enough to find out if the download finished or not or disconnected part way through.

The short → Downloaded from a mirror using wget and verified checksum without issue.

The long → Earlier last week I started this process with a program that I had written that would automatically download the iso for a workstation setup at home. I am a software dev by trade, and I have already gotten a few other downloads for other assets to work in a similar manner with the same code. The download from the main url did not show any errors, but the checksum failed. When that happened, I downloaded from the main url using a browser. Again, no errors but no luck on the checksum. For a third attempt, I downloaded with curl -v to show status and any errors. There were none, and the checksum failed.

I would not think that downloading with wget would actually make it any more or less successful. The only other variable that I changed is that this time I got the file from a mirror.

Either way, I got what I needed, and I appreciate your suggestions.

1 Like

In case you are interested, here is the mirror link that I used:

https://mirrors.vcea.wsu.edu/rocky/9.4/isos/x86_64/Rocky-9.4-x86_64-dvd.iso

I used a mirror based in the EU, but I think the main thing here is the main download urls via Fastly were being a bit problematic due to the cache (or lack of), and depending on location, either downloads were fast or slow, or problematic in one way or another causing an incorrect checksum.

As you downloaded it OK from alternative mirrors, you have it resolved anyway, but the team are looking at the main url’s as I reported it as being an issue, both speed wise as well as reliability of downloads.