all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jesse Gibbons <jgibbons2357@gmail.com>
To: "Jakob L. Kreuze" <zerodaysfordays@sdf.lonestar.org>
Cc: 36876@debbugs.gnu.org
Subject: bug#36876: guix system delete-generations removes custom boot menu entries
Date: Mon, 05 Aug 2019 21:12:42 -0600	[thread overview]
Message-ID: <e5d7a9a83b44c739794a597411ae3ee090bac61d.camel@gmail.com> (raw)
In-Reply-To: <8736ifzjfe.fsf@sdf.lonestar.org>

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

  reply	other threads:[~2019-08-06  3:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 15:48 bug#36876: guix system delete-generations removes custom boot menu entries Jesse Gibbons
2019-08-05 16:05 ` Jakob L. Kreuze
2019-08-06  3:12   ` Jesse Gibbons [this message]
2019-08-06 13:22     ` Jakob L. Kreuze
2019-08-06 16:32   ` Danny Milosavljevic
2019-08-06 16:35     ` Danny Milosavljevic
2019-08-06 18:27     ` Jakob L. Kreuze
2019-08-23 12:28   ` Ludovic Courtès
2019-08-28 15:38     ` Jakob L. Kreuze
2019-08-28 21:39       ` Ludovic Courtès
2019-08-29  8:02         ` Ludovic Courtès
2019-08-29 23:35           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5d7a9a83b44c739794a597411ae3ee090bac61d.camel@gmail.com \
    --to=jgibbons2357@gmail.com \
    --cc=36876@debbugs.gnu.org \
    --cc=zerodaysfordays@sdf.lonestar.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.