Skip to content

Expose installer images automatically#16

Draft
samueldr-at-cyberus wants to merge 14 commits into
cyberus-ctrl-os:mainfrom
samueldr-at-cyberus:feature/expose-installers-automatically
Draft

Expose installer images automatically#16
samueldr-at-cyberus wants to merge 14 commits into
cyberus-ctrl-os:mainfrom
samueldr-at-cyberus:feature/expose-installers-automatically

Conversation

@samueldr-at-cyberus

@samueldr-at-cyberus samueldr-at-cyberus commented Jan 25, 2026

Copy link
Copy Markdown
Contributor

(Follow-up to #15)

This diff view will be easier to review


This PR exposes images automatically for every device we are adding to the repository. The knowledge necessary to build a compatible image should be coming entirely from the device description, and as few details as possible should be coming from the installer expressions.

This might not look like it's useful, but this is also the beginning of thinking about composable configurations. We have the technology.

~/.../CTRL-OS-modules/hw-jetson-reworked $ nix repl .
Lix 2.93.3
Type :? for help.
Loading installable '...#'...
Added 9 variables.
nix-repl> (legacyPackages.x86_64-linux.hardware.devices.installers.nvidia-jetson-orin-nano-super.iso.eval.extendModules { modules = [ { networking.hostName = "foobar"; } ]; }).config.system.build.toplevel.name
"nixos-system-foobar-cross-from-x86_64-linux-26.05pre923638.5912c1772a44"

The main rationale behind this PR is to help with future additions to the repo. We shouldn't have to maintain a set of bespoke config attributes for devices we add to the repo, they should come up for free, exposed in some way.

Right now we have the iso and sd-image exposed. The SD image is the one for AArch64 systems, so that's one issue to fix. We should add a generic/mainline-x86_64 system or something to that effect for hardening our design against ARM-brainedness. (We should also add generic/mainline-aarch64, which in the end should result in the stock installer without device-specific configs.)

I'm not a fan, though, of using “packages” (be it legacy or not) to expose ISOs. To me, packages should be things that realistically will be added to a system, not random artifacts. But I don't know how that would be handled with this flake-parts structure. So that's left to be determined.

messemar and others added 14 commits January 27, 2026 10:47
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
The device name (even though the vendor does not seem to always spell it
out), includes “Super”.

I'm using the fact that the innate DeviceTree for the platform uses the
model name:

```
NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super
```

The `compatible` is `nvidia,p3768-0000+p3767-0005-super`.

For this reason, we shall always use “super”.

Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This will ensure the `mkIf` conditional is always *coherent* with what
it should be.

Otherwise, copy/paste mistakes can become awkward to debug.

Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is the first part of a change set that mirrors a commit from
Julian. This only *moves* the files and module itself around, the
options names are changed in the follow-up commit.

Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is the final part of a change set that mirrors a commit from
Julian. This one renames the options from platform to hardware devices,
better future-proofing the options.

This also has the benefit of not re-using a term (platform) that has an
existing meaning with Nixpkgs things (`stdenv.hostPlatform.system`), and
should make it less confusing to discuss about.

Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is WIP because this is currently using the `legacyPackages`
Flake output attribute, but I believe this is the wrong thing to do.
These are not packages, they would not be added to a user's system.

The `flakeModule` design seems to break down once you need something
that isn't in the "well-known"[sic] outputs of Flakes.
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
@samueldr-at-cyberus samueldr-at-cyberus force-pushed the feature/expose-installers-automatically branch from 09830c2 to e035ec4 Compare January 27, 2026 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants