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

nixos/grub: add new implementation of install-grub.pl #317026

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

pluiedev
Copy link
Contributor

@pluiedev pluiedev commented Jun 3, 2024

Description of changes

Following in the footsteps of Perlless Activation (#270727) and Perlless switch-to-configuration (#308801), it's now time for Perlless install-grub, which can be enabled by simply setting boot.loader.grub.useInstallNg to true.

This is still a draft PR for now since I don't use GRUB myself, and I could do with some help from GRUB users who could actually test this :) The GRUB config generation logic seems to work pretty well, though.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Jun 3, 2024
@pluiedev pluiedev force-pushed the init/install-grub-ng branch 5 times, most recently from 6327db4 to eff29a0 Compare June 3, 2024 21:53
@ofborg ofborg bot added 8.has: package (new) This PR adds a new package 11.by: package-maintainer This PR was created by the maintainer of the package it changes 10.rebuild-darwin: 1-10 10.rebuild-darwin: 1 10.rebuild-linux: 1-10 labels Jun 4, 2024
@pluiedev
Copy link
Contributor Author

pluiedev commented Jun 4, 2024

Found a couple of (serious) bugs, fortunately there's a test I can use to catch them... :D

@pluiedev pluiedev force-pushed the init/install-grub-ng branch 2 times, most recently from 339c8db to f8e1766 Compare June 6, 2024 19:48
@pluiedev
Copy link
Contributor Author

pluiedev commented Jun 6, 2024

Ready for review

@pluiedev pluiedev marked this pull request as ready for review June 6, 2024 19:58
@pluiedev pluiedev requested a review from dasJ as a code owner June 6, 2024 19:58
@nyabinary
Copy link
Contributor

Should probably post this in the discourse thread of prs ready to review :P

@Scrumplex
Copy link
Member

@ofborg test grub grub-ng

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/prs-ready-for-review/3032/4819

@KiaraGrouwstra
Copy link
Contributor

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 317026


x86_64-linux

⏩ 2 packages blacklisted:
  • nixos-install-tools
  • tests.nixos-functions.nixos-test
✅ 1 package built:
  • install-grub-ng

Copy link
Contributor

@ThinkChaos ThinkChaos left a comment

Choose a reason for hiding this comment

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

Thank you for working on this!
It's what's blocking me from going perl-less. I'll give it a try when I have time, though my setup is not likely to trigger many edge cases.

Generally it seems like we should use eyre a lot more: most code just uses ? without adding any context. That'll lead to errors users can't understand 🙁
IMO, it's fine for a prototype to do that, but the best time for error handling is when you write the code, and the second best is when there's a full review. Otherwise you end up having to go over every thing again and it's very easy to miss some places.

I haven't done a full review but already spent enough time one this now. Here's the comments I wrote for now.
Don't hesitate to tell me I'm wrong or whatever in the comments :)

Comment on lines +9 to +11
rustPlatform.buildRustPackage {
pname = "install-grub";
version = "0.1.0";
Copy link
Contributor

Choose a reason for hiding this comment

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

I generally like to do this without duplicating the info:

Suggested change
rustPlatform.buildRustPackage {
pname = "install-grub";
version = "0.1.0";
let
inherit (lib.importTOML ./Cargo.toml) package;
in
rustPlatform.buildRustPackage {
pname = package.name;
inherit (package) version;


use std::{
collections::HashSet,
fmt::Write as _,
Copy link
Contributor

Choose a reason for hiding this comment

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

style nit: Is this really needed? I think just using the trait without naming it is enough to not trigger linter errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is required for write(ln)! unfortunately as otherwise it introduces a name conflict with std::io::Write

}
}

let usernames = self.config.users.0.keys().copied().collect::<Vec<_>>();
Copy link
Contributor

Choose a reason for hiding this comment

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

style nit: IMO Turbofish is best left alone in its natural habitat (this seems more common as a pattern to me):

Suggested change
let usernames = self.config.users.0.keys().copied().collect::<Vec<_>>();
let usernames: Vec<_> = self.config.users.0.keys().copied().collect();

}

if let Some(store) = &self.grub_store {
writeln!(&mut self.inner, r"{}", store.search)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

style nit:

Suggested change
writeln!(&mut self.inner, r"{}", store.search)?;
writeln!(&mut self.inner, "{}", store.search)?;

Comment on lines +133 to +138
function savedefault {{
if [ -z "${{boot_once}}"]; then
saved_entry="${{chosen}}"
save_env saved_entry
fi
}}
Copy link
Contributor

Choose a reason for hiding this comment

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

style nit:

Suggested change
function savedefault {{
if [ -z "${{boot_once}}"]; then
saved_entry="${{chosen}}"
save_env saved_entry
fi
}}
function savedefault {{
if [ -z "${{boot_once}}"]; then
saved_entry="${{chosen}}"
save_env saved_entry
fi
}}

Copy link
Contributor

Choose a reason for hiding this comment

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

Having a builder.rs file and builder/ dir seems weird. Maybe move this to builder/mod.rs?

Copy link
Contributor Author

@pluiedev pluiedev Dec 3, 2024

Choose a reason for hiding this comment

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

I prefer new-style (mod.rs-less) module trees

See https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html

Comment on lines +39 to +40
fs::create_dir_all(&grub)?;
fs::set_permissions(&grub, fs::Permissions::from_mode(0o700))?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Any parent dirs will have unexpected permissions here.

grub_store: Option<Grub>,

default_config: &'conf Path,
pub copied: HashSet<PathBuf>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Might've missed something, but I don't think this needs to be pub.

default_config: &'conf Path,
pub copied: HashSet<PathBuf>,

dry_run: bool,
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems error prone to have !dry_run every where. Could be nice to have a wrapper for each fs function we use that checks the flag automatically.
A TODO is fine by me if you like the idea:

Suggested change
dry_run: bool,
// TODO: create wrappers for fs functions we use that check `$DRY_RUN` automatically
dry_run: bool,

.append_initrd_secrets(name, path, current)?
.unwrap_or_default();

// FIXME: $confName
Copy link
Contributor

Choose a reason for hiding this comment

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

What does this mean? Maybe put more details in the comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is from the original script, and I have no idea what it means either

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 1-10 10.rebuild-darwin: 1 10.rebuild-linux: 1-10 11.by: package-maintainer This PR was created by the maintainer of the package it changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants