Can't or shouldn't we re-use the same generator for all BLS entries generation, rather than maybe accidentally having diverging implementations?

Uhm, I'm not sure: it certainly make sense but the systemd-boot generator is in python. Using it would make the bootloader script depends on a shell, perl and python interpreter, which is not great. If install-grub.pl were to be rewritten in python, it would be trivial, but I don't have enough familiarity with either perl or grub to do that.

It would make the bootloader script depend on python, but isn't NixOS' base closure already bringing in the same python? I guess that would be the question to answer.

Because, sure it would increase this specific NixOS module's closure size, but re-implementing the code increases the code complexity.

That is my main concern with the PR, but I guess it could be fine to go with the duplicated code for the time being, as long as others don't feel strongly against that.

After reading #48378, if nothing changed in the mean time, python should not be in the minimal closure unless using systemd-boot (due to the python generator).
Also I think people are slowly trying to replace perl in the core tools / closure, but its not there yet.

I also have some incoming changes to systemd-boot-builder.py to support "boot counters" here: #84204
This involves keeping track of the boot counter state associated with each entry, which are optional counters included in the filename after a + symbol: e.g. nixos-generation-200+2-1.conf.

Having the loader entry generation in two different languages would make changes like this much more difficult. I wonder if the aversion to python in the minimal closure has changed at all since the apparently successful refactor to enable mypy type checking in nixops.

I believe the closure concerns are entirely about size.

So, It doesn't look like there is a consensus on whether perl, python or neither should be used instead.

I agree it's not ideal to have the booloader code written in two different languages, but I wouldn't stall changes on this because I don't think the conflict will be resolved anytime soon. Morover both systemd-boot-builder.py and install-grub.pl are complex and rewriting or unifying them is already a huge task.

So, It doesn't look like there is a consensus on whether perl, python or neither should be used instead.

I agree it's not ideal to have the booloader code written in two different languages, but I wouldn't stall changes on this because I don't think the conflict will be resolved anytime soon. Morover both systemd-boot-builder.py and install-grub.pl are complex and rewriting or unifying them is already a huge task.

I agree.
I am currently learning rust by trying to rewrite setup-etc and update-users-groups and eventually switch-to-configuration in rust (here if you want to take a look at the current state). If the community decides that it's a good road to follow, I will have a look at these boot loader generators as well. But that's for a another day..

I am currently learning rust by trying to rewrite setup-etc and update-users-groups and eventually switch-to-configuration in rust

Using a compiled language with static typing sounds like a good idea: the scripts are quite complex and a proper compiler could help. It would also remove the interpreter from the closure.

If install-grub.pl were to be rewritten in python

That would be amazing. The bootloader script has the potential to brick everyone's system, yet with the Perl stuff it is extremely easy to make mistakes in there.

In the PR I contributed to install-grub.pl recently, I spent multiple hours testing and consulted somebody who actually knew some Perl to get it right, and I still broke something and had to make a followup PR.

Similarly, I don't feel equipped to review this PR.

As a desktop user, and owner of important server infrastructure that needs to boot reliably, I'd accept a slightly larger system any day if in turn that Perl script dissapears from my "stuff that has a high potential to screw us" risk list.

If consensus can be reached for install-grub.pl to be rewritten in Python, I'm happy to spend some hours to implement it (I think I know quite well what that script does, I just can't modify it with confidence in Perl), or to sponsor e.g. 300 EUR to help fund the move.

Using a compiled language with static typing sounds like a good idea: the scripts are quite complex and a proper compiler could help.

👍 For Python, optional static typing support (mypy) is good in nixpkgs, and that could be used e.g. in a NixOS test that doesn't increase the closure vs plain Python (we use mypy for Python scripts at work).

That is not to discourage the Rust approaches (good stuff!), but if I Python is something that can be agreed on easily, I'd that immediately vs waiting for e.g. another year for a potential Rust solution to be ready (we can still switch to something better afterwards).

I'm not familiar with rust, but I could help with python too.

It's important to reach a consensus on the language before, though: without it all the efforts could go to waste.
What do you think of making an RFC? For example, this has been done for choosing the new Nixpkgs/NixOS docs format.

I'm not familiar with rust, but I could help with python too.

It's important to reach a consensus on the language before, though: without it all the efforts could go to waste.
What do you think of making an RFC? For example, this has been done for choosing the new Nixpkgs/NixOS docs format.

Well for compiled languages we do not have to restrict ourselves that much, but it would indeed be a good idea to agree on a canonical interpreted language while / if we have critical interpreted code present at runtime.

I marked this as stale due to inactivity. → More info

The GRUB BLS module (blscfg.mod) does not support ZFS. Source 1 (search in page for blscfg); therefore we must disable BLS if ZFS support is enabled.

@ne9z This PR has nothing to do with grub support for BLS. It's about adding some code to generate the BLS entries when switching to a new NixOS generation.