[RFC 0125]: Use an intermediary representation (bootspec) for bootloader backends

[grahamc]

Bootspec is a set of memoized facts about a system's closure.
These facts are used as the primary input for bootloader backends like
systemd-boot and grub, for creating files in /boot/loader/entries/
and grub.cfg.

In this proposal we create a stable, comprehensive, and machine-parsable
definition of a NixOS Generation as an intermediate representation (IR)
between the NixOS system definition and the bootloader management tools.

rendered
(thanks @ryantm)

[K900]

The raspberrypi bootloader should probably go away in some form, it's a horrible hack. Another thing for my bucket list...

[spacekookie]

Hey everyone, this RFC is open for shepherd nominations now

[samueldr]

I self-non-nominate. I suspect my nomination is otherwise likely (given my work/interest in the topic). I know from experience that I won't be able to attend to the duties for shepherding this RFC.

I'm still open to ad-hoc questions and opinions though.

[lheckemann]

LGTM overall.

[ghost]

This is really convenient for kexec-based bootloaders (petitboot, ownerboot, etc).

So yeah, device trees in bootspec would be great!
👍
we can work out how to do this in a future revision of bootspec.
👍

[lheckemann]

Moving to FCP, with disposition to accept!

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/bootspec-rfc-now-in-fcp/26598/1

[edolstra]

Do I understand correctly that this makes NixOS depend on Cue? Since Cue is essentially a competing configuration language, making NixOS depend on that might send an unintended message (namely that Nix or the NixOS module system are inadequate). What do we need Cue for that we can't do with the NixOS module system?

[K900]

I'd argue that not using Nix for validation is actually the right call here, because it makes it easier for other systems to adopt bootspec should they want to (and I believe some people were vaguely interested in doing that before, at the very least from the Guix side).

[RaitoBezarius]

Do I understand correctly that this makes NixOS depend on Cue? Since Cue is essentially a competing configuration language, making NixOS depend on that might send an unintended message (namely that Nix or the NixOS module system are inadequate). What do we need Cue for that we can't do with the NixOS module system?

We only use it for schema validation, CUE is completely optional for this specification, you can bring your own schema validator if you need to.

See manual on it: https://nixos.org/manual/nixpkgs/unstable/#id-1.5.8.11.5

[RaitoBezarius]

Also, we cannot validate using the NixOS module because we are writing parts of the file in the derivation builder script. Therefore, we would need to run the NixOS module verification at that moment, which is painful for no reason.

[sternenseemann]

We only use it for schema validation, CUE is completely optional for this specification, you can bring your own schema validator if you need to.

Why does the validator need to be executed on activation? This would imply a (afaik) new dependency on Go for every NixOS system.

[RaitoBezarius]

We only use it for schema validation, CUE is completely optional for this specification, you can bring your own schema validator if you need to.

Why does the validator need to be executed on activation? This would imply a (afaik) new dependency on Go for every NixOS system.

We did not want to ship broken configurations, but you are totally right, this is a problem.
We are more in implementation land, but, would an option to enforce validation be acceptable to you, disabled by default?

[pasqui23]

Can't we use JSON schemas for validation or is this more complex?

[RaitoBezarius]

It is more complicated than JSON schemas enable to express.

[edolstra]

We are more in implementation land, but, would an option to enforce validation be acceptable to you, disabled by default?

Yeah that sounds good. I didn't even consider the build-time dependency on Go, but that's something to be avoided in the base system if at all possible.

You're right this is an implementation issue, it doesn't really affect the RFC.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/boot-entry-management/29119/10