Hi Stefan, On Sun, 24 May 2020 12:18:38 +0200 Stefan wrote: > But I’m not sure, if the field bootloader-name can be dropped then[after adding bootloader-configuration-file to boot-parameters] from . But if, then we could probably also drop the field name from the record. We definitely can't drop it. The name is required in order to know which bootloader to restore when deleting system generations. After all you could be deleting the generation that switched from extlinux to grub. How to boot then? (see lookup-bootloader-by-name call site) Since we are trying to have the bootloader to use part of the Guix system configuration (for better or for worse), we have to be really careful to pick the right bootloader and generate the configuration for the right bootloader, otherwise the computer won't boot anymore *and* you couldn't select the before-fuckup generation anymore either. > Yes, it’s kind of possible to inherit from grub-efi-bootloader and overwrite the (configuration-file) field. In a first step this seems to work. But when e.g. deleting a system generation, in guix/scripts/system.scm (reinstall-bootloader) there is this code: > > ;; Use the detected bootloader with default configuration. > ;; It will be enough to allow the system to boot. > (bootloader-config (bootloader-configuration > (bootloader bootloader))) >In it seems – but I’m not sure yet – that we only keep a symbol name to figure out the path to the grub.cfg, although it is possible to just put that path directly there instead. And using the symbol makes it hard do get a configurable bootloader: A new bootloader has to be a variable, tricks with macros come up. Also inheriting from a bootloader and overwriting the configuration-file field – for whatever reason – is problematic: It seems to work at the beginning, but only fails badly when removing a system generation. It seems to have subtle bugs. It’s not usable like other parts in guix. It’s not hackable. I’d really prefer to change this. Yeah, well... that is the only way we could think of to make sure it actually boots in all cases, as it is right now. (Though if the user had custom entries, that would nuke all of them--but that's still better than not being able to boot at all) Using a symbol was to make it clear that this is supposed to be a reference to an actual variable and not some weird mini-programming language inside a string or whatever. It would be better to have some kind of abstract representation of *all* the bootloader things one could want, in Guix in config.scm. That would make Guix system a lot more complicated, though (chainloading bootloaders for one--I saw you working on this, too). Just to be clear, I'm fine with changing boot-parameters, but be very very careful that all old versions of Guix and new versions of Guix can handle all the boot-parameters--at least falling back to something. It's not fun if you can't boot anymore. Source: I modified a lot of that stuff and wasn't able to boot quite often until I finally stopped overcomplicating the boot-parameters. >Actually there is a problem with all this in guix: There is (bootloader (target …)), >which gives the impression that one is able to freely chose a folder for the >bootloader files. However, the path “/boot/grub.cfg” is kind of hard coded. Could you elaborate why having that hard-coded file path is bad? It makes booting a lot more resilient if it's hard-coded as opposed to having basic stuff like that configurable--and being careful all the time it's actually configured correctly for all the parties to it, some of them maybe not even inside Guix.