[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36876: guix system delete-generations removes custom boot menu entri
bug#36876: guix system delete-generations removes custom boot menu entries
Fri, 23 Aug 2019 14:28:59 +0200
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
address@hidden (Jakob L. Kreuze) skribis:
> Jesse Gibbons <address@hidden> 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
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?