GNU bug report logs - #36876
guix system delete-generations removes custom boot menu entries

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36876 in the body.
You can then email your comments to 36876 AT debbugs.gnu.org in the normal way.

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

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

From: Jesse Gibbons <jgibbons2357 <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: guix system delete-generations removes custom boot menu entries
Date: Wed, 31 Jul 2019 09:48:57 -0600

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.

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

From: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
To: Jesse Gibbons <jgibbons2357 <at> gmail.com>
Cc: 36876 <at> debbugs.gnu.org
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Mon, 05 Aug 2019 12:05:57 -0400

[Message part 1 (text/plain, inline)]

Hi Jesse,

Jesse Gibbons <jgibbons2357 <at> 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.

Thoughts from anyone else?

Regards,
Jakob

[signature.asc (application/pgp-signature, inline)]

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

From: Jesse Gibbons <jgibbons2357 <at> gmail.com>
To: "Jakob L. Kreuze" <zerodaysfordays <at> sdf.lonestar.org>
Cc: 36876 <at> debbugs.gnu.org
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Mon, 05 Aug 2019 21:12:42 -0600

On Mon, 2019-08-05 at 12:05 -0400, Jakob L. Kreuze wrote:
> ...
> 
> 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.
> 
> Thoughts from anyone else?
> 
> Regards,
> Jakob

Alternatively, we could save in the store a derivation for the the grub
config generated from the bootloader of the configuration. When the
user calls "guix system delete-generations", the derivation can be run,
and the remaining system generations (if any) can be appended in a menu
like when the user calls "guix system reconfigure". (Although it does
not work for me right now, I'm assuming "guix system delete-generations 
2m" as described in the manual will be implemented in the future.)

The immediate downsides I see to my solution:

- It would take space in the store per generation, which can add up if
the user does not often call "guix system delete-generations" and calls
"guix system reconfigure" on a healthy basis. The user could just be
reminded to call "guix system delete-generations" occasionally, and any
 official service that automatically updates the system via "guix
system reconfigure" can (and considering how large a generation with a
lot of updated system packages can get, probably should) also be
configured to call "guix system delete-generations".

- If someone hand-edits the grub config the changes would be lost. This
is the case as it is right now, and grub options can be edited in the
configuration, so I'm not too concerned about this.

-It would be much simpler to identify menu entries generated by guix
that are no longer in the store and remove them, and remove all empty
submenus. Parsing would make hand-editing grub.cfg more dangerous than
a solution that simply scraps the hand-made changes and rebuilds as I
propose, because the user doing the hand-editing would not necessarily
be aware what patterns the parser checks. It would also be inconsitent:
edits to grub.cfg being scrapped when "guix system reconfigure" is
called, but not when 'guix system delete-generations" is called looks
to me like a good way to introduce a bug to the more adventurous
"Murphy's Law"-type users down the road.


These are just my thoughts. I would love to hear other downsides to my
solution.

-- 
-Jesse

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

From: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
To: Jesse Gibbons <jgibbons2357 <at> gmail.com>
Cc: 36876 <at> debbugs.gnu.org
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Tue, 06 Aug 2019 09:22:59 -0400

[Message part 1 (text/plain, inline)]

Jesse Gibbons <jgibbons2357 <at> gmail.com> writes:

