Reverse order for old grub.cfg entries

Done

Details

6 participants

Clément Lassieur
Joshua Branson
Ludovic Courtès
Mathieu Othacehe
Mark H Weaver
Vagrant Cascadian

Owner: unassigned

Submitted by: Vagrant Cascadian

Severity: normal

Debbugs page

Vagrant Cascadian wrote 7 years ago

Recipients:(address . bug-guix@gnu.org)

Message-ID:87h8odb1fo.fsf@aikidev.net

Hi!

This is a pretty minor issue, but I've found that the "GNU system, old

configurations..." part of the menu would be nicer if the most recent

generations were listed at the top, rather than the oldest generations.

Currently it lists generation 1 as the first entry in the list, and if

I've got 50+ generations installed and I don't want to boot the current

generation, I'm most likely going to want to revert to one of the more

recent generations rather than the very oldest.

live well,

vagrant

Joshua Branson wrote 7 years ago

Recipients:(address . bug-guix@gnu.org)

Message-ID:ygffu3wtmeo.fsf@fastmail.com

That's actually a pretty good idea!

Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (13 lines)> Hi!
>
> This is a pretty minor issue, but I've found that the "GNU system, old
> configurations..." part of the menu would be nicer if the most recent
> generations were listed at the top, rather than the oldest generations.
>
> Currently it lists generation 1 as the first entry in the list, and if
> I've got 50+ generations installed and I don't want to boot the current
> generation, I'm most likely going to want to revert to one of the more
> recent generations rather than the very oldest.
>
> live well,
>   vagrant

Mark H Weaver wrote 7 years ago

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 31159@debbugs.gnu.org)

Message-ID:87y3hnnru3.fsf@netris.org

Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (9 lines)

> This is a pretty minor issue, but I've found that the "GNU system, old

> configurations..." part of the menu would be nicer if the most recent

> generations were listed at the top, rather than the oldest generations.

> Currently it lists generation 1 as the first entry in the list, and if

> I've got 50+ generations installed and I don't want to boot the current

> generation, I'm most likely going to want to revert to one of the more

> recent generations rather than the very oldest.

I agree that it would be better to reverse the order of these entries.

Thanks,

Mark

Mathieu Othacehe wrote 7 years ago

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87a7u2qmd4.fsf@gmail.com

Hi,

This seems like a good idea ! If we decide to make it unconditional the

patch attached does the job. We can also make it configurable in

bootloader-configuration for instance.

WDYT ?

Mathieu

From 3ec63fb55a074b547724c70d560cc61776c9298e Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Tue, 17 Apr 2018 09:23:00 +0200
Subject: [PATCH] scripts: system: Sort profile generations in reverse order.

* guix/scripts/system.scm (profile-boot-parameters): Reverse
generation-numbers list. This allows old generations to be listed from most
recent to oldest in bootloaders configuration files.
---
 guix/scripts/system.scm | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Toggle diff (21 lines)diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index b50cabc..7e1363c 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -393,9 +393,11 @@ it atomically, and then run OS's activation script."
                   "~Y-~m-~d ~H:~M")))
 
 (define* (profile-boot-parameters #:optional (profile %system-profile)
-                                  (numbers (generation-numbers profile)))
-  "Return a list of 'boot-parameters' for the generations of PROFILE specified by
-NUMBERS, which is a list of generation numbers."
+                                  (numbers
+                                   (reverse (generation-numbers profile))))
+  "Return a list of 'boot-parameters' for the generations of PROFILE specified
+by NUMBERS, which is a list of generation numbers. The list is ordered from
+the most recent to the oldest profiles."
   (define (system->boot-parameters system number time)
     (unless-file-not-found
      (let* ((params           (read-boot-parameters-file system))
-- 
2.7.4

Mark H Weaver writes:

Toggle quote (15 lines)> Vagrant Cascadian <vagrant@debian.org> writes:
>
>> This is a pretty minor issue, but I've found that the "GNU system, old
>> configurations..." part of the menu would be nicer if the most recent
>> generations were listed at the top, rather than the oldest generations.
>>
>> Currently it lists generation 1 as the first entry in the list, and if
>> I've got 50+ generations installed and I don't want to boot the current
>> generation, I'm most likely going to want to revert to one of the more
>> recent generations rather than the very oldest.
>
> I agree that it would be better to reverse the order of these entries.
>
>     Thanks,
>       Mark

Mark H Weaver wrote 7 years ago

Recipients:(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)

Message-ID:878t9llmr7.fsf@netris.org

Mathieu Othacehe <m.othacehe@gmail.com> writes:

Toggle quote (6 lines)

> This seems like a good idea ! If we decide to make it unconditional the

> patch attached does the job. We can also make it configurable in

> bootloader-configuration for instance.

> WDYT ?

Thank you, Mathieu! I doubt that there's a need to make this

configurable, but I'd like to hear an opinion from Ludovic, since I

guess he was the one who implemented the current ordering.

What do you think, Ludovic?

Mark

Toggle quote (31 lines)> From 3ec63fb55a074b547724c70d560cc61776c9298e Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Tue, 17 Apr 2018 09:23:00 +0200
> Subject: [PATCH] scripts: system: Sort profile generations in reverse order.
>
> * guix/scripts/system.scm (profile-boot-parameters): Reverse
> generation-numbers list. This allows old generations to be listed from most
> recent to oldest in bootloaders configuration files.
> ---
>  guix/scripts/system.scm | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
> index b50cabc..7e1363c 100644
> --- a/guix/scripts/system.scm
> +++ b/guix/scripts/system.scm
> @@ -393,9 +393,11 @@ it atomically, and then run OS's activation script."
>                    "~Y-~m-~d ~H:~M")))
>  
>  (define* (profile-boot-parameters #:optional (profile %system-profile)
> -                                  (numbers (generation-numbers profile)))
> -  "Return a list of 'boot-parameters' for the generations of PROFILE specified by
> -NUMBERS, which is a list of generation numbers."
> +                                  (numbers
> +                                   (reverse (generation-numbers profile))))
> +  "Return a list of 'boot-parameters' for the generations of PROFILE specified
> +by NUMBERS, which is a list of generation numbers. The list is ordered from
> +the most recent to the oldest profiles."
>    (define (system->boot-parameters system number time)
>      (unless-file-not-found
>       (let* ((params           (read-boot-parameters-file system))

Ludovic Courtès wrote 7 years ago

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87604oy5j7.fsf@gnu.org

Hello,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (14 lines)> Mathieu Othacehe <m.othacehe@gmail.com> writes:
>
>> This seems like a good idea ! If we decide to make it unconditional the
>> patch attached does the job. We can also make it configurable in
>> bootloader-configuration for instance.
>>
>> WDYT ?
>
> Thank you, Mathieu!  I doubt that there's a need to make this
> configurable, but I'd like to hear an opinion from Ludovic, since I
> guess he was the one who implemented the current ordering.
>
> What do you think, Ludovic?

I agree with you. As long as the entry labels clearly show which one is

the most recent, that sounds good.

However! On headless machines, we’d rather make sure users know about

this change. On our Libreboot “bayfront” server, GRUB for some reason

fails to display anything, and on several occasions we’ve had to blindly

select an older generation. Hopefully this is an unusual situation ;-),

but it could happen on ARM boards as well.

Ludo’.

Mark H Weaver wrote 7 years ago

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87bmegiajc.fsf@netris.org

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (9 lines)

> I agree with you. As long as the entry labels clearly show which one is

> the most recent, that sounds good.

> However! On headless machines, we’d rather make sure users know about

> this change. On our Libreboot “bayfront” server, GRUB for some reason

> fails to display anything, and on several occasions we’ve had to blindly

> select an older generation. Hopefully this is an unusual situation ;-),

> but it could happen on ARM boards as well.

Do you have an idea of how to make sure that users know about it?

Mark

Ludovic Courtès wrote 7 years ago

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87a7u0w9uc.fsf@gnu.org

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (12 lines)> ludo@gnu.org (Ludovic Courtès) writes:
>> I agree with you.  As long as the entry labels clearly show which one is
>> the most recent, that sounds good.
>>
>> However!  On headless machines, we’d rather make sure users know about
>> this change.  On our Libreboot “bayfront” server, GRUB for some reason
>> fails to display anything, and on several occasions we’ve had to blindly
>> select an older generation.  Hopefully this is an unusual situation ;-),
>> but it could happen on ARM boards as well.
>
> Do you have an idea of how to make sure that users know about it?

Not really. I think we can at least send a heads-up to guix-devel and

help-guix.

Ludo’.

Mathieu Othacehe wrote 7 years ago

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87po2vw7al.fsf@gmail.com

Toggle quote (3 lines)

> Not really. I think we can at least send a heads-up to guix-devel and

> help-guix.

Ok. Would the attached patch earlier in the thread be ok for you then ?

Thanks,

Mathieu

Ludovic Courtès wrote 7 years ago

Recipients:(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)

Message-ID:87k1syymu9.fsf@gnu.org

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

Toggle quote (5 lines)

>> Not really. I think we can at least send a heads-up to guix-devel and

>> help-guix.

> Ok. Would the attached patch earlier in the thread be ok for you then ?

Sure!

Ludo'.

Clément Lassieur wrote 7 years ago

control message for bug #31159

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87r2lsji3l.fsf@lassieur.org

tags 31159 fixed

close 31159

Vagrant Cascadian wrote 7 years ago

#31159: Reverse order for old grub.cfg entries

Recipients:(address . 31159@debbugs.gnu.org)

Message-ID:87muwfqy1x.fsf@aikidev.net

On 2018-05-31, GNU bug Tracking System wrote:

Toggle quote (8 lines)

> This is an automatic notification regarding your bug report

> #31159: Reverse order for old grub.cfg entries,

> which was filed against the guix package.

> Thank you for your report, which has now been closed.

> You can view the full report at

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31159

I don't see that the proposed patch was applied to any of the guix

branches I'm aware of. Has it been merged and just not yet been pushed?

Does it need to go to guix-patches instead of guix-bugs?

Thanks!

live well,

vagrant

Mark H Weaver wrote 7 years ago

Recipients:(name . Clément Lassieur)(address . clement@lassieur.org)

Message-ID:87y3fzdzbj.fsf@netris.org

reopen 31159

tags 31159 - fixed

thanks

Hi Clément,

According to our bug tracking system, you added the "fixed" tag to bug

31159 and closed it. I think this must have been a mistake. Did you

intend to close a different bug? This bug has to do with the fact that

the order of old grub.cfg entries should arguably be reversed.

Mark

Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (17 lines)> On 2018-05-31, GNU bug Tracking System wrote:
>> This is an automatic notification regarding your bug report
>> #31159: Reverse order for old grub.cfg entries,
>> which was filed against the guix package.
>>
>> Thank you for your report, which has now been closed.
>> You can view the full report at
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31159
>
> I don't see that the proposed patch was applied to any of the guix
> branches I'm aware of. Has it been merged and just not yet been pushed?
> Does it need to go to guix-patches instead of guix-bugs?
>
> Thanks!
>
> live well,
>   vagrant

Mathieu Othacehe wrote 7 years ago

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87h8mneypz.fsf@gmail.com

Hello,

I tought this one was pushed and told Clément it was ok to push, my

mistake! I just pushed it, so I close the ticket now.

To people used to select bootloader entries with shortcuts, be aware

that at next reconfigure, the entries will be reversed on all

bootloaders (top of the list => most recent configuration).

Thanks,

Mathieu

Mark H Weaver writes:

Toggle quote (33 lines)> reopen 31159
> tags 31159 - fixed
> thanks
>
> Hi Clément,
>
> According to our bug tracking system, you added the "fixed" tag to bug
> 31159 and closed it.  I think this must have been a mistake.  Did you
> intend to close a different bug?  This bug has to do with the fact that
> the order of old grub.cfg entries should arguably be reversed.
>
>        Mark
>
>
> Vagrant Cascadian <vagrant@debian.org> writes:
>
>> On 2018-05-31, GNU bug Tracking System wrote:
>>> This is an automatic notification regarding your bug report
>>> #31159: Reverse order for old grub.cfg entries,
>>> which was filed against the guix package.
>>>
>>> Thank you for your report, which has now been closed.
>>> You can view the full report at
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31159
>>
>> I don't see that the proposed patch was applied to any of the guix
>> branches I'm aware of. Has it been merged and just not yet been pushed?
>> Does it need to go to guix-patches instead of guix-bugs?
>>
>> Thanks!
>>
>> live well,
>>   vagrant

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 31159@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 31159

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags

mumi command -t +confirmed -t +easy

Or, remove the moreinfo tag and set the help tag

mumi command -t -moreinfo -t +help

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date