WIP: Separate installer and sub-components as skeleton from updatable system

[yfyf]

Reviewing the general situation, I believe it makes little sense that we mash together the packages and configuration needed for the runtime system and the installer into one big mess.

The installer really only needs the system image (a tar blob) + system metadata (a bunch of strings) as inputs. It does not care about what packages are in the system or how it is configured.

In fact, it should be the opposite, the runtime system should depend on the specific skeleton/layout produced by the installer, which involves:

• bootloader
• partition layout
• RAUC statusfile paths

This PR attempts to break apart the two systems, paving the path for a clear delineation between "skeleton" and the updatable system.

In particular:

• nixpkgs are no longer shared between installer/skeleton and runtime/updatable system
• nixos configuration is no longer shared
• RAUC and dependencies are pinned in the installer/skeleton and the runtime/updatable system re-uses it to ensure identical versions across releases that do not "evolve" (note: not strictly necessary, but since we anyway pin RAUC's version in the runtime system, might as well pin it all the way with the deps to the skeleton version? The resulting bundle size increase is only 50MB)

TODOs:

• Store the installer/skeleton ref/version in /boot so that playos-diagnostics can read it easily
• Decide if installer/ to be renamed to skeleton/ officially
• Decide if we want to version the installer from the get go or not
• Decide if installer gets it's own git repo / versioning
• Decide if installer becomes a flake
• Decide on the pinned nixpkgs version in installer/skeleton
• Populate system.nixos.label and environment.etc.os-release using the systemMetadata

[yfyf]

E2E tests seem to pass 🥳

[yfyf]

This might be an overkill, because it pulls in all the dependencies from installer's nixpkgs.

If we want to avoid this, we could do:

Suggested change

	rauc = (import ../installer/pkgs).rauc;
	rauc = (import ../installer/pkgs/rauc) super;

The resulting RAUC bundle size difference is quite minimal, around 50MB:

• with RAUC deps from runtime nixpkgs: 1323M
• with RAUC deps from installer nixpkgs: 1371M

[yfyf]

Further thoughts regarding skeleton versioning and update testing in the context of this PR.

With a bit effort, we could put the installer/skeleton into a separate git repo, even convert it into a flake with just two inputs (systemImage, systemMetadata) and several outputs (ISO, installer script, etc). This way the installer/skeleton can be tracked and used as a versioned dependency. You could define and build things like "PlayOS 2027.1.0 (<gitref>) installer with skeleton 1.0 (<gitref>)".

However, versioning the installer/skeleton is not strictly necessary for automated testing, because I think the current release validation testing already covers all the relevant scenarios:

• If skeleton is unchanged in the PlayOS release: we only need to test that current runtime system is compatible with the current skeleton and earlier skeleton versions. Testing compatibility is covered by the second self-update in release-validation tests (Refactor and upgrade release-validation to perform a double-update #309), plus currently this PR eliminates possibility of unexpected divergence by pinning RAUC+deps. We already test against multiple "skeletons" by testing against multiple previous PlayOS releases (Automatically run release validation tests in CI against multiple base systems  #307), we might just want to add an extra target for a "truly ancient" PlayOS version.
• If skeleton is changed in the PlayOS release:
  • PlayOS releases (runtime systems) that were released with the earlier skeleton version do NOT need to be tested, since it is safe to assume the updated skeleton will not be used for running previous releases. This is a side-effect of the fact that we do not do rollbacks.
  • Future¹ PlayOS releases need to be tested against this new skeleton version. That will happen, however, as a side-effect of a new PlayOS release disk being produced with the new skeleton during the release process and it being included in the release-validation testing matrix. It effectively goes back to the "skeleton is unchanged in the PlayOS release" case.

It might be useful to have the skeletons versioned anyway for nomenclature / process reasons, so that we can easily refer to them when documenting things and etc.

Footnotes

1. In theory it is "all future PlayOS releases forever", but if we define a "skeleton EOL" (e.g. +10, 15 years?), we could reduce the window of how much backtesting we need to do. ↩

[knuton]

Very good thinking, this seems like a great approach and conceptual cleanup!

[knuton]

Since we don't plan to bump this on the regular, maybe there's some kind of context to capture about the specific version picked

(Comment probably premature)

[yfyf]

Yeah, this is just temporarily set to one of the earlier releases (dc92081). It's an important question to decide on what this should be set to as it would become the "golden standard" for a long time.

[knuton]

I support a new greeting art, and inlining it

[yfyf]

The current greeting is broken also, because the label text overflows the next line gets indented.