Rocky Linux support is likely going to generate a missmatch hash pretty fast
Describe the bug
Rocky linux is pointing to the latest images. However, we did update the GH action update script (update-images.py) to automatically update the hash to the lastest release.
Preferably, we'd not be pointing to the latest release, but to a fully qualified release. We'd update this fully qualified release through the update script.
See what we do for Debian/Ubuntu for more details.
/cc @thefossguy
Items in vault (download.rockylinux.org/vault) are never supposed to be touched. They're historical artifacts. ~But it seems like that isn't respected.~ I noticed the CI at work going all red. Will look into why that's the case and also move away from latest to a fully qualified release.
EDIT: I misspoke. Looked at the logs and this is unrelated. Nonetheless, will look into it before EoW.
Sorry about the hasty response from a few days back. I was encountering an issue similar to the issue topic and assumed both were related. They were not.
About this specific issue, as I mentioned, the download URL for the images are from the "vault" (with the URL download.rockylinux.org/vault). They are historical artifacts and they will "never" change ("never" is theoretically a long time but is true in practical sense).
Regardless, as promised, before EoW, I will have a PR ready that points the URLs to an image that does not have latest in the filename.
Unfortunately, I do not believe that investing in adding support for Rocky in the update script (update-images.py) will be worth it since the disk images are supposed to be static and never to be updated by the RESF, therefore there will be nothing to update.
See #142