guix system delete-generations does not use bootloader configuration

Hello,

I use a coreboot that does not have a VGA option rom, which means Grub can't use `gfxterm`, so I have this setting in my `operating-system`:

(bootloader-configuration

; ...

(terminal-outputs '(console)))

This lets me see a boot menu at startup even without the VGA option rom.

However, recently when I did a `guix system delete-generations` to remove some old configurations, I saw to my dismay that the `/boot/grub/grub.cfg` got reverted to `terminal_output gfxterm`.

Creating a pointless whitespace change to a daemon configuration file and `guix system reconfigure` got this fixed. This workaround is undesirable since it makes deleting old generations a multi-step, non-atomic process.

The expected behavior is that whatever settings were used in my latest `bootloader-configuration` should not be touched by `guix system delete-generations`.

The actual behavior is `guix system delete-generations` uses the default configuration.

Looking at the code, it seems to be an issue with `guix/scripts/system.scm`'s `reinstall-bootloader` function:

```scheme

;; Use the detected bootloader with default configuration.

;; It will be enough to allow the system to boot.

(bootloader-config (bootloader-configuration

(bootloader bootloader)))

```

While "it will be enough to allow the system to boot", it is not enough for me, on my specific system, to get a convenient boot menu where I can, you know, select older systems (absolutely vital due to the brittleness of Shepherd). On my system, using `terminal_output gfxterm` leads to an "invisible" boot menu, making Guix's vaunted ability to have multiple bootable systems fairly useless --- I can't be sure what system I end up booting into since I can't see the boot menu. I think on other systems as well that need other terminal outputs (such as some sort of `serial`) this will be a problem as well.

A possible solution would be to check if the current system has a `provenance`, and if so, to read in the file and look for the `configuration` field. Then read *that* file and extract its `bootloader` field, and to only fall back to a default configuration if that attempt fails. See https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00294.htmlfor similar idea. Would this be an acceptable solution?

Thanks

raid5atemyhomework

Note as well that keyboard layouts at Grub time are also broken by this. As the keyboard layout is used when accepting passphrases for cryptodisks, this can leave a user potentially unable to boot at all without expert GRUB knowledge, if they selected a passphrase including characters not available on default US keyboard.

An alternative solution is to split the `grub.cfg` file into two pieces: one containing the bootloader configuration settings, the other containing the entries. Then `reinstall-bootloader` just changes the entries.

On alternative bootloaders, there is usually little to no configuration.

So a possible design would be to have a "split" generation of the configuration file.

This affects how `bootloader-configuration-file-generator` is used, however. This affects three points:

Yet another solution would be to augment `boot-parameters` with the fields of `bootloader-configuration`, but that violates DRY --- fields added to `bootloader-configuration` in the future need to be added to `boot-parameters` as well, so I think this is undesirable.

Thanks

raid5atemyhomework

Bump.