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

[pluiedev]

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:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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.

[pluiedev]

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

[pluiedev]

Ready for review

[nyabinary]

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

[Scrumplex]

@ofborg test grub grub-ng

[nixos-discourse]

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]

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

[ThinkChaos]

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 :)

[ThinkChaos]

Any parent dirs will have unexpected permissions here.

[pluiedev]

Can you elaborate?

[ThinkChaos]

If create_dir_all creates any parent directories, they won't use the permission we set just below.

I'm not sure what's the best thing to do here.

[symphorien]

(I didn't read the PR but the os prober test passes, great!)

[xddxdd]

I tested this and the grub.cfg generated contains errors that would prevent boot. The kernel/initrd references ($drive1)/kernels/name instead of the actual path to kernel/initrd.

Example entry from this PR:

menuentry "NixOS - Configuration 730 (2024-11-25 - 25.05pre-git)" --class nixos {
  savedefault
search --set=drive1 --fs-uuid 5573-574D
  linux ($drive1)/kernels/name init=/nix/store/myp185i80v1ibjicj33bv1jqm8vwzk98-nixos-system-lt-hp-omen-25.05pre-git/init [args...]
  initrd ($drive1)/kernels/name 
}

Example entry from old script:

menuentry "NixOS - Configuration 730 (2024-11-24 - 25.05pre-git)" --class nixos {
  savedefault
search --set=drive1 --fs-uuid 5573-574D
  linux ($drive1)//kernels/i52qc8wmsbldpzh5sqy3591c9lzwa6pz-linux-cachyos-latest-6.12.1-bzImage init=/nix/store/myp185i80v1ibjicj33bv1jqm8vwzk98-nixos-system-lt-hp-omen-25.05pre-git/init [args...]
  initrd ($drive1)//kernels/hh0dadclbbfnbrd3xhc1nbdy8ppskrfz-initrd-linux-cachyos-latest-6.12.1-initrd
}

I have an impermanence setup. This is my partition setup for reference:

Device           Start        End    Sectors  Size Type
/dev/nvme2n1p1    2048    1050623    1048576  512M EFI System - /boot partition, FAT32
/dev/nvme2n1p2 1050624 7814037134 7812986511  3.6T Linux filesystem - /nix partition, Btrfs

[pluiedev]

Might have missed a variable reference there when porting? (Note to self: never touch Perl ever again)

[rnhmjoj]

So, you could say I'm one of the maintainers of grub: I use it on both EFI and non-EFI systems and I wrote the NixOS tests.
I'll try to test this when I have some spare time.

As a first impression: can we try to keep it simpler?
This implementation is almost 2000 lines split over 7 files: it looks quite impenetrable to me.
Compared, install-grub.pl is just 800 lines of linear imperative code: I understand it well enough even without knowing perl.
Say, recently I was extending the script to generate boot loader entries, here I wouldn't even know to where start.

[pluiedev]

Most of the complexity is simply handling the error cases that the Perl code just skips over — more rigorous input parsing, more rigorous subprocess spawning, etc. Rust is in general a much more explicit language than Perl (which is infamous for being so terse that it's impenetrable).

As to where to add the extra bootloader entries, it's aptly under src/builder/entries.rs :p

[nyabinary]

What's necessary for this to move forward?

[pluiedev]

Mostly to fix some bugs with the code output (see comments above). I'm a bit burnt out from Nix work at the moment but I'll come back to this in due time

[Shados]

At least the root, mount point, and device fields in /proc/$PID/mountinfo are POSIX paths, meaning they are strings of bytes that do not contain a null byte. Given that the format of/proc/$PID/mountinfo relies on space-separated fields in line-separated records, it escapes several items in path-type fields by replacing them with a \ followed by three octal digits encoding the byte (e.g. a UTF-8 newline is replaced by \012). You'll need to decode these escapes before using the resulting OsString to construct a Path object, if you want to be robust against weird paths. install-grub.pl doesn't do this, but it's buggy overall.

Possibly some of the other fields have this kind of escaping also, not sure.

[pluiedev]

Do they always use octal escapes and never other escape formats (e.g. hexadecimal escapes)?

[Shados]

Took a look at the kernel code generating the mountinfo pseudo-files, and yep. It is also only those three fields which get this escaping/mangling, too, looks like.

[Shados]

Given you're using eyre¹ and returning its Result type already, you can avoid these rather verbose Option matches and replace them with this arguably more readable construct, converting the Option to a Result with error context and opening it with the try operator:

let ext = splash_image.extension().ok_or_eyre("Splash image has no extension - could not decide which module to load!")?;

1: Also, what's the motivation for using eyre instead of just anyhow?

[pluiedev]

I preferred eyre when I first wrote this, but I've since switched to anyhow — haven't gotten to porting this over yet.

[Shados]

I believe it should be checking mount_options rather than super_options here, as the latter is always going to contain rw, for both the bind mount and non-bind mount, at least on the systems I've checked.

That would also explain why mount_options appears to be unused in the Perl version: they accidentally used the wrong variable here. Although I guess that never mattered enough to cause a bug in practice, or at least not one that anyone tracked down...

[pluiedev]

Ah, that makes so much sense actually. I was confused by this as well xD