Description of problem: After updating to a new kernel, the Grub2 default boot option points to another earlier kernel version. Version-Release number of selected component (if applicable): How reproducible: I had it once, but apparently other people had the same snag. See https://www.mageialinux-online.org/forum/topic-24872+petit-soucis-avec-maj-kernel.php Steps to Reproduce: 1.Install M5 and M6 on a single PC 2.Keep all old kernels on both as they get updated. 3.When this list gets long enough, the problem occurs. In my case, all went well till I checked on kernel 4.14.20, and found out the default was reverted back to 4.14.10. I'm pretty sure with 4.14.16 it was still OK, but didn't check after the installation of 4.14.18.
Herman, are you absolutely sure that the grub2 menu you are booting from is owned by the system exhibiting this issue? If system B controls the bootloader and system A has a kernel update then the bootloader will still boot the old kernel in system A until update-grub2 is run in system B. I am sure that you are aware of this, but making the point just to be sure and help others who may not be :)
CC: (none) => zen25000
Yes, I am talking about a system which was booted in MGA6, got kernel updates for MGA6 and was rebooted because of the update. And yes, I have two MGA6's on this machine, but it happened on the same MGA6 which was booted as default. And grub2 in its default setting, does not have a real default boot option. It boots to the latest boot option chosen before. So suppose I had the boot last configured in B, and start system A, grub2 will remember this. If A pulls in a kernel update, it will update its own grub menu choices, and reboot to A. If later I reboot to B, this one will not be aware of what happened to A and reboot to its own last kernel, but certainly not to one of its older versions of the kernel.
Did this maybe go wrong because of bug 22274 ? @ Herman Did you ever use drakboot (from MCC) or the option to set up your bootloader in stage2 in (one of) those two installs? If you choose a kernel version to boot with, then you're bound to get problems, the only safe choice is Mageia 6 without kernel version (which'll default to the latest kernel)
Assignee: bugsquad => zen25000CC: (none) => marja11
No, I only use drakboot in case something went wrong, to correct it as in this case. And that' s precisely the problem here: the choice Mageia 6 without kernel version did not point to the latest kernel.
Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 6's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/ Best regards, Aurélien Bugsquad Team
Resolution: (none) => OLDCC: (none) => ouaurelienStatus: NEW => RESOLVED
Version: 6 => 7
Issue still occurs with Mageia 7
Status: RESOLVED => REOPENEDResolution: OLD => (none)
@Herman, Sorry to see this in Mageia 7. Therefore, the problem you encounter is unsupported upstream. GRUB 2 bootloader must be set by a master distribution and other distributions must not touch it as it results some misbehaving problems. GRUB 2 must be invoked from latest version of Mageia, and os-prober script will look forward other installed systems like Ubuntu, Mint, Windows, macOS,... It is unsupported by us to have 2 versions of our distributions manipulating GRUB conf files. On EFI system, each linux system has his own directory in /boot/EFI and each package manager can update it. But on BIOS legacy system, GRUB2 package from Mageia 7 can be erased by Cauldron version or Fedora or what ever system you dual boot. But in the maintime, our tools and GRUB 2 scripts update correctly GRUB menu each Kernel update. I suggest you report your issue upstream or don't install GRUB with other Linux systems, use a single distribution to update your GRUB. So we won't fix this as it is unsupported upstream.
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX
Summary: Grub2 does not get updated correctly when installing a new kernel => Grub2 does not get updated correctly when installing a new kernel and packages manager (urpmi) does not have control on dual (triple) boot system.
@ Aurelien. To make the point on the configuration I have: 1. It is EFI and originally this laptop had (and still has) Windows10, so that one has set up the original /boot/EFI. 2. I added Mageia (first one, later more) instance to it, still all EFI and had the installation handle the boot stuff on its own, no intervention from my side. 3. The situation is now that each instance has its own / partition (of course) and each of these has in it its own /boot/EFI. Inside each of those is a link "BOOT and "EFI" to the boot/EFI at the beginning of the (rust) disk. To my feeling and memory, if I install a new instance of Mageia, using the standard installer, I have no choice on the boot/efi and grub configuration. I haven't tried Fedora or other more removed cousins , disk space has its limits, so I don't know how these would handle it. Beside, there is another issue with grub2 on such multi-instance installations, in that as soon as the total number of options (having older kernels remaining in the different instances) exceeding some 10 to 12, then the whole grub2 configuration gets corrupted. Each of the instances boots with some kernel, but there is now way to predict which one it could take as default. Luckily grub-customizer can save the situation. I get the impression I would be getting caught in "finger pointing" - grub is at fault - no, mageia makes a mistake - no etc....... I've had a long professional experience in SW development, and I don't want to be involved anymore in such games. Sorry, Aurelien, I realize you are the messenger and you get the unpleasant things over your head, which you do not really deserve.
Reopening it. Sorry being rude, but we can't do upstream jobs. Therefore, you pinpoint the right issue in your latest comment. Assigning to basesystem maintainers, Kernel and Drivers should be here also. We can't support every some particular use of our distribution with multiple instances on same harddrive, but we should prevent /boot from being messed up by too many kernels, initrd, config, here. GRUB does his job populating his menu after every kernel release, but, during lifetime of a release, we publish some updates and new versions of Linux kernel in order to enable new hardware, correct bugs and address security vulnerability in such crucial component. BUT : end-users should not see too much Kernel's images in their /boot. Too many bugs could occurs, and we should not allow booting vulnerable kernels. I think hold "n-1" after updating could be correct and it allows our users to reboot on n-1 kernel if something goes wrong with new one. This is a stopgap and we need to uninstall the old kernels a week after the update, while leaving them in the repositories for urgent reinstallation.
Status: RESOLVED => REOPENEDKeywords: (none) => UPSTREAMAssignee: zen25000 => basesystemResolution: WONTFIX => (none)
Your rule/suggestion to keep only the "n" and "n-1" kernels in the instances is something I tried to remember and maintain manually and up to now it holds ground, but it is an altogether uneasy thing. And wasn't grub to be a solution for multi-instance installations in the first place??? I am reluctant to report this upstream, I think (hope!) there are other people more qualified to have a discussion with the grub people .
Depends on: (none) => 24403
See 24403. GRUB is here for that, I agree but his scripts do their jobs for what they are written. But, too many kernels for a same instance of a system in not good enough situation. End-user does not mind having too many kernels in /boot. Also, this should be automated by our tools.
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
It got even worse with M8, in the way that following the various kernel updates, it has screwed up the normal structure of the different options. Normally you get - normal entry for the default (i.e. latest) kernel of an installation - the "Advanced" section which allows to select an older version. I will try to make some photos from the grub menus and load them here.
Created attachment 12846 [details] Menu from M7 partition
Created attachment 12847 [details] Main menu from M8 partition - first part
Created attachment 12848 [details] Main menu from M8 partition - ssecond part
Some explanation of the pictures: Menu from M7 This is an M7 partition on /dev/sda11 which lists the other OS as well. This menu is the submenu for the M8 partition on sda12 and is totally wrong: this partition has been updated with kernel versions 45.2 and 46 and the kernels 43 and 37 were removed before the M7 was updated to 46 and had its startsystem generated in MCC. Main menu from M8 partition on sda8 -first part. This is first part because the menu is longer than fits on one screen. It is clear that the normal structure is completely broken. But at least th entries are correct in their contents. Main menu from M8 partition on sda8 -second part. This shows the entries for the M7 partition, but the default is not correct since it points to version 45.2, while the advanced entry when expanded lists the versions 45.2 and 46 correctly. Note: I never edit the grub files manually!!!!
Version: 7 => 8
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Resolution: (none) => OLDStatus: REOPENED => RESOLVED