| Summary: | Mageia 9 cannot boot: grub_stack_addr not found | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frédéric "LpSolit" Buclin <LpSolit> |
| Component: | Installer | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | critical | ||
| Priority: | High | CC: | lewyssmith, mageia |
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
grub 2 error message
installer error message Screenshot of the BIOS |
||
Created attachment 14060 [details]
installer error message
Here is the error I got when doing a clean install. These conflicts do not make sense to me.
Here is what I tested: 1) Upgrade from Mageia 8 to Mageia 9 2) Clean install without reformatting the / partition (SSD disk) 3) Clean install with reformatting the / partition + online updates 4) Clean install with reformatting the / partition without online updates (Classic DVD only) In all 4 cases do I get the exact same error message, see attachment 14059 [details]: Loading Linux 6.4.9-desktop-4.mga9... error: ../../grub-core/kern/dl.c:429:symbol `grub_stack_addr` not found. I cannot reproduce the dependencies error mentionned in comment 1, so let's ignore it. @martinw: any idea what's going on? CC:
(none) =>
mageia That suggests your system is still booting from a grubx64.efi image generated by an older version of GRUB. I can reproduce this error by: 1. Installing Mageia 8. 2. Copying /boot/EFI/EFI/mageia/grubx64.efi to /boot/EFI/EFI/mageia/mageia8.efi 3. Installing Mageia 9, reformatting the root partition but not reformatting the ESP. 4. In the BIOS, booting from the file \EFI\mageia\mageia8.efi in the ESP. So either the installer/GRUB is failing to update the grubx64.efi image, or there's another image in a different location (e.g. in \EFI\BOOT) and the BIOS is booting from that instead. OK, I managed to make it work, but this was a terrific experience. I installed all versions of Mageia, from 1 to 9, and this one was definitely the worst I ever had, and also the first one to not work "out of the box". As you suggested, the BIOS was looking at /boot/EFI/EFI/BOOT/BOOTX64.EFI instead of /boot/EFI/EFI/mageia/grubx64.efi. So I reformatted /boot/EFI to have a clean partition, but everything went wrong from this point as my BIOS was unable to boot my machine, because only mageia/grubx64.efi was created. I had to reinstall from the DVD and ask the installer to install a copy into BOOT/BOOTX64.EFI. This was really not intuitive. I don't know why my BIOS didn't search for another .efi file instead of failing to boot miserably. Feel free to mark this bug as invalid as I don't understand who exactly is the culprit. Oh, and thanks for you help, Martin! :) Thanks Martin for your help. (In reply to Frédéric "LpSolit" Buclin from comment #4) > As you suggested, the BIOS was looking at /boot/EFI/EFI/BOOT/BOOTX64.EFI > instead of /boot/EFI/EFI/mageia/grubx64.efi. The first file is the 'default' disc bootloader, normally used when the EFI BootOrder BootXXXX entries do not work. The Mageia BootXXXX entry should be the first in BootOrder in order for it to be actioned. Try # efibootmgr to see these things. Some bad machines always boot from the default bootloader anyway (and cannot boot if there is no valid bootloader there). > So I reformatted /boot/EFI to > have a clean partition, but everything went wrong from this point as my BIOS > was unable to boot my machine If the ESP really is empty, the machine cannot boot from the hard disc, just a removeable device. > because only mageia/grubx64.efi was created. This is normal and should be OK if the corresponding NVRAM BootXXXX and BootOrder are correct. Here is an example: # efibootmgr BootCurrent: 0005 BootOrder: 0005,0004,0000,0002 Boot0000* mageia HD(1,GPT,6d0f2485-ef1b-403f-b120-46f1da2333a3,0x800,0x32000)/File(\EFI\MAGEIA\GRUBX64.EFI) ... In my case, this entry would be the 3rd one tried if the previous two (5,4) do not fly. Normally, BootOrder should start with the Mageia Bootxxxx entry. > I had to reinstall from the DVD and ask the installer to install a copy into > BOOT/BOOTX64.EFI. This was really not intuitive. I don't know why my BIOS > didn't search for another .efi file instead of failing to boot miserably. We do not know now what the EFI Bootxxxx entries and BootOrder were at the end of the first installation. Nor what exactly was in the ESP and mageia/grubx64.efi - the new file, or an old one. > Feel free to mark this bug as invalid as I don't understand who exactly is > the culprit. Thanks for the offer. There is a dated Wiki "About EFI" about this (I see that the output of efibootmgr has grown from that illustrated). CC:
(none) =>
lewyssmith (In reply to Lewis Smith from comment #6) > The first file is the 'default' disc bootloader, normally used when the EFI > BootOrder BootXXXX entries do not work. The Mageia BootXXXX entry should be > the first in BootOrder in order for it to be actioned. > Try > # efibootmgr > to see these things. Some bad machines always boot from the default > bootloader anyway (and cannot boot if there is no valid bootloader there). Here is what I get: $ efibootmgr BootCurrent: 0002 Timeout: 0 seconds BootOrder: 0002,0001,0003,0004,0005 Boot0001* UEFI: ATAPI iHAS124 F PciRoot(0x0)/Pci(0x17,0x0)/Sata(4,65535,0)/CDROM(1,0x21a62f,0x2000)0000424f Boot0002* UEFI OS HD(1,GPT,...,0x800,0x95822)/File(\EFI\BOOT\BOOTX64.EFI)0000424f So it only mentions BOOTX64.EFI. Before the upgrade, the BIOS was listing both BOOTX64.EFI and mageia. No idea why mageia is not listed again. (In reply to Frédéric "LpSolit" Buclin from comment #4) > I had to reinstall from the DVD and ask the installer to install a copy into > BOOT/BOOTX64.EFI How did you manage that? You say "a copy". I wonder whether having done that, it did not install also the normal mageia/grubx64.efi. If it did not, that would be en error. This command is great for seeing what is what in the ESP: # tree /boot/EFI/EFI and when comparing different - or duplicated - bootloaders, you need 'ls -l' to see their exact sizes and dates. The output in the previous comment looks incomplete. No Boot0004 Boot0005 entries? \EFI\BOOT\BOOTX64.EFI is presumably the Mageia Grub bootloader in disguise. (In reply to Lewis Smith from comment #8) > > I had to reinstall from the DVD and ask the installer to install a copy into > > BOOT/BOOTX64.EFI > How did you manage that? You say "a copy". I clicked the "Install in /EFI/BOOT" checkbox in the bootloader configuration panel: https://doc.mageia.org/installer/8/en/content/images/rEFIndLoaderConfig.png I said "copy" in my previous comment because they are exactly the same file: $ md5sum /boot/EFI/EFI/BOOT/BOOTX64.EFI /boot/EFI/EFI/mageia/grubx64.efi cfbca234ecad154a61eb3060cd8e0cbe /boot/EFI/EFI/BOOT/BOOTX64.EFI cfbca234ecad154a61eb3060cd8e0cbe /boot/EFI/EFI/mageia/grubx64.efi > I wonder whether having done that, it did not install also the normal > mageia/grubx64.efi. If it did not, that would be en error. $ ls -alR /boot/EFI/EFI/ /boot/EFI/EFI/: total 16 drwxrwxrwx 4 root root 4096 oct 16 04:14 ./ drwxrwxrwx 3 root root 4096 jan 1 1970 ../ drwxrwxrwx 2 root root 4096 oct 16 04:32 BOOT/ drwxrwxrwx 2 root root 4096 oct 16 04:21 mageia/ /boot/EFI/EFI/BOOT: total 164 drwxrwxrwx 2 root root 4096 oct 16 04:32 ./ drwxrwxrwx 4 root root 4096 oct 16 04:14 ../ -rwxrwxrwx 1 root root 159744 oct 16 04:32 BOOTX64.EFI* /boot/EFI/EFI/mageia: total 164 drwxrwxrwx 2 root root 4096 oct 16 04:21 ./ drwxrwxrwx 4 root root 4096 oct 16 04:14 ../ -rwxrwxrwx 1 root root 159744 oct 16 04:21 grubx64.efi* As you can see, mageia/grubx64.efi has been created the first time I ran the installer, at 4:21am (yes, I was not yet sleeping). When I rebooted the machine, the BIOS didn't find any bootloader and my machine falled back to the BIOS interface. When I then clicked the "Install in EFI/BOOT" checkbox on the 2nd run, BOOT/BOOTX64.EFI has been created, at 4:32am. Then the machine could boot correctly into Mageia 9. I checked in the BIOS interface, and it doesn't list mageia, but only the default one. > The output in the previous comment looks incomplete. No Boot0004 Boot0005 > entries? I truncated the output because they were not relevant. The full output is: $ efibootmgr BootCurrent: 0002 Timeout: 0 seconds BootOrder: 0002,0001,0003,0004,0005 Boot0001* UEFI: ATAPI iHAS124 F PciRoot(0x0)/Pci(0x17,0x0)/Sata(4,65535,0)/CDROM(1,0x21a62f,0x2000)0000424f Boot0002* UEFI OS HD(1,GPT,...,0x800,0x95822)/File(\EFI\BOOT\BOOTX64.EFI)0000424f Boot0003* UEFI:CD/DVD Drive BBS(129,,0x0) Boot0004* UEFI:Removable Device BBS(130,,0x0) Boot0005* UEFI:Network Device BBS(131,,0x0) > \EFI\BOOT\BOOTX64.EFI is presumably the Mageia Grub bootloader in disguise. Yes. So, to summarize, it looks like the installer didn't update entries in the UEFI Boot Manager configuration, which would explain why my machine has been unable to boot. I see that there is a kernel-4.9.16 in updates/testing. I will install it to see if it updates entries correctly. (In reply to Frédéric "LpSolit" Buclin from comment #9) > I see that there is a kernel-4.9.16 in updates/testing. Err... I meant 6.4.16! :) (In reply to Frédéric "LpSolit" Buclin from comment #9) > I see that there is a kernel-6.4.16 in updates/testing. I will install it to > see if it updates entries correctly. It didn't. The kernel should make no difference. The problem seems to be that the 1st install correctly put grubx64.efi in /boot/EFI/EFI/mageia at 04:21, but does not seem to have set the NVRAM accordingly. That does not have a Bootxxxx entry for the Mageia bootloader, which would be set to the start of BootOrder. Was there such an entry previously? Where has it gone? "Before the upgrade, the BIOS was listing both BOOTX64.EFI and mageia" agrees with the idea that the Mageia Bootxxxx entry disappeared during the upgrade. Depending on the EFI firmware, its boot menu might offer everything in NVRAM; looks like your case. The 2nd install explicitly saying "Install in EFI/BOOT" seems to have put the same bootloader as BOOT/BOOTX64.EFI (the default) at 04:32, with BootOrder set correspodingly, where the EFI firmware found it. One thing could matter here: it was an upgrade to a system which previously booted OK. That should have had a Bootxxxx entry for Mageia (8) as \EFI\MAGEIA\GRUBX64.EFI. If that bootloader had been left untouched, that would have caused grief as Martin suggested comment 3. It only needed to update the bootloader itself (and leave the Bootxxxx array & BootOrder unchanged) to work. @Martin? You can create with efibootmgr a Bootxxxx entry for \MAGEIA\GRUBX64.EFI, and change BootOrder to put it at the front. But the configuration you have now is satisfactory, so better to leave it alone. I think there is not enough before-&-after evidence of the upgrade, nor between the two upgrades you did, to say exactly what went wrong. And it is too painful to try to reproduce. Can we close this 'worksforme'? (In reply to Lewis Smith from comment #12) > I think there is not enough before-&-after evidence of the upgrade, nor > between the two upgrades you did, to say exactly what went wrong. And it is > too painful to try to reproduce. Yeah, I won't reinstall Mageia 9 now that everything is working again. Next upgrade will be when Mageia 10 is released. But the fact that mageia/grubx64.efi is not listed looks like a bug to me. It would be great to fix it before Mageia 10. > Can we close this 'worksforme'? Are you saying that in your comment 6, the installer correctly listed \EFI\MAGEIA\GRUBX64.EFI ? Or did it come from a previous install ? A few observations: 1. You mention you have installed all versions of Mageia on this machine, so presumably you switched from legacy boot to UEFI boot at some point (Mageia didn't support UEFI boot before Mageia 4). Do you remember at what point you made the change? 2. For the Mageia 8 GRUB image to have been present in \EFI\BOOT, you must either have chosen the option to install it there or manually copied it from \EFI\mageia. Do you remember which? 3. Some EFI BIOSs don't pay any attention to the EFI NVRAM variables and are hard-wired to either boot Windows or use the fallback in \EFI\BOOT. HP laptops were often like this. To check, run drakboot and reinstall GRUB in the default place (that shouldn't delete the copy in \BOOT\EFI), then check the system journal for drakboot and grub messages, and run efibootmgr to see if a Mageia entry has been added. Then reboot and run efibootmgr again. On my old HP laptop, the Mageia entry would get added but would be removed by the BIOS on the next reboot. (In reply to Martin Whitaker from comment #14) > A few observations: > > 1. You mention you have installed all versions of Mageia on this machine, so > presumably you switched from legacy boot to UEFI boot at some point (Mageia > didn't support UEFI boot before Mageia 4). Do you remember at what point you > made the change? Ah no, I was talking about the experience I have with Mageia (and before that, with Mandrake and Mandriva). I installed all versions of Mageia, but of course on different machines over the years. I bought my current machine (a PC with a MSI PRO Z690-A DDR4 motherboard + i7-12700 CPU) last year, so the first OS installed was Mageia 8. I always used UEFI on this machine. > 2. For the Mageia 8 GRUB image to have been present in \EFI\BOOT, you must > either have chosen the option to install it there or manually copied it from > \EFI\mageia. Do you remember which? Manual copy? no way! Did I choose the option to install it there? yes, that's very possible (I honestly don't remember). > 3. Some EFI BIOSs don't pay any attention to the EFI NVRAM variables and are > hard-wired to either boot Windows or use the fallback in \EFI\BOOT. HP > laptops were often like this. To check, run drakboot and reinstall GRUB in > the default place (that shouldn't delete the copy in \BOOT\EFI), then check > the system journal for drakboot and grub messages, and run efibootmgr to see > if a Mageia entry has been added. Then reboot and run efibootmgr again. On > my old HP laptop, the Mageia entry would get added but would be removed by > the BIOS on the next reboot. I ran drakboot and unchecked "install in /BOOT/EFI/". Now I get: $ efibootmgr BootCurrent: 0002 Timeout: 0 seconds BootOrder: 0000,0002,0001,0003,0004,0005 Boot0000* mageia HD(1,GPT,...,0x800,0x95822)/File(\EFI\mageia\grubx64.efi) Boot0001* UEFI: ATAPI iHAS124 F PciRoot(0x0)/Pci(0x17,0x0)/Sata(4,65535,0)/CDROM(1,0x21a62f,0x2000)0000424f Boot0002* UEFI OS HD(1,GPT,...,0x800,0x95822)/File(\EFI\BOOT\BOOTX64.EFI)0000424f Boot0003* UEFI:CD/DVD Drive BBS(129,,0x0) Boot0004* UEFI:Removable Device BBS(130,,0x0) Boot0005* UEFI:Network Device BBS(131,,0x0) I will now reboot my machine and will post another comment again. Created attachment 14065 [details]
Screenshot of the BIOS
The mageia boot option is back in the BIOS, see the screenshot, but it's listed as option #2, not #1. That's exactly what I had when I upgraded from Mageia 8 to 9. So if Mageia 8 installed /EFI/BOOT/BOOTX64.EFI and Mageia 9 installed /EFI/mageia/grubx64.efi only, then, from what I understand, the BIOS loaded the Mageia 8 BOOTX64.EFI.
Now:
$ efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000
Boot0000* mageia HD(1,GPT,...,0x800,0x95822)/File(\EFI\mageia\grubx64.efi)
Boot0002* UEFI OS HD(1,GPT,...,0x800,0x95822)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
All other options are gone. Oops!
Hum... I can read here and there that MSI is pretty well known to only rely on the default path to the bootloader, i.e. /EFI/BOOT/BOOTX64.EFI, and if this file is missing, then the MSI BIOS ignores other entries in the NVRAM. This would mean that I have been lucky when installing Mageia 8 last year, because I probably checked the "install in /BOOT/EFI/" checkbox. Let's close this bug as invalid, then. I'm really sorry for the noise. Status:
NEW =>
RESOLVED |
Created attachment 14059 [details] grub 2 error message I upgraded my machine from Mageia 8 to Mageia 9 using the Mageia-9-x86_64.iso classic installer. The upgrade went well, but my PC is now unable to boot, see the screenshot: Loading Linux 6.4.9-desktop-4.mga9... error: ../../grub-core/kern/dl.c:429:symbol `grub_stack_addr` not found. So I decided to do a clean install, but I got another error message, which I will attach in my next comment. So I'm back to Mageia 8 (fortunately I burnt the Mageia 8 ISO on a DVD before upgrading to Mageia 9)