Hi Danny! > Am 24.05.2020 um 13:00 schrieb Danny Milosavljevic : > >> 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) OK, I understand. I will take a look at it. > 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. Hm, if I select an older system generation in GRUB, than that older one is booted. But this doesn't change the bootloader. If I then delete some system generations – as I’ve seen so far, but I might be wrong – the bootloader is not reinstalled either. Only the grub.cfg is regenerated to remove the deleted generations. If I reboot, then I'm still using the latest generation GRUB, but boot some older system generation, which would not be able by itself to install this very recent GRUB in use. If I then reconfigure the system, only then another GRUB - or even a different bootloader, depending on my etc/config.scm – will be installed and the according configuration file will be generated as well. Then again all will fit. In the worst case the (bootloader (bootloader-configuration …) …) in my etc/config.scm is still newer than this older guix system in use is able to handle. Oh, by the way, does booting an older system generation also change the guix version in use from the latest 'guix pull'? I don't think it does. And does booting an older generation change the config.scm? I don’t think so either. Actually, I don’t really understand what you mean. Are there circumstances beside a 'guix system reconfigure' in which the bootloader gets reinstalled? And with reinstall I don’t mean to only regenerate the grub.cfg, but calling /sbin/grub-install. Isn’t the actual problem for an older running system generation to know which bootloder is currently in use? I think this can't be inferred by the currently running system generation. It may happen, that you use a brand new bootloader which is not known by the older system generation you just switched to. But still then, if you invoke a 'sudo -E guix system delete-generations' or a 'sudo -E guix system reconfigure' I think you still use the very latest guix version that you 'guix pull'-ed last. And that guix version should still know all brand new bootloader. The problem may “only” be to know for 'sudo -E guix system delete-generations' which one to use. But actually the bootloader-name field in /var/guix/profiles/system/parameters can't tell either, as it must be an older bootloader than the brand new one. Maybe the information about the bootloader version in use needs to reside with the installed bootloader somewhere below /boot/efi/…? But this may be impossible for the legacy grub-bootloader. >> 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. I think after switching to an older system generation this is not true, as explained above. Am I wrong about this? > 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. I see. > 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. As I wrote a bit below: I think there is a second possibility. It may be possible to create a symlink from /boot-nfs/efi/boot/grub.cfg to ../../../boot/grub.cfg. Then the assumption that there will always be a /boot/grub.cfg file stays valid. But Im still unsure about this. Bye Stefan