[RFC 0125]: Use an intermediary representation (bootspec) for bootloader backends #125
Conversation
…r backends 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.
spacekookie
added
the
status: open for nominations
|
Hey everyone, this RFC is open for shepherd nominations now |
…ghtly by integrating bootspec
|
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. |
edolstra
changed the title
Relocate to $out/boot.json, top-level key of specification version
|
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 |
|
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? |
|
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). |
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 |
|
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. |
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. |
|
Can't we use JSON schemas for validation or is this more complex? |
|
It is more complicated than JSON schemas enable to express. |
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. |
lheckemann
added
status: accepted
and removed
status: FCP
|
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 |
This introduces the second revision of RFC-0125, Bootspec, addressing the feedback we received in NixOS#125 and building on our experience of Bootspec v1.
This introduces the second revision of RFC-0125, Bootspec, addressing the feedback we received in NixOS#125 and building on our experience of Bootspec v1.
This introduces the second revision of RFC-0125, Bootspec, addressing the feedback we received in NixOS#125 and building on our experience of Bootspec v1.
This introduces the second revision of RFC-0125, Bootspec, addressing the feedback we received in NixOS#125 and building on our experience of Bootspec v1.
…der backends (NixOS#125) * RFC 0125: Use an intermediary representation (bootspec) for bootloader backends 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. * bootspec: relocate to $out/bootspec/boot.v1.json * Clarify that this document describes bootspec v1 * Note that the filename must match the contained schemaVersion. * Replace the specialisation's pointer to a bootspec with the full bootspec document * Clarify the 'to interface with' bit * Link to the bootspec implementation PR * Note it is likely for bootloader backends to change their results slightly by integrating bootspec * Relocate to $out/boot.json, top-level key of specification version * Fix nits from code review Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com> Co-authored-by: Linus Heckemann <git@sphalerite.org> * 0125-bootspec: add the shepherd team and leader Co-authored-by: Kevin Cox <kevincox@kevincox.ca> * 0125-bootspec: initrd is optional, add system, extensions, clarify the meaning of optional * PR: address comments (1) Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com> * PR: address comments (2) Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com> * Update RFC text with changes agreed on with RaitoBezarius --------- Co-authored-by: Cole Helbling <cole.helbling@determinate.systems> Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com> Co-authored-by: Linus Heckemann <git@sphalerite.org> Co-authored-by: Kevin Cox <kevincox@kevincox.ca> Co-authored-by: Raito Bezarius <masterancpp@gmail.com>
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)