Installer Features

Things we think we need. Put this in issue #blah - we don't need another working doc.

Mantra

We generally don't want ublue specific things, our intent is to help give feedback so that it improves the OCI installation experience in Fedora and then eventually the EL family of distros.

What we have

https://universal-blue.org/installation/
https://universal-blue.org/images/

These pages show some of the bandaids we have to do to get the end user to an installed state

• Many parts of ublue are workarounds - the initial installer utilizes kickstart.
• The offline installer writes an image to /var/image/ublue-os - and then the ublue-update service live-rebases the system on first update to a signed image. This is because there's no way to directly install a signed image. This is one of the most critical workarounds in ublue that we would love to move away from.
• TPM is a challenge for us to implement properly
• Flatpaks are installed by service units we make to install them on the machine after first boot. This is fragile and the 2nd worst thing we want to delete. otaylor opened this feature in upstream flatpak to help support distro flatpak installation: https://github.com/flatpak/flatpak/issues/5579

What we think we need

Lots of this is written in "Jorgeisms", feel free to edit. I will also add things that osbuild already has but are net new to us so the community can follow along with the "feature list". Would love to skip the old school Anaconda and go right to the new web ui. (See the marketing section for more details)

Offline ISO

A fully Fedora offline experience that does not require internet to install.

Use cases

• Bazzite - it's a mobile device and that team prefers a full offline installer for reliability reasons
• Anyone who runs a lab - users have asked for an offline experience so that they can make custom images to deploy labs in places with limited internet. "Burn 50 usb sticks at the home base, ship to this conference"

Features

• Build ISO from the osbuild tool. (With and without a container seem to be working?) - bootc-image-builder
• Ability to build it in a github action
• Ability to build via podman
• Ability to generate cloud images with the same tooling. Other clouds can be plugged into osbuild so we're pretty good here – as they get added we "get those for free"
• Ability to directly install a signed OCI image directly without need for the user to ever use an unsigned image. [#1 req, MVP needs this]
• The installer experience should be the same as upstream Fedora.
  • Adding the user account on firstboot.
  • Adding the user account to specific groups
  • Have the same partition layout as upstream (Currently there is hardcoding to use EXT4 rather than BTRFS which is what is used upstream)
  • Configure Full Disk Encryption
  • Allow for networking configuration and choice of hostname.
• The ability to use kickstart files in a way a linux sysadmin expects. (ublue todo: we need examples in our repos for people to derive from, or if upstream has some …)
• No deviation from standard Fedora - we don't want "the ublue way"

Netinstaller

All features in the Offline ISO but with a netinstaller. We don't think this is critical for an MVP.

• Primary reason: Github hosting limits us to 2GB per file, therefore we need a way to reuse the actions from the above section but generate a netinstaller and attach it to GitHub releases.
• Hosting offline ISOs will be a challenge since we'll depend on third parties, etc. This is possible since lots of distros do this. However, we are not popular enough to just apply to a typical mirror network.
  • Even with hosting we'll only do offline ISOs for bazzite, bluefin, and ucore
  • ALl the other images we'll expect people to generate their own via podman, or hook up the github action to their own custom repo.

Flatpak

A way to declare what flatpaks, flatpak remotes, and runtimes will be installed on the custom image. Strongly prefer something that can be hosted in a git repo and then piped to the installer.

• In the offline case it should be added to the image
• In the netinstaller case it should grab from the remote directly so the latest apps are installed without the user having to run an update after first boot

A working Progress Bar during install

The hardest problem in computer science:

Marketing

This is the new installer for Fedora Silverblue and Kinoite. It is critical that this isn't seen as "the new ublue installer". It is a preview of the new Fedora installer that we're working with the osbuild team on. We're the hot rod shop doing the work with upstream. If we are not clear on this people will just make things up, so we gotta be specific.

• The OCI feature in Fedora requires adding the ability to install signed OCI image directly onto the device, this requires upstream work in Anaconda.
• The osbuild team exists with the purpose of [insert purpose here]
  • Most fedora users probably have no idea osbuild exists, so let's use this as a way to introduce the team's work to the community.
• The osbuild install will get Fedora users the following features
  • A web ui to make your own custom image (do we have screenshots?)
  • Podman desktop will add a custom image feature right in the flatpak application itself
  • "Imagine building a custom image on your friend's windows machine with podman to make it perfect before they install!" -> then just burn the ISO.
• Local Deployment
  • Usage of existing OCI tooling allows for total control.
  • Use your existing onprem or cloud registry, build your own images, run everything locally.

Why the new UI?

Anaconda doesn't have an awesome reputation with the end user/enthusiast community - which is why we think we should go right to the new web ui, otherwise people will criticize it even if the features are awesome.

We're willing to deviate with upstream on this one even if it's more work for us.

Timeline

We follow Fedora so "Fedora 40" would be the target goal

• There's always the risk that OCI Native Containers and the new installer get bumped to F41
• We're totally fine with that, one more cycle of "beta" is fine, it's just a label.
• We're also capable of shipping anything out of band in fedora, so if we need to run a copr for things with intergrated patches, that's an option.