I spend a lot of time with Rocky on RPi. This week, I installed a pair of 8s (8.4 and 8.5 then upgraded them to 8.7) and the current version of 9. It’s no big deal to download the iso and burn it with Balena. I keep watching distros come and go in the Raspberry Pi Imager. A new one came out this week and I searched with baited breath to see Rocky. Sigh, disappointed again.
The products are wonderfully complete and stable so I imagine that it would be beneficial (and not too challenging) for both Rocky/CIQ and RPi Trading to get together to include R8 and R9 in the distros available on the imager.
I will gladly volunteer my meager services in such a project (certainly not needed but. . .)
I’ve heard of this, but never used it - I always just seek out the specific OS/image I’m after.
I don’t have a lot of time at the moment, but maybe someone who knows more about this project could talk with them, or issue a pull request? It looks like OS-specific info is stored in data files in the doc/ folder(?) : rpi-imager/os-list-schema.json at qml · raspberrypi/rpi-imager · GitHub
Note: Mostly unrelated, but I would change “CIQ” to “the RESF”, as CIQ is a sponsor, not the owner of Rocky Linux. The site does make this clear, but I wanted to clear it up just in case for you.
The raspberry pi images for Rocky are not in an ISO, they are compressed images as seen here for Rocky Linux 9. There is also an 8 one.
The rasperry pi imager likely pulls prebuilt images (like our own) and plasters them to an sdcard or otherwise. I’ve not used it, so I can’t be certain. But when I look through json’s of what the imager supports, they’re pointing to compressed images, which tells me those are already prebuilt.
There is a massive difference between an ISO that is upwards of 8+ GB’s that is meant to boot up and install to a hard disk to a rasperry pi image that is a 0.5GB that is prebuilt and ready to be used.
The downloads for the raspberry pi images are in the alternative images section: Alternative Images | Rocky Linux - It’s not clear at the get-go, so I understand that it can be confusing.
So far, every reply that you have made to me about this project is to be critical or to point out that I’m wrong. I have corrected the trivial reference to CIQ to RESF in your first critique.
This wasn’t a critique actually. This was to clear up who manages/develops Rocky Linux. This happens often enough in other scenarios that we have to correct it when it comes up.
You don’t know, you have no experience with it but you speculate authoritatively.
My speculation was based on prior experience of preparing a raspberry pi to run something, as well as watching others in the community and interactions in SIG/AltArch. I’ve never used official imagers, just dd or the likes of xzcat. The readme provided by SIG/AltArch briefly talks about it too. Though the alternative images page doesn’t link directly to it, but it is found alongside the images on our mirror.
Rather than criticize and speculate, if you actually know something about this, please respond to my request for assistance
I am trying to help where I reasonably can. I’ve provided links to the compressed images and links to where they can be downloaded. I also looked at the json link you provided as an example and made an educated guess that the raspberry pi imager takes compressed images and plasters them to an sdcard, similar to dd or xzcat.
Louis has been answering your questions and providing feedback. I sorry you feel you are not receiving support, but tagging Greg here is really uncalled for, as is being argumentative and dismissing our project member’s knowledge and experience.
Please consider that we are volunteers working on this project, and are giving best effort support to help people who wish to work on projects like the one you are suggesting. I do think that inclusion in this project would be a good thing for Rocky, and so I welcome the addition of this, however there is a way in which things like this get done–and it’s not usually by belittling the people who work on the core parts of the project itself.
That being said, I think arguing over this is a waste of time and energy, and we should instead focus on what this topic is actually about.
</mod hat>
Regarding this project overall - it seems like there are just a couple pieces that we need to figure out here, and I appreciate your effort in figuring out these details. From what I can tell, Raspberry Pi hosts some json file which contains references to other project’s images which can be installed from the installer.
It’s still not clear to me on the RPI side what we need to supply to them, but the schema for listing what images we have published seems well enough defined that we can put in some tickets to investigate how we might integrate this into our toolkit and generate this JSON file when we add/update images on the CDN.
For next steps, let’s figure out that this JSON might look like for our images, and then it can be tested locally using the --repo parameter for the Pi Installer tool to point to a locally hosted copy of the JSON which describes our images. From there, we can create tickets to track adding this into the toolkit and get them scheduled/prioritized with our other tasks.
@nazunalika twice posted links, first directly to the images themselves and again when he replied and mentioned the Alternative Images page. It seems you missed this twice as this is what you have been seeking I believe yes?