I want to transmit the frustration I’m currently experiencing to get the release I want for Fedora.
My goal is rather crazy: I just wanted to test installing an rpm-ostree-based workstation in a raspberry pi 4. I know I’m doomed, but that’s not the point.
The point is that there are a lot of different installation formats of fedora, all scattered around several websites, and it gets very confusing to find what I need.
What I really wanted was an aarch64 raw.xz Silverblue 34 image. But that’s nowhere.
Some of the paths I’ve followed are:
- Go to https://arm.fedoraproject.org/ and find there’s a workstation raw.xz image, but there’s no iso.
- Go to Descargar Fedora IoT and find there are raw.xz and iso images (cool!). However Zerere has a bug that doesn’t let me provision my ssh key. Besides, if I go to Welcome :: Fedora Docs it tells me to use Silverblue.
- Go to https://silverblue.fedoraproject.org/ and find out there are only iso images, not raw.xz.
- While I’m downloading and testing several images of several formats, I get some network problems, so I want the torrent download to get it faster, so go to https://torrent.fedoraproject.org/ just to find out those are only the iso images (although that’s explained nowhere; you have to download the torrent to see it).
- After all this, let’s try downloading the lxqt spin without rpm-ostree (sad). Go to Download Fedora LXQt Desktop. Guess what? Only iso x86_64.
I was expecting my experiment to go wrong later at some point… but not here!
So my suggestion/proposal/complaint is: please create a single download portal for all fedora flavor images, where I can easily get the image:
- In iso or in raw.xz
- In any supported arch
- Direct or torrent
Of course I’m forgetting about containers and VMs, but you get the point. All this, scattered around, inconsistent… gives a bad experience.
The big difference is the architecture. With x86 you can select a device to boot from and then boot from a network, optical disk, or USB device. So with that ISO you can burn it to an optical disk or USB, or use it to create a PXE boot server. Once the device boots from that image you can run a live OS or choose to install it to the internal storage.
However, with ARM you don’t have that by default. Instead they boot from the SD card slots. So instead of booting the device and then installing from an ISO, you’re basically installing the OS when you “burn” the image to the SD card. The install is basically the act of burning the image to the SD card. Sure your ARM boards can be configured to boot from an optical drive or from the network, but they have to be booted from an OS on an SD card to be reconfigured to boot from other devices.
That being said, ISOs and the raw images are 2 very different images; ISOs are designed to be booted from and then loaded with packages to allow you to install it, and RAW images are essentially a fully working OS that’s written as-is to a disk.
As for things like Silverblue and LxQT, you that’s all up to the teams that develop those. One team does not develop and package all versions of Fedora. Instead when enough interest in some new desktop or whatever builds up, a group may or may not come along and say “Hey, we’d like to develop and maintain a new spin of Fedora”. It’s then up to that group on weather or not they are going to support ARM or if they’ll do an rpm-ostree based image like Silverblue.
But AFAIK for example the raspberry pi is able to boot from an USB. So what would be the problem in preparing a bootable installer just like with x86?
After all, if more companies follow Apple in supplying desktop ARM computers, this is gonna become more common.
OTOH I understand the issues. I just wanted to express a bad UX because maybe all of this means there’s a problem in the image supply process. I think these kind of PoVs are easy to miss for experienced devs. My goal is to help easing that pain for newbies.
Maybe there should be a tool that, given a bunch of parameters, produced all of the available install methods and flavors and uploaded them. OpenSUSE seems to use Kiwi for that, although it might not fix that problem (I never used it).
That’s true, but depending on the version of Pi, it needs to be configured first. I’m not familiar with other ARM boards though, so I can’t speak to them.
It’s really about how the board was designed. Apple might have some sort of a BIOS like an x86 system, or maybe they have something in MacOS to change it. My concern is that they don’t have anything so they lock you into their OS, and installing another OS requires some hacking.