bug#36876: guix system delete-generations removes custom boot menu entries

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Jesse Gibbons <jgibbons2357@gmail.com> writes:
>
>> I dual-booted Guix with another gnu/linux-libre distro.
>> My configuration includes the other distro in the grub menu. When I run
>> "sudo guix system delete-generations" the changes to the grub menu drop
>> the other distro with the older system generations of guix.
>>
>> My current work-around for this is to run "guix system reconfigure ..."
>> which includes the boot menu entries specified in the configuration.
>
> Thanks for reporting this; it's a rather serious issue. The problem lies
> in the 'reinstall-bootloader' procedure. Chiefly, it uses the default
> bootloader configuration for whatever it can find using
> 'lookup-bootloader-by-name' and generates menu entries for the
> generations reachable from '%system-profile', which is quite a bit
> different from how 'guix system reconfigure' produces the bootloader
> configuration. It really isn't ideal. To quote a comment in
> 'system.scm': "[i]t will be enough to allow the system to boot."
>
> I don't think this should be _too_ hard to fix. To me, parsing the
> installed Grub configuration to get existing menu entries seems like a
> logical step forward.

I agree with Danny here that parsing the GRUB config wouldn’t be great.

We have information about the user’s extra menu entries.  The issue, as
I see it, as that this information is lost once the system is
instantiated.

But!  We have the <boot-parameters> structure, that gets serialized with
the system, and which we could extend with those extra menu entries.
That way, the info would be preserved, and we can restore them upon
‘delete-generations’.  <menu-entry> records are bootloader-independent,
which is good.

How does that sound?

Thanks,
Ludo’.