Today I updated Tumbleweed for the first time this year, to 2015-01-15. Standard procedure, sudo zypper ref and zypper dup; used TTY. Tumbleweed had been fine today before the update.
Now GRUB throws ”symbol grub_efi_allocate_fixed not found“. There is no way anymore for me to get out of GRUB and boot into Tumbleweed. I have Manjaro on the same machine, still booting fine from the same EFI partition and bootloader which Tumbleweed uses.
I should say that my machine (HP EliteBook 8560w from 2011) has an early UEFI implementation. It requires to have bootx64.efi to be present in the Microsoft default place, /boot/efi/EFI/BOOT/.
In addition, since an earlier update last year I found a fwupdx64.efi in the openSUSE Directory of the EFI partition. I didn‘t do anything with it.
I‘m somewhat lost and would like to ask for your help.
In detail: Booting from GRUB Menü unto Tumbleweed gets to the loading initial ramdisk, then throws the a.m. error and ”hit any key“, then into GRUB command mode.
I’m not sure what went wrong. I have not heard any other reports of this problem.
It seems that you got as far as grub, so this is probably not a UEFI firmware issue.
Are you using “btrfs”?
Since you are able to boot manjaro, you should be able to add a boot entry for openSUSE in your manjaro boot menu. Perhaps you will have to add manually.
If what you propose is good, then I think I should be able to point my UEFI to boot the original grubx64.efi in the openSUSE subdue of the EFI partition?
Unfortunately, I have to be patient until Monday at my computer.
In the meantime: Any other ideas and help? Thanks.
With “ext4”, you should not have problems booting via manjaro.
The default for openSUSE is to configure secure-boot support. You appear to not be using that. So I would suggest that you go into Yast bootloader, and uncheck the “secure-boot” support (if it is checked). That will leave one less thing to go wrong during booting.
No Secure Boot. That check mark in Yast Create Bootloader was not touched manually, AFAIK.
No serious error messages during zypper dup today as far as I could see in passing.
Following your info that the symbol in question was introduced on Dec 20, I have a hypothesis that Tumbleweed with today’s update wrote a new and different grubx64.efi to /boot/efi/EFI/openSUSE/. If that were true, then it would be different from the existing /boot/efi/EFI/BOOT/bootx64.efi, which is the only one my PC can boot from without manual intervention, and which comes from an update before December. Maybe such a scenario causes my current boot failure. It might be solved by booting into Manjaro and copying beE/openSUSE/grubx64.efi over to beE/BOOT/bootx64.efi. For the past two years or so I had been careful enough to always do such copying after a zypper dup whenever Tumbleweed showed a different time stamp for grubx64.efi. Maybe today was my unlucky day - I have neglected to check and copy grubx64.efi, since in the past the various grubx64.efi files had been identical most of the time.
But maybe this is not true, and another reason would need to be found. Maybe the grub config file would need to recreated. Maybe the initial ramdisk would need to be recreated. Maybe I would have to boot into Manjaro and give its grub menu an entry to boot Tumbleweed.
I will dig into this on Monday. Hope you both will be available for further help!
Sigh, all solved. The issue was exactly what I figured it to be following your helpful comments,
and
I had missed the one step after updating that is essential with my peculiar UEFI hard and firmware, i.e. copying /boot/efi/EFI/opensuse/grubx64.efi over to /boot/efi/EFI/BOOT/bootx64.efi whenever Tumbleweed changes its /boot/efi/EFI/opensuse/grubx64.efi (check its timestamp).
Lesson learnt! Always exert utmost diligence to do all steps when updating.
Now, three questions come to my mind:
(1) What does
actually mean? Where was it introduced?
(2) Until now, I thought all grubx64.efi’s were created equal (for the same GRUB version, and except for pointing to its OS-specific config file, but having the same executable EFI code), but I seem to be mistaken. So, what’s in a grubx64.efi file? What did change in Tumbleweed’s grubx64.efi between Dec 20 and Jan 15? Maybe you could give a short explanatory summary; of course I did already dig deeper into the literature, but will have to continue.
menuentry "Menüeinträge für Manjaro Linux" {
set bootdir='hd0,gpt2'
search --fs-uuid --set=bootdir a1b2c3d4-e5f6-a7b8-c9d0-a1b2d3e4f5g6
configfile (${bootdir})/boot/grub/grub.cfg
}
So there is only one grubx64.efi (aka bootx64.efi) in action, the Tumbleweed one. Manjaro’s /boot/efi/EFI/Manjaro/grubx64.efi - as as I understand it - is never used in my case. Correct??? Now, what would happen if Manjaro were to decide some day that its grubx64.efi shall be changed. Would it be possible that Tumbleweed’s grubx64.efi turns out to be incompatible with Manjaro’s? Would I be unable to boot Manjaro on that potential day? Similar to what happened to me within Tumbleweed between last December and the latest update 20190115.
Thanks a lot to both of you for your helpful comments, past, present and future!
When grub2 is update, it is reinstalled. But that reinstalls “/boot/efi/EFI/opensuse/grubx64.efi”. It won’t reinstall “/boot/efi/EFI/BOOT/bootx64.efi”, so it is up to you to keep that up to date.
(1) What does
actually mean? Where was it introduced?
I’m not up on the internals of grub2, but arvidjaar is. There was a recent update to grub2. If you check, you will find that “/boot/grub2/x86_64-efi” has been recently reinstalled (has relatively new dates). And the “grubx64.efi” needs to match the code in that directory. In fact “grubx64.efi” is really the file “core.efi” from that directory. So you had a mismatch between your “bootx64.efi” and code that it calls (the grub2 modules).
Thank you for taking the time to explain. Understood. In consequence, my fears that the Tumbleweed grubx64.efi might some day be unable to boot Manjaro just is irrelevant.
You just need to keep a bootable CD or USB around, so that you can get in and fix things if they break. And, after this experience, you have a pretty good idea on what can break and how to fix it.
I actually try to keep track. After a Tumbleweed update, I look at “/boot/efi/EFI/opensuse” to see if any files there were updated. Most of the time, “grubx64.efi” does not change. But occasionally it does change, and that happened in the most recent update.
This is function that was added to grub in patch dated in package changelog 2018-12-20. In this case function definition gets compiled into core.efi == grubx64.efi. You had old version of this file which did not contain this definition. Not every grub module needs this function which explains why grub was able to launch one menu entry and failed with another.
if there is enough systems that require this workaround it would be valid feature request. Actually installation is done by simple shell script located under /usr/lib/bootloader; copy directory under another name, adjust script, set LOADER_TYPE to this new directory name. It will be used from now when bootloader needs to be reconfigured or reinstalled. The only thing that probably will be confused is YaST - I am not sure whether YaST takes list of available loaders from this directory or hard codes it … yes, there is fixed list.
Thanks for your help and thinking further. I don‘t think such a peculiarity of UEFI machines would require automation, though. If anything, then zypper or that installer script could just output a warning like ”Reinstalled GRUB2. Please ensure to take care of all necessary post-install adjustments“.
I used zypper dup from Leap:15.0 to update to the same Tumbleweed snapshot on an HP pavilion laptop born mid 2018. I resized the windows partition and installed Leap:15.0 on it. I set it up to boot from grub, which I use to boot windows 10 (mainly for netflix download and play later) the boot system has survived monthly windows updates without a problem.
The first reboot after zypper dup to Tumbleweed failed with “failed to find grub_efi_allocate_fixed” I fixed this by booting installed system from an installation usb stick and running yast2 bootloader but firstly after running yast bootloader and changing the boot menu timeout fro 9 to 8 it went wrong again, fixed it with boot installed system then running yast bootloader again. After a Windows 10 driver update - same problem again. This is getting very irritating.
The point is that this is a bug and if Leap:15.0 has no problem then neither should Tumbleweed.
Please add yourselves to https://bugzilla.novell.com/show_bug.cgi?id=1123245
I agree with arvidjaar, that your problem is not related to this thread.
I’ll read through the bug report later today. I don’t have a comment at present, except that I am not having any boot problems with Tumbleweed or with Leap 15.0 (and this is on UEFI systems).
Well… also having an issue since latest grub2 update. Leap 43.2 - not tumbleweed. My system randomly restarts a few times but eventually boots to “Emergency Mode”. Allows me a root login to a full screen text CLI with no network connection. Most restarts occur when closing firefox or a tab in firefox. Eventually I end up back to emergency mode. I can restore a back up image quickly and all is fine until I let the updater do its magic.