GNU bug report logs - #47442
guix system delete-generations does not use bootloader configuration

Previous Next

To reply to this bug, email your comments to 47442 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: guix system delete-generations does not use bootloader configuration
Date: Sun, 28 Mar 2021 04:42:17 +0000

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.html for similar idea.  Would this be an acceptable solution?


Thanks
raid5atemyhomework

Message #8 received at 47442 <at> debbugs.gnu.org (full text, mbox):

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: "47442 <at> debbugs.gnu.org" <47442 <at> debbugs.gnu.org>
Subject: guix system delete-generations does not use bootloader configuration
Date: Mon, 29 Mar 2021 02:01:24 +0000

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.

* `depthcharge` - No configuration.
* `extlinux` - Only `timeout` configuration.
* `u-boot` - Based on `extlinux` (so only `timeout` 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:

* `gnu/machine/ssh.scm` - This is given a `bootloader-configuration` from the actual OS on the machine, so probably OK to use this legacy interface.
* `gnu/system.scm` - Like the above, given a `bootloader-configuration` from the actual OS on the machine.
* `gnu/scripts/system.scm` - This is the problem point identified before.


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

Message #11 received at 47442 <at> debbugs.gnu.org (full text, mbox):

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: "47442 <at> debbugs.gnu.org" <47442 <at> debbugs.gnu.org>
Subject: Re: guix system delete-generations does not use bootloader
 configuration
Date: Fri, 23 Jul 2021 15:32:12 +0000

Bump.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.