I have Qubes-R4.2.4-x86_64.iso, which required borrowing someone else’s decent Internet connection to obtain. Now I would like 4.3.0, without having the fetch all 8 gigs of that ISO. In principle, it should be possible to mount an old ISO image and grab a jigdo template, to then just grab the differences needed to build the latest ISO.
Welcome to QOS…
Im trying to understand and to help you but need a bit more from you…is it your internet connection or the size of the iso the challenge here ?
enjoy IT
If the connection is unstable you can try the torrent. If you have some kind of data limit, try to in-place upgrade from 4.2.
1 Like
Unfortunately, I’m quite sure the difference would be around the same size of the ISO itself because everything changed or is under some compressed format that won’t allow you to have a delta between the two version.
I usually have no Internet at home. Occasionally, I have mobile broadband with a 4gb cap for a month.
To get qubes, I go to a public access point.
1 Like
@parulin apparently believes upgrading after installing will demand significantly less than 8gb. So it seems there is no concensus on the proportion of change.
The compressed product of a package should not change one bit if the package does not change. Nonetheless, I believe jigdo works off of filenames not diffs or hashes. E.g., if you have:
(release 1)/somePackage_v1.2.3.tar.gz
(release 2)/somePackage_v1.2.3.tar.gz
Even if those files would have a binary difference for some strange reason, I believe jigdo would opt to re-use the release 1 version when building the ISO. But then the expected hash would not match the template and jigdo would detect the failure when it verifies the ISO. From there, I do not know if jigdo is sophisticated enough to pin down the difference and sort it out.
If jigdo could save a few gigs, it’s worthwhile to use it. The mirrors would get some relief and there would also be a reduced climate footprint w/bittorrent and otherwise. If it would save <1gig, perhaps not worth it.
Another consideration:
I have not yet used Qubes, but I was told it includes Debian. I sometimes grab the full-blown version of debian (~120gb). But it’s not that crazy with jigdo because many apps do not advance from one release to another. In any case, it does not seem ideal that Qubes includes Debian. Would a version without Debian be much smaller?
1 Like
I think you are on your own on this topic, nobody is working on this as far as I know. Jigdo can’t be used on its own without using it server side (it’s like bittorrent but server-client instead of peer-to-peer).
Although packages may have the same version between two debian releases, they are compiled using different toolchains so the binary files are different. Some assets may be identical though.
As Qubes OS iso ships RPM packages that contain the templates (fedora / debian and I don’t know if it’s an iso, a squashfs or a raw disk) that themselves contain packages in deb/rpm format, I have no idea how to use jigdo here to make a diff between two releases as there are multiple layers of archiving going on.
This is an interesting project to reduce bandwidth usage by downloading the delta between two releases, but it’s work to be done.
4 Likes
I haven’t really monitored my upgrade from 4.2 to 4.3, but that was my impression. After doing an in-place upgrade from *debian-12-xfce` to debian-13-xfce, I think my impression was wrong (you might save a few hundred MiB only).
By installing Qubes 4.2 you might be able to remove unwanted templates before upgrading to 4.3 (you can save 1 or 2 GiB).
By the way, Debian and Fedora template have quite the same size. I have a preference for Debian because it works well with apt-cacher-ng.
But if you don’t have any experience with Qubes OS, doing in-place upgrades might be difficult.
Hi dataSubject - and welcome to the forum! 
I have a nagging suspicion, that without the full/original ISO, your generated ISO will have a different md5sum/sha1sum/sha256sum/sha512sum checksum, so any checks against the public/signed sums will be void – even if all the files on the ISO are identical 
1 Like
Jigdo does not have its own protocol or server. A Debian mirror naturally contains a tree of *.deb files covering all apps and this is entirely independent of jigdo. A jigdo user can (if they want) supply an old ISO image to jigdo. It will harvest what it can from that local ISO and grab everything else simply using wget. The server is entirely unaware of jigdo. The server simply has some jigdo template files in a directoy that jigdo grabs using wget (or the templates can be fetched by the user and given to jigdo).
I get the impression Qubes files are not separately available on the mirrors… so I guess making all the files individually available is where the human labor would be.
Regarding what you say about layers of tarballs/deb/rpms embedded inside ISOs that would then be nested inside the top ISO-- this would not break jigdo, but jigdo would likely treat those nested things as a single atomic object and thus we would lose efficiency of re-use for that data. So if there is much of that, then indeed it could create a diminishing return for jigdo.