Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 17 commits into from
Apr 2, 2023

Conversation

grahamc
Copy link
Member

@grahamc grahamc commented May 9, 2022

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)

…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.
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
Copy link

@K900 K900 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@spacekookie
Copy link
Member

Hey everyone, this RFC is open for shepherd nominations now

rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
@samueldr
Copy link
Member

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.

Copy link
Member

@lheckemann lheckemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall.

rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
rfcs/0125-bootspec.md Outdated Show resolved Hide resolved
@edolstra edolstra changed the title RFC 0125: Use an intermediary representation (bootspec) for bootloader backends [RFC 0125]: Use an intermediary representation (bootspec) for bootloader backends May 27, 2022
cole-h and others added 2 commits May 31, 2022 08:50
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
👍

Copy link
Member

@lheckemann lheckemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving to FCP, with disposition to accept!

@lheckemann lheckemann added the status: FCP in Final Comment Period label Mar 22, 2023
@nixos-discourse
Copy link

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
Copy link
Member

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
Copy link

K900 commented Mar 30, 2023

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

RaitoBezarius commented Mar 30, 2023

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
Copy link

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

@RaitoBezarius
Copy link
Member

It is more complicated than JSON schemas enable to express.

@edolstra
Copy link
Member

edolstra commented Mar 31, 2023

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
Copy link

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

RaitoBezarius added a commit to RaitoBezarius/nixos-rfcs that referenced this pull request Nov 1, 2023
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.
@RaitoBezarius RaitoBezarius mentioned this pull request Nov 1, 2023
5 tasks
RaitoBezarius added a commit to RaitoBezarius/nixos-rfcs that referenced this pull request Nov 15, 2023
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.
RaitoBezarius added a commit to RaitoBezarius/nixos-rfcs that referenced this pull request Dec 9, 2023
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.
RaitoBezarius added a commit to RaitoBezarius/nixos-rfcs that referenced this pull request Dec 16, 2023
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.
KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
…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 <[email protected]>
Co-authored-by: Linus Heckemann <[email protected]>

* 0125-bootspec: add the shepherd team and leader

Co-authored-by: Kevin Cox <[email protected]>

* 0125-bootspec: initrd is optional, add system, extensions, clarify the meaning of optional

* PR: address comments (1)

Co-authored-by: Cole Helbling <[email protected]>

* PR: address comments (2)

Co-authored-by: Cole Helbling <[email protected]>

* Update RFC text with changes agreed on with RaitoBezarius

---------

Co-authored-by: Cole Helbling <[email protected]>
Co-authored-by: Cole Helbling <[email protected]>
Co-authored-by: Linus Heckemann <[email protected]>
Co-authored-by: Kevin Cox <[email protected]>
Co-authored-by: Raito Bezarius <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.