Description of problem: When a new kernel is installed, bootloader-config seems to update the config files for a single bootloader when multiple are installed. For example, I have grub, grub2 and refind installed and bootloader-config only updated the refind config files, leaving grub and grub2 alone. Since I installed refind only for emergencies, grub for historical reasons and use grub2 to actually boot, I didn't notice that I was running a months-old kernel for, well, months. bootloader-config should update the config files for *all* installed and/or configured bootloaders, not just one (apparantly) random one. Version-Release number of selected component (if applicable): 19.21-1 How reproducible: Happens with grub, grub2 and refind installed Steps to Reproduce: 1. Install more than one bootloader 2. Install a new kernel 3. Note that only one bootloader's config files were updated
Hardware: All => x86_64
Hi, thanks reporting this. drakboot can't support more than one bootloader concurrently. (In reply to Dan Fandrich from comment #0) > > bootloader-config should update the config files for *all* installed and/or > configured bootloaders, not just one (apparently) random one. In facts, I suspect it can support only last installed bootloader. Having GRUB AND grub2 at the same time is not supported upstream. We provide several bootloaders, like grub, lilo, grub2 and refind. But, as we write a tool, drakboot, to configure them, our end-user MUST choose only one of them that is suitable for their current system. So I'm willing to say: INVALID (In reply to Dan Fandrich from comment #0) > Description of problem: > When a new kernel is installed, bootloader-config seems to update the config > files for a single bootloader when multiple are installed. For example, I > have grub, grub2 and refind installed and bootloader-config only updated the > refind config files, leaving grub and grub2 alone. Since I installed refind > only for emergencies, grub for historical reasons and use grub2 to actually > boot, I didn't notice that I was running a months-old kernel for, well, > months. I suggest you to drop grub as grub2 is here and supported upstream. Grub legacy will not see new major feature. Also, to emergency issue, you should use a LIVE USB/ISO: we have a tool on it to restore faulty bootloader on production system. You have a choice to make: GRUB2 or REFIND. So, this behavior is not bug from us but a side-effect from you making no choice. Feel free to reopen this issue if not satisfied.
CC: (none) => ouaurelienStatus: NEW => RESOLVEDResolution: (none) => INVALIDAssignee: bugsquad => mageiatools
I had grub installed before I switched to grub2 and didn't remove it since I wanted it available if I needed it to fix grub on an external drive. I installed refind as an emergency backup in case grub2 got hosed, since UEFI can switch between them easil. Refind is good at detecting all the OSes installed without even having to update config files, so it seemed like it would be a benign safety net (and it got me out of a number of situations where I would have been stuck while I was switching over to grub2). So, I really only need grub2 config files written when I install a new kernel today. It would be nice to have all three config files written (and I didn't spot any technical reason why it couldn't) so I have a backup bootloader available in case one gets hosed, but I really only *need* grub2. If bootloader-config won't be changed to write them all, then it should give a choice as to which one to write when there's a choice, e.g. with something in /etc/sysconfig/installkernel In my case, I deleted /boot/refind_linux.conf and that was enough for it to start writing grub2 config files, but it would be nice to have an explicit mechanism for this.
Request for enhancement. Reopening it. Packagers: this should be discussed on dev ML. Will do it. @Dan, I will go back with answers. Leaving this in Bugsquad for now, until discuss done.
Resolution: INVALID => (none)Status: RESOLVED => REOPENEDAssignee: mageiatools => bugsquadSeverity: normal => enhancement
Also, as I understand it, grub (legacy) and lilo do not support ext file systems with an inode size over 128 bytes. As the default size was changed to 256 bytes to support larger file systems, they can only be used with old file systems or ones where the inode-size has explicitly been specified as 128 bytes during mkfs. They are still supported for people upgrading from prior releases.
CC: (none) => davidwhodgins
If we switched to bootloader spec for grub2, we could make drakboot work just fine for grub2, systemd-boot, u-boot, and refind using the same configuration snippets.
CC: (none) => ngompa13
@Neal, can we support more than one bootloader at the same time on same system? I don't think it is possible. But it could be useful to support on x86_64 grub2, refind and systemd-boot, and for ARM, u-boot is required.
U-Boot 2020.10 is released upstream.
Just fyi, on a Mageia 8 uefi system with both grub2-efi and refind installed, using mcc/Boot/Set up boot system to switch back and forth between the two does work. The only catch is that when using refind, update-grub2 must be run manually before switching back.
(In reply to Dave Hodgins from comment #8) > The only catch is that when using refind, update-grub2 must be run manually > before switching back. True if booting via Grub, but in my case Grub is not needed at all, as this refind.conf contains: dont_scan_dirs EFI/tmp EFI/mageia
CC: (none) => maurice
Without editing the refind.conf refind has two icons for Mageia. The first is for EFI\mageai\grubx64.efi from SYSTEM which then starts grub2. The second is for boot\vmlinuz-(latest version) from the Mageia installation. I normally use the second. If I use the first it will be using a grub menu that does not include the kernel updates unless I've run update-grub2. I have to use the first one, using grub if I want an older kernel for any reason. That said, comment 8 was about using mcc to overwrite the boot loader used for starting the system so that refind is not used at all.
(In reply to Dan Fandrich from comment #2) > If bootloader-config won't be changed to write them all, then it should give > a choice as to which one to write when there's a choice, e.g. with something > in /etc/sysconfig/installkernel In my case, I deleted > /boot/refind_linux.conf and that was enough for it to start writing grub2 > config files, but it would be nice to have an explicit mechanism for this. There *is* an explicit mechanism to do this - it's called drakboot. Use that to select the bootloader. When you switch away from rEFInd it will rename /boot/refind_linux.conf to /boot/refind_linux.unused so it is easily recoverable. (In reply to Dave Hodgins from comment #8) > The only catch is that when using refind, update-grub2 must be run manually > before switching back. That needs to be fixed. (In reply to Dave Hodgins from comment #10) > Without editing the refind.conf refind has two icons for Mageia. The first > is for EFI\mageai\grubx64.efi from SYSTEM which then starts grub2. The second > is for boot\vmlinuz-(latest version) from the Mageia installation. > > I normally use the second. If I use the first it will be using a grub menu > that does not include the kernel updates unless I've run update-grub2. > > I have to use the first one, using grub if I want an older kernel for any > reason. In the rEFInd menu, select the icon and press F2. That will let you boot any of the installed kernels. Or change refind.conf to give you a separate icon for each kernel version. Press F2 again if you need to edit the boot command line.
CC: (none) => mageia
Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Status: REOPENED => NEWAssignee: bugsquad => mageiatools
(In reply to Martin Whitaker from comment #11) > (In reply to Dave Hodgins from comment #8) > > The only catch is that when using refind, update-grub2 must be run manually > > before switching back. > > That needs to be fixed. > I just tested that in a cauldron VM. When using drakboot to change from rEFInd to GRUB2, it automatically ran update-grub2. If you can reproduce a case where that doesn't happen, please open a new bug report and attach an extract of the system journal covering the time drakboot was running.
With refind in control there are two icons for Mageia 8. The first loads the grub menu, the second goes directly to the selected kernel. The second is the one that is normally used. When a new kernel is installed an old ones removed, the grub menu is not updates. This is not using mcc to put grub back in control, but just using the refind icon to select the gru menu.
I understand you now Dave. When switching to rEFInd, drakboot doesn't delete the contents of \EFI\mageia, because it might belong to another Mageia installation which hasn't been configured for rEFInd. I use rEFInd exclusively, so don't have anything in \EFI\mageia and don't have the annoyance of that additional icon.
(In reply to Martin Whitaker from comment #15) > I use rEFInd exclusively, so don't have anything in \EFI\mageia and don't > have the annoyance of that additional icon. +1
I try to explore as many ways of doing things as I can, during testing.
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.
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Status: NEW => RESOLVEDResolution: (none) => OLD