Re: missing files from different formats of the .iso files

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

griffin tucker wrote:
> jigdo-lite runs in batch mode, and usually the reconstruction of the
> first .iso is completely reconstructed from a directory of mounted
> .iso's from another format, however, the next few .iso's will
> consistently have 1 file missing that it couldn't find from the
> mounted .iso's, when it should, and i am unable to determine the
> pattern or reason for this

Could be a problem of jigdo-lite with this special file presentation.

Does the missing file have a particular position in the .jigdo file
which you use for composing the new ISO ?
  gunzip < *.jigdo | less

Does it exist in the mounted ISOs and does its checksum match ?
  echo '...char.salad.from.jigdo...'==  | sed -e 's/-/+/g' -e 's/_/\//g' |
    base64 -d | od -t x1 | sed -e 's/^.......//' -e 's/ //g'


I wrote:
> >   In this case the checksum is MD5. Expect to see SHA256 in newer .jigdo.
> >

> i look forward to the sha256 or sha512 implementation

In this case, the MD5 is not used as verifier but as access key.
When it gets found in the .template file it is looked up in the .jigdo
to get the download URL of the file.
Verification should be done by the overall checksum of the ISO as
published in the SHA256SUMS or SHA512SUMS files which accompany the .jigdo
and .template files.

So i don't see much reason to switch internally to SHA256.
But MD5 has a bad reputation in Debian and so the Jigdo format was
enhanced to use SHA256 instead. Interestingly, even
debian-12.0.0-amd64-netinst.jigdo still uses the shorter MD5s.
(xorriso-1.5.4 in Debian 12 is capable of producing SHA256 in the .jigdo
files. The development version xorriso-1.5.3 can do it since end of 2019.)


> i'm running it in a virtual machine, if that makes a difference
> (afaik, it shouldn't)

That would be indeed astonishing. I rather bet on the mounted ISOs as
trigger. (But i have no stake in jigdo reconstruction, only in its
production as developer of xorriso.)


---------------------------------------------------------------------
Off topic:

I wonder what those unusual headers with changing names in your mails
mean:
  X-Coil-Desert: 4e292ddc276fab1b_1687051700717_2547565298
  X-Obese-Wide-Eyed: 37ca251540d1f045_1687078216293_605541665
  X-Ruddy-Name: 05f4b58c06a9aab5_1687078216565_3930339659
always between
  X-MailChannels-Auth-Id: ...
and
  X-MC-Loop-Signature: ...


Have a nice day :)

Thomas