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

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

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

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 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 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))

...

...

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 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 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 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))