#5 Split installation configuration to be friendly for preloading on hardware (OEM install)
Closed: Fixed by ngompa. Opened by ngompa.

The current way Fedora KDE is installed on a system has Anaconda configuring all the host-specific information up front during initial installation.

This is problematic if we want to have OEMs be able to preload Fedora KDE like Lenovo is doing with Fedora Workstation.

We currently lack an equivalent to gnome-initial-setup, but perhaps we can configure Anaconda's firstboot functionality for this? Ideally, we should have something KDE-native for this role.


Metadata Update from @ngompa:
- Issue tagged with: meeting

In the KDE SIG meeting today, we discussed this and @appadeia noted that they are developing a new application along those same lines, called kiss (KDE Initial System Setup), that can solve this problem for us. We'll work with them to figure out what needs to be present and start working on using it as soon as possible.

Once ready, we'll change the Fedora KDE Anaconda configuration to disable all the steps that kiss will handle instead.

Metadata Update from @ngompa:
- Issue untagged with: meeting
- Issue assigned to appadeia

It occurred to me that we never wrote down exactly what we're aiming to provide through initial setup...

For Fedora KDE with KISS, we've previously discussed that the following sequence is desired:

  1. Welcome
  2. Locale and timezone
  3. License agreement
  4. Privacy settings (location services, ABRT crash reporting)
  5. Network setup (Wi-Fi, cellular, etc.) and computer name (hostname)
  6. User account (with the option of enterprise Login through SSSD/realmd)
  7. Online Accounts (Google, ownCloud/NextCloud, Microsoft, Fedora, etc.)
  8. Optional panel for subscription management enrollment (if on RHEL, since Fedora KDE SIG manages KDE for RHEL now)
  9. Third party sources enablement
  10. Launch tour (if one ever exists...)

Would be super nice to have swap/hibernation setup too, https://bugs.kde.org/show_bug.cgi?id=432887

Giving this one a try with https://pagure.io/fedora-kickstarts/pull-request/840

Given that initial-setup-gui does not work right now, we'll remove it and try to make https://invent.kde.org/cblack/kiss available and useful instead.

@marcdeop packaged kiss a while ago: https://src.fedoraproject.org/rpms/kiss

The most recent discussions around this have been with @nicolasfella around extending @ngraham's plasma-welcome to add a first-stage environment to do the bare minimum steps for the "no-user" initial provisioning:

  1. Welcome
  2. Locale/language and timezone
  3. License agreement
  4. Network setup (Wi-Fi, cellular, etc.) and computer name (hostname)
  5. User account (with the option of enterprise Login through SSSD/realmd)
  6. Optional panel for subscription management enrollment (if on RHEL, since Fedora KDE SIG manages KDE for RHEL now, and this can be a plasma-welcome plugin/addon/custom page thing)
  7. Third party sources enablement (this can also be a plasma-welcome plugin/addon/custom page thing)

The rest of the steps are already handled in the per-user Plasma Welcome mode that exists now.

Metadata Update from @ngompa:
- Assignee reset

Metadata Update from @siosm:
- Issue tagged with: kinoite

Or we ship Calamares like Fedora Asahi Remix does it right now.

Calamares is restricted to the architectures with UEFI or BIOS (x86_64 and AArch64). It also has trouble operating properly in Wayland just like Anaconda does.

I've made a test Kinoite pre-installed QCOW2 disk image using the experimental support in Kiwi with the Calamares first boot RPM from Asahi and it appears to work pretty well. I would say that x86_64 & aarch64 support is a good start.

Given that initial-setup-gui does not work right now, we'll remove it and try to make https://invent.kde.org/cblack/kiss available and useful instead.

https://fosstodon.org/@kalpa/112779178647408486
It looks like OpenSUSE is going to try to restart working on KISS. It might be worth joining their efforts here if Calamares is insufficient

The intention is to work with @sfaulken on KISS, yes.

Metadata Update from @ngompa:
- Issue assigned to sfaulken

This is now done with Fedora Linux 44! :wine_glass:

Metadata Update from @ngompa:
- Issue assigned to ngompa (was: sfaulken)
- Issue close_status updated to: Fixed
- Issue set to the milestone: Fedora Linux 44 (was: Future Release)
- Issue status updated to: Closed (was: Open)

Metadata