> Alternatively, we could save in the store a derivation for the the grub
> config generated from the bootloader of the configuration. When the
> user calls "guix system delete-generations", the derivation can be run,
> and the remaining system generations (if any) can be appended in a menu
> like when the user calls "guix system reconfigure". (Although it does
> not work for me right now, I'm assuming "guix system delete-generations 
> 2m" as described in the manual will be implemented in the future.)
>
> The immediate downsides I see to my solution:
>
> - It would take space in the store per generation, which can add up if
> the user does not often call "guix system delete-generations" and calls
> "guix system reconfigure" on a healthy basis. The user could just be
> reminded to call "guix system delete-generations" occasionally, and any
>  official service that automatically updates the system via "guix
> system reconfigure" can (and considering how large a generation with a
> lot of updated system packages can get, probably should) also be
> configured to call "guix system delete-generations".
>
> - If someone hand-edits the grub config the changes would be lost. This
> is the case as it is right now, and grub options can be edited in the
> configuration, so I'm not too concerned about this.
>
> -It would be much simpler to identify menu entries generated by guix
> that are no longer in the store and remove them, and remove all empty
> submenus. Parsing would make hand-editing grub.cfg more dangerous than
> a solution that simply scraps the hand-made changes and rebuilds as I
> propose, because the user doing the hand-editing would not necessarily
> be aware what patterns the parser checks. It would also be
> inconsitent: edits to grub.cfg being scrapped when "guix system
> reconfigure" is called, but not when 'guix system delete-generations"
> is called looks to me like a good way to introduce a bug to the more
> adventurous "Murphy's Law"-type users down the road.

I haven't tried it yet, but 'menuentry' seems as though it would be a
fairly simple structure to parse.

> These are just my thoughts. I would love to hear other downsides to my
> solution.

I prefer your suggestion to mine and think that the benefits may
outweigh the costs in this case. This seems to fit into the Guix idea of
purity a bit better than parsing a grub.cfg that may have been
overwritten by another system.

Regards,
Jakob

[signature.asc (application/pgp-signature, inline)]

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Tue, 6 Aug 2019 18:32:34 +0200

[Message part 1 (text/plain, inline)]

Hi Jakob,

keep in mind that switching back to a previous generation could also entail a
switch of bootloader projects.  It does you no good to parse the grub config to
find menu entries and then append them to u-boot.

Fundamentally, it would be best if either the bootloader is part of the state
that guix manages (and each time uses), or it isn't; not both.

Current situation:

* If you select a previous generation in the boot menu, then the state that is
selected does NOT include the bootloader (i.e. it doesn't change the bootloader
or the bootloader config).

* If you do "guix system reconfigure", the state that is saved includes only
the bootloader in the boot sector (simplified) but not the bootloader installer
or the bootloader derivation.

* If you do "guix system delete-generations", the state that is restored does
not include the bootloader installer and previous bootloader configuration.

Clearly, it's not nice to have these different things happen.

It would be better if we retained the generation's bootloader installer
and bootloader config and reinstalled it on each of those.

So, I would suggest to retain the following for each system generation:

* The bootloader package derivation
* The bootloader config derivation
* The bootloader installer derivation

And to install the bootloader each time using the latter.

This introduces cycles--not sure whether that's a problem or not.
For the GC I think it's not a problem.

[Message part 2 (application/pgp-signature, inline)]

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Tue, 6 Aug 2019 18:35:58 +0200

[Message part 1 (text/plain, inline)]

Addition:

* If you do "guix system switch-generation", the state that is restored does
not include the bootloader installer and previous bootloader configuration.

[Message part 2 (application/pgp-signature, inline)]

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

From: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Tue, 06 Aug 2019 14:27:47 -0400

[Message part 1 (text/plain, inline)]

Hi Danny,

Danny Milosavljevic <dannym <at> scratchpost.org> writes:

> Hi Jakob,
>
> keep in mind that switching back to a previous generation could also entail a
> switch of bootloader projects.  It does you no good to parse the grub config to
> find menu entries and then append them to u-boot.
>
> Fundamentally, it would be best if either the bootloader is part of the state
> that guix manages (and each time uses), or it isn't; not both.
>
> Current situation:
>
> * If you select a previous generation in the boot menu, then the state that is
> selected does NOT include the bootloader (i.e. it doesn't change the bootloader
> or the bootloader config).
>
> * If you do "guix system reconfigure", the state that is saved includes only
> the bootloader in the boot sector (simplified) but not the bootloader installer
> or the bootloader derivation.
>
> * If you do "guix system delete-generations", the state that is restored does
> not include the bootloader installer and previous bootloader configuration.
>
> Clearly, it's not nice to have these different things happen.
>
> It would be better if we retained the generation's bootloader installer
> and bootloader config and reinstalled it on each of those.
>
> So, I would suggest to retain the following for each system generation:
>
> * The bootloader package derivation
> * The bootloader config derivation
> * The bootloader installer derivation
>
> And to install the bootloader each time using the latter.
>
> This introduces cycles--not sure whether that's a problem or not.
> For the GC I think it's not a problem.

