ublue-os
Improved Installation Experience
The current installation experience across UBlue projects is suboptimal, often leading to errors, inflexibility, and user confusion. A more streamlined and reliable approach is needed to enhance usability and accessibility.
We have begun exploring potential solutions, including:
- Live ISOs via ublue-os/titanoboa
- A new installer via ublue-os/yai
This issue serves as a hub for discussing ideas, challenges, and plans to improve the installation process. Contributions, feedback, and suggestions are welcome!
CC @travier
Ideally, we would build a derived container image like https://github.com/travier/fedora-kinoite/blob/main/fedora-kinoite-live/Containerfile and then use it to generate a LiveISO. There is currently no support for LiveISO either in kiwi or bootc-image-builder.
What we could do in the mean time is use ideas from https://github.com/ublue-os/titanoboa with this derived container and include the container image on the system as well. That would be 2 times the storage but we should be able to do a run of dedup to turn into hard links the duplicated files.
Then we could tell Anaconda to install the system directly from the container image in the storage. This way we still have all the support for disk setup that Anaconda has.
Actually we should use this for discussion. Ok here's the current plan after some awesome work with the Fyra folks. We were able to get a working installer in about a week. I've been testing it all day and it's looking great.
Redundancy never hurts so having another action in the repo that makes an anaconda installer set of ISOs is totally doable, there way be cases where people want their own kickstarts, etc. Readymade is more for consumer devices so that's where I'm going to spend my time, though I'm sure we'll get there with anaconda someday.
Ok so here's the plan for MVP. Since GNOME has a first boot user creation experience it was easier to knock out, so Bluefin is basically the MVP. Live session, blast the disk, that's it. That's the MVP. Those are most of the items on the board.
Now we need to do the user creation for KDE, and then all the partition stuff for dual boot and all of Bazzite's needs.
We need to construct the ISO testing pipeline first, so we need to prioritize this:
- https://github.com/ublue-os/titanoboa/issues/81
This will ensure that we kick off fresh ISOs on every readymade release (or commit, or both, whatever) and then push them to a bucket so it looks like:
Production ISO: https://download.projectbluefin.io/bluefin-gts-amd64.iso
Test ISO: https://download.projectbluefin.io/bluefin-testing-gts-amd64.iso
Or somesuch, we can bikeshed on the naming convention. The idea being that any time there is a titanoboa or readymade release renovate builds and pushes ISOs automatically. We will have an explicit bucket just for the testing ISOs to keep the seperation of concerns, IMO we should just put testing or something in the filename so that it's clear on my local PC that it's not a production artifact.
And we can count on these URLs so we can add them to the contribution section of the docs. Then when people ask how to help we know for certain that those ISOs will be the freshest. This will allow us to bring the huge bazzite community in to help. As soon as this loop completes we can start to be louder about it because now we can see the goal and we're close.
Then we version lock the production ISOs and version pin them in CI, and we only promote those by hand after the testing ISOs have been vetted with some testing. We should just use release-please, which will then take the versions we've tested, and then run the production action to push new prod ISOs.
Then we'd be done!