[opensuse] Bad md5sum for DVD image?
Hello, http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is... says that the md5sum of the opensuse-11.3 dvd should be 1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso but the file I downloaded today from http://software.opensuse.org/113/de gives: jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso What would be the correct md5sum? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is... says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken. BC -- Gumperson's Law: The probability of anything happening is in inverse proportion to its desirability. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is...
says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
but why waste the time burning a disk with a known wrong md5sum? i'm pretty sure the answer to his problems is to fetch a full and correct image...hints to do that are in one or more of these cites: http://en.opensuse.org/SDB:Download_help http://tinyurl.com/yhf65pv http://tinyurl.com/ycly3eg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Aug 26, 2010 at 11:17:24AM +0200, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
What would be the correct md5sum? Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
A bad md5sum might be an indication for compromised disk. Thus, I want to know what exactly is going on here.
but why waste the time burning a disk with a known wrong md5sum?
That'd be faster than discussing the toping on the list, I guess. But for the reason mentioned above, it might be better to check whether the image on the server is broken.
i'm pretty sure the answer to his problems is to fetch a full and correct image...hints to do that are in one or more of these cites: http://en.opensuse.org/SDB:Download_help http://tinyurl.com/yhf65pv http://tinyurl.com/ycly3eg
Reloading from the same URL will give me the same file because the proxy caches it. Anybody has a direct link? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf wrote:
On Thu, Aug 26, 2010 at 11:17:24AM +0200, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
What would be the correct md5sum? Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
A bad md5sum might be an indication for compromised disk. Thus, I want to know what exactly is going on here.
you have a bad download....why, i do not know...what kind file system are you downloading to? what browser are you using? do you know if both are able to handle 4.7G files?
but why waste the time burning a disk with a known wrong md5sum?
That'd be faster than discussing the toping on the list, I guess. But for the reason mentioned above, it might be better to check whether the image on the server is broken.
the imange on the servers are ok..
i'm pretty sure the answer to his problems is to fetch a full and correct image...hints to do that are in one or more of these cites: http://en.opensuse.org/SDB:Download_help http://tinyurl.com/yhf65pv http://tinyurl.com/ycly3eg
Reloading from the same URL will give me the same file because the proxy caches it.
are you behind a proxy or other potential barrier which may want to 'control' your download (like: a campus dorm with a per file download limit; a business not wanting to support your p0rn habit and therefore restricts in some ways; a country afraid you will start a revolution; a coffee shop's metered wifi; etc etc etc)? i think i remember something about dealing with proxies on one (or more) of those three cite i gave you earlier.. if, in fact you are behind an MS based proxy which can't store or pass large files you need to do something else, like GO somewhere else for your feed..
Anybody has a direct link?
it used to be here: http://old-en.opensuse.org/Mirrors_Released_Version but since the wiki was 'upgraded' i have no idea where it is now, but Google should be able to find it.. it has been mentioned the easiest way to make sure you have a correct and complete iso is to let a torrent automatically repair and complete what you already have (but it can't if you have a deficient file system in use).. DenverD -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi Josef, On Thu, Aug 26, 2010 at 11:54:14 +0200, Josef Wolf wrote:
On Thu, Aug 26, 2010 at 11:17:24AM +0200, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
What would be the correct md5sum? Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
A bad md5sum might be an indication for compromised disk. Thus, I want to know what exactly is going on here.
You could duplicate the file (to another disk maybe) and then use rsync against one of the mirrors to repair it. After that (and when the hash of the second file proves to be fine), you could compare the files for differences (e.g. with cmp) or diff them blockwise. You may also want to try to reproduce the problem; maybe you can replicate it if you download the same way as before. There could be a bug in the download client or in a mirror, after all. If you'd know from which mirror you got the file that you have, it would be helpful in that case, of course.
but why waste the time burning a disk with a known wrong md5sum?
That'd be faster than discussing the toping on the list, I guess. But for the reason mentioned above, it might be better to check whether the image on the server is broken.
A very good plan.
i'm pretty sure the answer to his problems is to fetch a full and correct image...hints to do that are in one or more of these cites: http://en.opensuse.org/SDB:Download_help http://tinyurl.com/yhf65pv http://tinyurl.com/ycly3eg
Reloading from the same URL will give me the same file because the proxy caches it. Anybody has a direct link?
download.opensuse.org has them all: http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is... Cf. also http://mirrors.opensuse.org/list/11.3.html Peter
On 26/08/2010 19:17, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is...
says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
but why waste the time burning a disk with a known wrong md5sum?
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me. Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature? BC -- Gumperson's Law: The probability of anything happening is in inverse proportion to its desirability. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is...
says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
but why waste the time burning a disk with a known wrong md5sum?
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
maybe it WAS received correctly, and then "saved" to a FAT file system only able to save the first 2.x gigs.. DenverD -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 26/08/2010 22:45, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is...
says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
but why waste the time burning a disk with a known wrong md5sum?
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
maybe it WAS received correctly, and then "saved" to a FAT file system only able to save the first 2.x gigs..
Possibly, but unlikely as the OP is using Mutt as his mail client and the information he provided in his post shows a Linux/Unix command line. But then anything is possible..... BC -- Gumperson's Law: The probability of anything happening is in inverse proportion to its desirability. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-26 14:38, Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
Yes, but it appears that http/ftp don't have that feature. Instead, people could use the metalink "link" to make the download with a good metalink downloader, because that protocol _can_ guarantee a correct download, correcting errors. I use aria2c. Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB. Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page? A torrent downloader can also correct it. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Thu, Aug 26, 2010 at 04:03:00PM +0200, Carlos E. R. wrote:
On 2010-08-26 14:38, Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
i'm pretty sure the answer to his problems is to fetch a full and correct image...
Yeah, I tried that before posting, but got the same md5sum every time.
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
Modern times, that...
Yes, but it appears that http/ftp don't have that feature.
Turns out, that a broken proxy was the problem. The proxy delivered a Content-Length header of about 51 MB. So the client has never had a chance to do a correct download. Guess the proxy had problems with the 4GB limit.
Instead, people could use the metalink "link" to make the download with a good metalink downloader, because that protocol _can_ guarantee a correct download, correcting errors. I use aria2c.
Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB.
With a wrong Content-Length header, all chances are gone, IMHO.
Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page?
A torrent downloader can also correct it.
But what do you do if your only access is HTTP via proxy? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Aug 26, 2010 at 09:27:53PM +0200, Josef Wolf wrote:
Turns out, that a broken proxy was the problem. The proxy delivered a Content-Length header of about 51 MB. So the client has never had a chance to do a correct download. Guess the proxy had problems with the 4GB limit.
Unfortunately, there are still quite some proxies out there which can't handle large files. Thanks for posting the result of your quest.
With a wrong Content-Length header, all chances are gone, IMHO.
...and the Content-Range header would probably show the same irregularities.
But what do you do if your only access is HTTP via proxy?
I can't think of anything else productive right now than pointing out the problem to the folks who operate the intermediary proxy. Peter
On 2010-08-26 21:27, Josef Wolf wrote:
On Thu, Aug 26, 2010 at 04:03:00PM +0200, Carlos E. R. wrote:
Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB.
With a wrong Content-Length header, all chances are gone, IMHO.
Indeed... Perhaps if you find an http downloader that works in smaller chunks. I mean: download 1MB starting at 123MB. If I'm interpreting the problem correctly.
Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page?
A torrent downloader can also correct it.
But what do you do if your only access is HTTP via proxy?
Cry? :-( Go outside to an Internet Café, download it there, and pass the expenses to the company? -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Fri, Aug 27, 2010 at 01:04:10AM +0200, Carlos E. R. wrote:
On 2010-08-26 21:27, Josef Wolf wrote:
On Thu, Aug 26, 2010 at 04:03:00PM +0200, Carlos E. R. wrote:
Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB.
With a wrong Content-Length header, all chances are gone, IMHO.
Indeed...
Perhaps if you find an http downloader that works in smaller chunks. I mean: download 1MB starting at 123MB. If I'm interpreting the problem correctly.
Many download managers do that and the Content-length header won't be a problem then. However, the Content-range header still needs to be handled correctly for the large sizes, because otherwise the responses for chunks above 4GB will be incorrect. Thus, the download managers downloading in chunks are powerless as well, in the situation with the broken proxy. Other problems than broken proxies the Metalink-capable download managers can handle fine. Torrent client are also designed to handle such errors, however don't need only HTTP access. The mirrors themselves are checked by mirrors.opensuse.org for correct operation with files larger than 4GB. If they don't do this correctly, download.opensuse.org will not redirect (requests to DVDs) to them. Last year, 30% of mirrors still couldn't do this correctly, so it's an important check.
Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page?
A torrent downloader can also correct it.
But what do you do if your only access is HTTP via proxy?
HTTPS could help as well :-) Maybe there's a chance that the proxy supports large files via FTP, at least. Manually picking an FTP mirror from mirrors.opensuse.org might be worth a try, if one is stuck behind such a legacy proxy. Peter
But what do you do if your only access is HTTP via proxy?
HTTPS could help as well :-)
Maybe there's a chance that the proxy supports large files via FTP, at least. Manually picking an FTP mirror from mirrors.opensuse.org might be worth a try, if one is stuck behind such a legacy proxy.
Peter
you could also just circumvent the security on the network with an ssh tunnel, if you really had to. assuming: a. your desktop can access the website directly b. your desktop can ssh to the machine that needs the iso c. you don't have something running on port 80 of the machine that needs the file (this isn't a hard and fast requirement, but it makes things a little easier) if the url is http://www.opensuse.org/downloads/iso/11.3/thehuge.iso from your desktop: ssh -R 80:www.opensuse.org:80 id@target.that.needs.iso from target that needs iso: wget http://localhost/downloads/iso/11.3/thehuge.iso and you should be in business. similar silly pet tricks can be used to get around most things and can really get you into (or possibly even out of) trouble if you run squid at home and can ssh there. -- Even the Magic 8 ball has an opinion on email clients: Outlook not so good. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 27/08/2010 00:03, Carlos E. R. wrote:
On 2010-08-26 14:38, Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
Yes, but it appears that http/ftp don't have that feature.
Instead, people could use the metalink "link" to make the download with a good metalink downloader, because that protocol _can_ guarantee a correct download, correcting errors. I use aria2c.
Caveat: it requires that the metalink metadata contains error correction blocks. The DVD links at suse do. The system works by redownloading a bad block, and the dvd link has 129 such blocks of ~33 MB.
Once a download is bad, probably rsync is more efficient at correcting it. Do we have this info easily found in the wiki, near the download page?
A torrent downloader can also correct it.
Incredible....We are in this situation after some close to 30 years of having error-correcting protocols.....Unbelievable :-( . I use a Firefox Extension called DownThemAll! which has never given me a bad CD or DVD - and it resumes from where I lost the connection (which never happens now :-) .) I also find that the downloader in Firefox now also resumes from where the connection was lost and it also produces a "clean" file - but this latter downloader has not been under any "real strain" since it was upgraded by Mozilla. The reference to DownThemAll! is shown in this Wikipedia link: http://en.wikipedia.org/wiki/Download_manager BC -- Gumperson's Law: The probability of anything happening is in inverse proportion to its desirability. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-27 09:58, Basil Chupin wrote:
On 27/08/2010 00:03, Carlos E. R. wrote:
Incredible....We are in this situation after some close to 30 years of having error-correcting protocols.....Unbelievable :-( .
I use a Firefox Extension called DownThemAll! which has never given me a bad CD or DVD - and it resumes from where I lost the connection (which never happens now :-) .) I also find that the downloader in Firefox now also resumes from where the connection was lost and it also produces a "clean" file - but this latter downloader has not been under any "real strain" since it was upgraded by Mozilla.
Notice that this doesn't guarantee a correct download, the http or ftp protocols don't allow that. You need something else for verification of the download, and then retry. This can be automated, but you need a verification method. For example, if the download manager knows the expected crc, it can insist downloading chunks until the result is good. But blindly, because it can not know what section of the file has the error. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Sat, Aug 28, 2010 at 04:35:04AM +0200, Carlos E. R. wrote:
On 2010-08-27 09:58, Basil Chupin wrote:
On 27/08/2010 00:03, Carlos E. R. wrote:
Incredible....We are in this situation after some close to 30 years of having error-correcting protocols.....Unbelievable :-( .
I use a Firefox Extension called DownThemAll! which has never given me a bad CD or DVD - and it resumes from where I lost the connection (which never happens now :-) .) I also find that the downloader in Firefox now also resumes from where the connection was lost and it also produces a "clean" file - but this latter downloader has not been under any "real strain" since it was upgraded by Mozilla.
Notice that this doesn't guarantee a correct download, the http or ftp protocols don't allow that. You need something else for verification of the download, and then retry. This can be automated, but you need a verification method.
DownThemAll! verifies the download (provided that a metalink contains hashes). However, it doesn't verify chunks of the file - only the end result. Even though this doesn't guarantee that you get a correct result, it guarantess that you don't get an incorrect one. (HTTP/FTP themselves have no provision for this, that's true. That's why there are metalinks. Okay, HTTP does have a special header that has recently been updated to support modern hashes (RFC5843), but it's not used yet. And for FTP people are working on a standard. But it's not ready or even used anywhere. Metalinks are ready, actively used and standardized in RFC 5854.)
For example, if the download manager knows the expected crc, it can insist downloading chunks until the result is good. But blindly, because it can not know what section of the file has the error.
Yes. The download manager aria2c (which has been mentioned before) uses all the hashes and verifies chunks of the file (which it is in transit) and re-downloads pieces from other mirrors if an error happens. Chunked hashes are all available with openSUSE downloads. Hopefully, the number of download clients that actually use them will increase in the future. Peter
On 2010-08-29 22:14, Peter Pöml wrote:
On Sat, Aug 28, 2010 at 04:35:04AM +0200, Carlos E. R. wrote:
On 2010-08-27 09:58, Basil Chupin wrote:
Notice that this doesn't guarantee a correct download, the http or ftp protocols don't allow that. You need something else for verification of the download, and then retry. This can be automated, but you need a verification method.
DownThemAll! verifies the download (provided that a metalink contains hashes). However, it doesn't verify chunks of the file - only the end result.
He did not say he was using a metalink. Things change a lot. We were talking of plain old html/ftp.
Even though this doesn't guarantee that you get a correct result, it guarantess that you don't get an incorrect one.
(HTTP/FTP themselves have no provision for this, that's true. That's why there are metalinks. Okay, HTTP does have a special header that has recently been updated to support modern hashes (RFC5843), but it's not used yet. And for FTP people are working on a standard. But it's not ready or even used anywhere.
Ah, that's nice. Too late, but nice. Perhaps they though that the checksum in tcp packets were enough security.
Metalinks are ready, actively used and standardized in RFC 5854.)
I know. Although... I was surprised the other day when Yast got three corrupt rpms and I had to tell it to retry, manually. I though that aria2c was already the default or enabled (11.2). I still have to review the logs, I forgot.
For example, if the download manager knows the expected crc, it can insist downloading chunks until the result is good. But blindly, because it can not know what section of the file has the error.
Yes. The download manager aria2c (which has been mentioned before) uses all the hashes and verifies chunks of the file (which it is in transit) and re-downloads pieces from other mirrors if an error happens.
But they are not using aria2c, that is the problem.
Chunked hashes are all available with openSUSE downloads. Hopefully, the number of download clients that actually use them will increase in the future.
Not many people are aware of its existence. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Thu, 2010-08-26 at 22:38 +1000, Basil Chupin wrote:
On 26/08/2010 19:17, DenverD wrote:
Basil Chupin wrote:
On 26/08/2010 18:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is...
says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Why not run the DVD and select the option to test the DVD for errors? This will 'tell' you if the DVD is broken.
but why waste the time burning a disk with a known wrong md5sum?
i'm pretty sure the answer to his problems is to fetch a full and correct image...
I've seen such responses before - and they puzzle me.
Since the 1980s we have had download protocols which use CRC to ensure that the file being transmitted is received correctly. So what has happened to this feature?
I've had numerous bad dl's using a web browser as well as using wget, that checksum would be nice to have, if it could identify the bad chunk and request it be sent again. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-27 03:21, Mike McMullin wrote:
I've had numerous bad dl's using a web browser as well as using wget, that checksum would be nice to have, if it could identify the bad chunk and request it be sent again.
Have a look at what the metalink for the dvd looks like. You will see (it is a text file, actually) that it contains a list of mirrors and methods, plus a list of checksums for a hundred or more chunks. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Thursday 26 of August 2010 11:59:53 Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD- i586.iso.md5 says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
The checksum of my image is 1a1da28c84e3cdad750d5cfa21c4fd17.
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum?
Probably the official one. Could you try downloading again? Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 26/08/10 09:59, Josef Wolf wrote:
Hello,
http://download.opensuse.org/distribution/11.3/iso/openSUSE-11.3-DVD-i586.is... says that the md5sum of the opensuse-11.3 dvd should be
1a1da28c84e3cdad750d5cfa21c4fd17 openSUSE-11.3-DVD-i586.iso
but the file I downloaded today from http://software.opensuse.org/113/de gives:
jw@kiste> md5sum /var/tmp/images/openSUSE-11.3-DVD-i586.iso d66ce5f7061b586cdd5406f9dbe7cfa1 /var/tmp/images/openSUSE-11.3-DVD-i586.iso
What would be the correct md5sum? If you downloaded directly, (i.e. HTTP/FTP) and the md5sum's don't match it is most likely that you got a corrupted download - you can try repairing it with BitTorrent if you don't want to redownload.
The md5sum on the site is correct. Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (9)
-
auxsvr＠gmail.com -
Basil Chupin -
Carlos E. R. -
DenverD -
Josef Wolf -
Mike McMullin -
Peter Pöml -
Tejas Guruswamy -
zGreenfelder