Thank you for your comments -- after reading this and Jesse's
suggestion, I'm quite confident that this is the way to go about it.

Regards,
Jakob

[signature.asc (application/pgp-signature, inline)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Fri, 23 Aug 2019 14:28:59 +0200

Hello!

zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Jesse Gibbons <jgibbons2357 <at> 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’.

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

From: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Wed, 28 Aug 2019 11:38:45 -0400

[Message part 1 (text/plain, inline)]

Hi Ludo,

Ludovic Courtès <ludo <at> gnu.org> writes:

> 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?

Would that involve appending an additional field to <boot-parameters>
for storing the previous entries? I think that would have the pleasant
side-effect of making the code for deployment/reconfiguration simpler :)

Regards,
Jakob

[signature.asc (application/pgp-signature, inline)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Wed, 28 Aug 2019 23:39:55 +0200

[Message part 1 (text/plain, inline)]

Hello,

zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> 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?
>
> Would that involve appending an additional field to <boot-parameters>
> for storing the previous entries? I think that would have the pleasant
> side-effect of making the code for deployment/reconfiguration simpler :)

Oh that’d be nice.

The attached patches should fix this.  I’ve successfully deleted a
generation on my system. :-)  I don’t have extra menu entries though, so
it’d be great if you could give it a try.

Thanks,
Ludo’.

[0001-system-Add-bootloader-menu-entries-field-to-boot-par.patch (text/x-patch, attachment)]

[0002-guix-system-Reinstalling-the-bootloader-preserves-ex.patch (text/x-patch, attachment)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36876 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>,
 Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Thu, 29 Aug 2019 10:02:49 +0200

Hi there!

Ludovic Courtès <ludo <at> gnu.org> skribis:

> The attached patches should fix this.  I’ve successfully deleted a
> generation on my system. :-)  I don’t have extra menu entries though, so
> it’d be great if you could give it a try.

So I tried it on my laptop: I added a dummy menu entry, reconfigured,
rebooted, then ran “guix system delete-generations N”, and I confirm
that it preserves the extra menu entry.

There was a typo though:

> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -116,6 +116,7 @@
>              boot-parameters-label
>              boot-parameters-root-device
>              boot-parameters-bootloader-name
> +            boot-parameters-bootloader-menu-entries
>              boot-parameters-store-device
>              boot-parameters-store-mount-point
>              boot-parameters-kernel
> @@ -251,6 +252,8 @@ directly by the user."
>    ;; OS's root file system, so it might be a device path like "/dev/sda3".
>    (root-device      boot-parameters-root-device)
>    (bootloader-name  boot-parameters-bootloader-name)
> +  (bootloader-menu-entries                        ;list of <menu-entry>
> +   boot-parameters-bootloader-menu-entries)
>    (store-device     boot-parameters-store-device)
>    (store-mount-point boot-parameters-store-mount-point)
>    (kernel           boot-parameters-kernel)
> @@ -297,6 +300,11 @@ file system labels."
>           ((_ args) args)
>           (#f       'grub))) ; for compatibility reasons.
>  
> +      (bootloader-menu-entries
> +       (match (assq 'bootloader-menu-entries rest)
> +         ((_ . entries) (map sexp->menu-entry entries))
                ^
There shouldn’t be a dot here.

I’ll go ahead and push these patches (with this correction) if there are
no objections.

Thanks,
Ludo’.

Message #42 received at 36876-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 36876-done <at> debbugs.gnu.org,
 Jesse Gibbons <jgibbons2357 <at> gmail.com>
Subject: Re: bug#36876: guix system delete-generations removes custom boot
 menu entries
Date: Fri, 30 Aug 2019 01:35:21 +0200

Pushed as c3e59de9b1340f1a0ef7e30dd2e4e7bf7b484ee9.

Let me know if anything’s still not quite as expected!

Ludo’.

Previous Next

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