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

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


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 ?

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:
   gunzip <debian-testing-i386-DVD-1.jigdo >/dev/null

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.

Have a nice day :)


Reply to: