Bug 22274 - drakboot should suggest "Mageia (<kernel flavour>) 7" as default choice, instead of "Mageia" or "Mageia (<the oldest version of a kernel flavour>) 7"
Summary: drakboot should suggest "Mageia (<kernel flavour>) 7" as default choice, inst...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: MGA6TOO
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-28 11:24 CET by Shlomi Fish
Modified: 2022-08-12 15:07 CEST (History)
8 users (show)

See Also:
Source RPM: drakxtools
CVE:
Status comment:


Attachments
journalctl output for the boot. (128.38 KB, application/x-xz)
2017-12-28 15:14 CET, Shlomi Fish
Details

Description Shlomi Fish 2017-12-28 11:24:00 CET
Description of problem:

After I upgrade my kernel using urpmi, it does not set the latest kernel as default. As I discovered today, this was doable using https://www.gnu.org/software/grub/manual/grub/grub.html#Environment-block (grub2-editenv), but without it at first boot I am still getting the old kernel by default (subsequent boots remember the last kernel).

Version-Release number of selected component (if applicable):

Cauldron.

How reproducible:

Always.

Steps to Reproduce:
1. Install a new kernel-dekstop-latest.
2. Reboot.
3.
Comment 1 Marja Van Waes 2017-12-28 13:46:56 CET
Hi Shlomi,

Funny, I thought there was a bug report from you about this issue, but I can't find it. Maybe you only mentioned it on IRC?

I don't see how urpmi could cause this, but using DNF I didn't reproduce it back then, nor now.

[root@localhost marja]# journalctl -b | grep "Linux version"
dec 28 13:10:33 localhost kernel: Linux version 4.14.9-desktop-2.mga7 
etc.

[root@localhost marja]# journalctl -b -1 | grep "install kernel-desktop-latest"
dec 28 09:21:25 localhost [RPM][6561]: install kernel-desktop-latest-4.14.9-2.mga7.x86_64: success
dec 28 09:24:11 localhost [RPM][6561]: install kernel-desktop-latest-4.14.9-2.mga7.x86_64: success
[root@localhost marja]# 

But maybe my luck is that installing kernel-desktop-latest was a double success ;-)

More seriously: in between those "successes", the links in /boot were updated and so was /boot/grub2/grub.cfg, they all have  "dec 28 09:23" as time stamp.

On your system, do they have a time stamp from when you were updating the kernel on your system?

Can you attach the log from the install?

At the moment you started to install, had the EFI or MBR bootloader then last been written from the same Mageia install or from a different one?

Keywords: (none) => NEEDINFO
Source RPM: kernel-4.14.9-2.mga7.src.rpm => kernel-4.14.9-2.mga7.src.rpm, urpmi???
CC: (none) => mageiatools, marja11
Assignee: bugsquad => kernel

Comment 2 Shlomi Fish 2017-12-28 15:13:27 CET
Hi Marja,

(In reply to Marja van Waes from comment #1)
> Hi Shlomi,
> 
> Funny, I thought there was a bug report from you about this issue, but I
> can't find it. Maybe you only mentioned it on IRC?
> 

I did mention it there.

> I don't see how urpmi could cause this, but using DNF I didn't reproduce it
> back then, nor now.
> 
> [root@localhost marja]# journalctl -b | grep "Linux version"
> dec 28 13:10:33 localhost kernel: Linux version 4.14.9-desktop-2.mga7 
> etc.
> 
> [root@localhost marja]# journalctl -b -1 | grep "install
> kernel-desktop-latest"
> dec 28 09:21:25 localhost [RPM][6561]: install
> kernel-desktop-latest-4.14.9-2.mga7.x86_64: success
> dec 28 09:24:11 localhost [RPM][6561]: install
> kernel-desktop-latest-4.14.9-2.mga7.x86_64: success
> [root@localhost marja]# 
> 
> But maybe my luck is that installing kernel-desktop-latest was a double
> success ;-)
> 
> More seriously: in between those "successes", the links in /boot were
> updated and so was /boot/grub2/grub.cfg, they all have  "dec 28 09:23" as
> time stamp.
> 

grub.cfg was updated, but not /boot/grub2/grubenv.

> On your system, do they have a time stamp from when you were updating the
> kernel on your system?
> 

root@telaviv1:~$ ls -l /boot/grub2/grub.cfg
-rw-r--r-- 1 root root 49007 Dec 28 15:34 /boot/grub2/grub.cfg

looks fine

> Can you attach the log from the install?
> 

I'm going to attach it.

> At the moment you started to install, had the EFI or MBR bootloader then
> last been written from the same Mageia install or from a different one?

from the same one/
Comment 3 Shlomi Fish 2017-12-28 15:14:04 CET
Created attachment 9859 [details]
journalctl output for the boot.
Comment 4 Marja Van Waes 2017-12-29 16:28:56 CET
(In reply to Shlomi Fish from comment #2)

Thanks, Shlomi :-)
> 
> (In reply to Marja van Waes from comment #1)

> > 
> > More seriously: in between those "successes", the links in /boot were
> > updated and so was /boot/grub2/grub.cfg, they all have  "dec 28 09:23" as
> > time stamp.
> > 
> 
> grub.cfg was updated, but not /boot/grub2/grubenv.

Here /boot/grub2/grubenv doesn't get updated on a kernel update, either.

It only contains:
# GRUB Environment Block
saved_entry=gnulinux-simple-<the UUID of my root partition>
(and then one line with 934 #s)

What did your grubenv look like, before you edited it for the first time? And  before and after you edited it yesterday?

CC'ing barjac


> 
> > On your system, do they have a time stamp from when you were updating the
> > kernel on your system?
> > 
> 
> root@telaviv1:~$ ls -l /boot/grub2/grub.cfg
> -rw-r--r-- 1 root root 49007 Dec 28 15:34 /boot/grub2/grub.cfg
> 
> looks fine

That's over 4 hours after you updated the kernel ;-) I suppose you've run update-grub2 after editing grubenv.

> 
> > Can you attach the log from the install?
> > 
> 
> I'm going to attach it.

I hope barjac can tell whether there is anything odd with the grub2 configuration part.

CC: (none) => zen25000
Source RPM: kernel-4.14.9-2.mga7.src.rpm, urpmi??? => kernel-4.14.9-2.mga7.src.rpm, urpmi???, grub2???

Comment 5 Shlomi Fish 2017-12-29 18:00:55 CET
Hi Marja,

sorry for the late reply.

(In reply to Marja van Waes from comment #4)
> (In reply to Shlomi Fish from comment #2)
> 
> Thanks, Shlomi :-)
> > 
> > (In reply to Marja van Waes from comment #1)
> 
> > > 
> > > More seriously: in between those "successes", the links in /boot were
> > > updated and so was /boot/grub2/grub.cfg, they all have  "dec 28 09:23" as
> > > time stamp.
> > > 
> > 
> > grub.cfg was updated, but not /boot/grub2/grubenv.
> 
> Here /boot/grub2/grubenv doesn't get updated on a kernel update, either.
> 
> It only contains:
> # GRUB Environment Block
> saved_entry=gnulinux-simple-<the UUID of my root partition>
> (and then one line with 934 #s)
> 
> What did your grubenv look like, before you edited it for the first time?
> And  before and after you edited it yesterday?
> 

Now it looks like this:

root@telaviv1:~$ grub2-editenv /boot/grub2/grubenv list
saved_entry=gnulinux-advanced-d320c338-58a2-4aa6-9d47-d2c0bc60524b>gnulinux-4.14.9-desktop-2.mga7-advanced-d320c338-58a2-4aa6-9d47-d2c0bc60524b
root@telaviv1:~$ 

Previously, it had that only with rel 1 instead of 2.

> CC'ing barjac
> 
> 
> > 
> > > On your system, do they have a time stamp from when you were updating the
> > > kernel on your system?
> > > 
> > 
> > root@telaviv1:~$ ls -l /boot/grub2/grub.cfg
> > -rw-r--r-- 1 root root 49007 Dec 28 15:34 /boot/grub2/grub.cfg
> > 
> > looks fine
> 
> That's over 4 hours after you updated the kernel ;-) I suppose you've run
> update-grub2 after editing grubenv.
> 

something like that.

> > 
> > > Can you attach the log from the install?
> > > 
> > 
> > I'm going to attach it.
> 
> I hope barjac can tell whether there is anything odd with the grub2
> configuration part.
Comment 6 Barry Jackson 2017-12-29 19:53:25 CET
Sounds like you have something set in /etc/default/grub that is saving the last booted kernel for next time. (see bug link below)

It's not configured that way in the grub2 packaging, but drakxtools does edit /etc/default/grub by adding something like:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

I would simply remove those two lines if you have them and replace with:
GRUB_DEFAULT=0

Then run update-grub2

That will always boot the first kernel in the list which is always a link to the latest.

There is no reason to ever edit grubenv manually as far as I am aware.

Some comments in here may help:
https://bugs.mageia.org/show_bug.cgi?id=18560
Comment 7 Marja Van Waes 2017-12-30 09:51:15 CET
(In reply to Barry Jackson from comment #6)
> Sounds like you have something set in /etc/default/grub that is saving the
> last booted kernel for next time. (see bug link below)
> 
> It's not configured that way in the grub2 packaging, but drakxtools does
> edit /etc/default/grub by adding something like:
> 
> GRUB_DEFAULT=saved
> GRUB_SAVEDEFAULT=true

I had those settings, too, yet I did't have this bug.

I was wondering where Shlomi's kernel_version & release in his grubenv came from.

So I ran drakboot. It amazed me that the default kernel to boot with, is the *oldest* kernel, which is at the top of drakboot's list. Using that gives this line in grubenv:
saved_entry=Advanced options for Mageia>Mageia (4.13.10-desktop-1.mga7) 7

"Mageia (desktop) 7" is the one but last option in drakboot's list (the very last entry is the same, but recovery) I think drakboot should have proposed that one.

I don't find a bug report about drakboot proposing to use the oldest kernel. I'll check in my other cauldrons whether it happens there, too.

> 
> I would simply remove those two lines if you have them and replace with:
> GRUB_DEFAULT=0
> 
> Then run update-grub2
> 
> That will always boot the first kernel in the list which is always a link to
> the latest.

If that list has a different order than the one that drakboot uses.
Does it?

> 
> There is no reason to ever edit grubenv manually as far as I am aware.
> 
> Some comments in here may help:
> https://bugs.mageia.org/show_bug.cgi?id=18560

Source RPM: kernel-4.14.9-2.mga7.src.rpm, urpmi???, grub2??? => drakxtools
Assignee: kernel => mageiatools
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18560

Comment 8 Barry Jackson 2017-12-30 11:11:13 CET
The list I was referring to was the list created by grub2 in it's menu. There the top entry uses vmlinuz which is a link to the latest kernel.

The latest kernel in /boot/ listed alphanumerically will be at the bottom, so maybe that is how drakboot shows them?

I will test drakboot in cauldron later as running Mga6 just now.
Comment 9 Barry Jackson 2017-12-30 11:34:29 CET
I just checked in Mga6 and it's the same.
Drakboot 'proposes' the oldest, but that does not reflect what is currently being used, as the oldest is 4.9.30 and I am booting 4.9.56.

The grubenv has only:
saved_entry=gnulinux-simple-ef35d404-24fa-4e23-9437-55ed93f93658

which is the uuid of the root partition.

I have never changed the default using drakboot on this (or any) machine so it's a 'clean' reference.
Comment 10 Marja Van Waes 2017-12-30 12:16:03 CET
(In reply to Barry Jackson from comment #9)
> I just checked in Mga6 and it's the same.
> Drakboot 'proposes' the oldest, but that does not reflect what is currently
> being used, as the oldest is 4.9.30 and I am booting 4.9.56.

So keeping drakboot's proposal, even when only one kernel is installed, will keep the system from booting into newly installed kernels. 
> 
> The grubenv has only:
> saved_entry=gnulinux-simple-ef35d404-24fa-4e23-9437-55ed93f93658
> 
> which is the uuid of the root partition.
> 
> I have never changed the default using drakboot on this (or any) machine so
> it's a 'clean' reference.

Mine was like that too, before I played with drakboot. And it works well like that: new kernels do get booted on first reboot after installing them.
Btw, I didn't make changes with drakboot in the summary step of Mageia install, either.

@ Shlomi

Do you remember having run drakboot (either in the installed system or in the summary step during install) and saved changes with it _before_ hitting this bug?
Comment 11 Barry Jackson 2017-12-30 13:46:56 CET
(In reply to Marja van Waes from comment #10)
> (In reply to Barry Jackson from comment #9)
> > I just checked in Mga6 and it's the same.
> > Drakboot 'proposes' the oldest, but that does not reflect what is currently
> > being used, as the oldest is 4.9.30 and I am booting 4.9.56.
> 
> So keeping drakboot's proposal, even when only one kernel is installed, will
> keep the system from booting into newly installed kernels.

It would seem so.
 
I just set up my current cauldron with the default /etc/default/grub setup and ran drakboot where I selected the "Mageia (Desktop) 7" option.
Next boot was OK into current latest kernel.
I then updated Cauldron with the new kernel and re-booted.
I selected the top 'Mageia' option, and the system booted into the new kernel.

I think the only "bug" here is that drakboot rather 'quietly' offers the oldest kernel as default.
It works perfectly in that it does exactly what it says it is going to do.
It should however offer "Mageia (desktop) 7" initially, as it's too easy to click through that page without making a proper selection, especially as in some cases where a lot of kernels are installed the 'proper/normal' selection is also off the page initially presented by the chooser.
Comment 12 Marja Van Waes 2018-01-05 11:57:13 CET
(In reply to Barry Jackson from comment #11)

> 
> I think the only "bug" here is that drakboot rather 'quietly' offers the
> oldest kernel as default.
> It works perfectly in that it does exactly what it says it is going to do.
> It should however offer "Mageia (desktop) 7" initially, as it's too easy to
> click through that page without making a proper selection, especially as in
> some cases where a lot of kernels are installed the 'proper/normal'
> selection is also off the page initially presented by the chooser.

Updating the summary.

I don't know how the list is created, with some luck reversing the sort order will fix the problem. (Else recovery mode will appear at the top, then, which we don't want, either)

Summary: Installing kernel-desktop-latest does not set it as the default on boot => drakboot should suggest "Mageia (<kernel flavour>) 7" as default choice, instead of "Mageia (<the oldest version of a kernel flavour>) 7"

Comment 13 Marja Van Waes 2018-01-05 11:59:09 CET
@ Shlomi

I'm removing "NEEDINFO" because I assume you agree the summary reflects the actual problem.

Feel free to adjust the summary and explain if you don't agree... you're the author of this report, I don't want to hijack it!

Keywords: NEEDINFO => (none)

Comment 14 Marja Van Waes 2018-06-01 22:04:51 CEST
(In reply to Barry Jackson from comment #9)
> I just checked in Mga6 and it's the same.
> Drakboot 'proposes' the oldest, but that does not reflect what is currently
> being used, as the oldest is 4.9.30 and I am booting 4.9.56.

adding MGA6TOO

Increasing severity, because this'll bite many users.

Severity: normal => major
Whiteboard: (none) => MGA6TOO

Comment 15 Marja Van Waes 2019-04-20 07:41:21 CEST
It would be good if this could be fixed before Mageia 7 release, recently a bug reporter was found to boot a very old Mageia 6 kernel, instead of his latest Mageia 7 one :-(

Severity: major => critical
Priority: Normal => release_blocker

Comment 16 Marja Van Waes 2019-04-20 07:53:44 CEST
It seems the default choice now is "Mageia", instead of "Mageia (<the oldest version of a kernel flavour>) 7" but for the user who reported bug 24692, that still results in booting an old kernel.

I don't understand that, though, because vmlinuz and initrd link to the latest vmlinuz and latest initrd... or don't they for all?

Summary: drakboot should suggest "Mageia (<kernel flavour>) 7" as default choice, instead of "Mageia (<the oldest version of a kernel flavour>) 7" => drakboot should suggest "Mageia (<kernel flavour>) 7" as default choice, instead of "Mageia" or "Mageia (<the oldest version of a kernel flavour>) 7"

Comment 17 Martin Whitaker 2019-04-22 21:00:54 CEST
I fixed the installer/drakboot to propose "Mageia" as the default choice back in October. I believe that is the correct thing to do - everything else is hidden under "Advanced options for Mageia".

By experimentation (on a mga7 system using the -desktop kernel) I find:

1. The vmlinuz and initrd.img (and also vmlinuz-desktop and initrd-desktop.img) soft links point to the last kernel installed.

2. update-grub2 sets the "Mageia" entry to boot the kernel with the highest version number.

3. update-grub2 adds a "Mageia (desktop) 7" entry under "Advanced options..." which boots the vmlinuz-desktop soft link.

4. update-grub2 does *not* add an entry that boots the vmlinuz soft link.

5. Uninstalling a kernel does not correctly update the soft links or the grub2 config.

CC: (none) => mageia

Comment 18 Thierry Vignaud 2019-04-23 16:23:23 CEST
For latest point, I suggested a fix in https://bugs.mageia.org/show_bug.cgi?id=16268#c9

CC: (none) => thierry.vignaud

Marja Van Waes 2019-05-13 17:33:26 CEST

CC: (none) => lewyssmith

Comment 19 Aurelien Oudelet 2020-12-13 11:46:12 CET
Ping?

CC: (none) => ouaurelien

Comment 20 Dave Hodgins 2021-01-28 00:04:26 CET
Status?

CC: (none) => davidwhodgins

Comment 21 Martin Whitaker 2021-01-28 10:10:26 CET
I don't know for sure, because I don't use GRUB2, but I believe the "Mageia" entry will always boot the newest installed kernel, and that is the entry selected by default on a new install. If the user chooses a different entry, GRUB2 will remember that for the next boot, unless the user changes /etc/default/grub to disable that feature.
Comment 22 Aurelien Oudelet 2021-01-28 10:15:09 CET
Martin you're right. As far as I try, by default grub2 Always select Mageia (release version) as default entry with the latest installed Kernel.

I do think all seem fixed.
Comment 23 Lewis Smith 2021-01-29 13:22:54 CET
My penny's worth.
I do not like at all the fact that the top "Mageia" line says just that; you do not know exactly what you are booting - especially if you have >1 Mageia installed (I do). It would be clearer if it was not anonymous: ideally the partition ID, optionally the kernel ID. Like all the other entries.
Comment 24 Frédéric "LpSolit" Buclin 2021-01-29 20:19:25 CET
(In reply to Lewis Smith from comment #23)
> I do not like at all the fact that the top "Mageia" line says just that; you
> do not know exactly what you are booting - especially if you have >1 Mageia
> installed (I do). It would be clearer if it was not anonymous: ideally the
> partition ID, optionally the kernel ID. Like all the other entries.

I disagree. I think most (99% or more) users have only one Mageia on their machine, and it would be ugly to display something too technical to them. Those (<1%) who have several Mageia installations on their machine should know enough what they are doing to click "advanced options" if they need more information.
Comment 25 Lewis Smith 2021-01-30 14:29:55 CET
We beg to differ! Never mind.

@ Shlomi: all the evidence here defends that the top "Mageia" entry *does* boot the last installed  kernel. The essence of the bug was that in your case, it did not. 3y ago.
Do you still maintain the complaint? If not, we can close the bug.

Priority: release_blocker => Normal
Severity: critical => normal

Comment 26 sturmvogel 2022-08-12 15:07:56 CEST
1 and a half year later after comment 25..no response.
The initial problem that not the latest kernel was booted is fixed. The design of the bootloader is a matter of taste....
Closing as FIXED.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.