[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2° Weekly "wheezy" from jigdo file md5sum errors

On 04/04/2012 20.55, Thomas Schmitt wrote:
Alex<alex@laseroffice.it>  wrote:
Of course, for .iso DVD incorrect, change only last row in error and image
is not good.
You have any idea ?

It would be interesting to see the whole message output of a failed
jigdo download attempt.
Maybe you can get such a log by
    jigdo-lite ...usual.options... 2>&1 | tee -i /tmp/jigdo-lite-message-log
(you will have to repeat the tries until one fails to verify its result).

If file /tmp/jigdo-lite-message-log is too large for the list, maybe you
can put it on some publicly reachable web space ?

OK ... next week I do it and upload on my web space.

Goal is to determine from where the alteration sneaks in.
Afaik, there are three sources of data involved:
- The .template file provides the framework of meta-data blocks of the
   ISO filesystem.
- The local data files from previous DVD versions ("Files to scan")
   provide most of the data blocks which get inserted into the holes
   of .template.
- The remote data files ("Debian mirror") provide content for those
   holes, where the MD5 checksum that is recorded in the .jigdo file
   did not match the checksum of the local file.

Template file and jigdo file get produced by Debian via libisofs and libjte.
It is likely that these two files are ok on the download server.
So something goes wrong during your download in particular.

The .jigdo file should be verificable by its gzip CRC-32:

The .jigdo file contains a checksum of the .template file:
    gunzip<debian-testing-i386-DVD-1.jigdo | fgrep 'Template Hex MD5Sum'
I assume jigdo-lite checks this, but it cannot harm if you compare the
the checksum of your downloaded .template by yourself:
    md5sum debian-testing-i386-DVD-1.template

The data files are covered by MD5 checksums in the .jigdo file.
jigdo-lite is supposed to compare these with the local files and to take
them only in case of checksum match. Else it should download them
from the mirror (and check their MD5s afterwards ?).

So, if everything is working as expectable, there should be an error
message about a non-matching checksum with a particular file, before
finally the whole ISO image fails to match its checksum.

The main problem consists in verifying the correct execution of jigdo-lite file.
The output is huge because of the wget messages on the console, I think.
How can I mute only that ?

I run my script in the night for update all disks .iso image (i386 and amd64) and it was OK for last ten years about :) I believe, the problems begin post I change PC motherboard and HD storage (previous IDE, now SATA), or/and I change from debian Squeeze 32 bit at now 64 bit.
The new motherboard and hd work fine in all other jobs.
Next, I download full .iso image for checking if this problems also afflicts a simple download with FileZilla.

Meanwhile, thanks to all


Reply to: