Hello! zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:
> Jesse Gibbons <jgibbons2...@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’.
