http://bugzilla.opensuse.org/show_bug.cgi?id=1123245 http://bugzilla.opensuse.org/show_bug.cgi?id=1123245#c11 --- Comment #11 from Dave Plater <davejplater@gmail.com> --- (In reply to Neil Rickert from comment #10)
This is confusing, because I do not see any "secure boot" entry in the output that you show in comment #3 above.
That would be Boot0002* judging by the order, Boot0000* is the default boot.
It is also unclear what you mean by "secure boot is disabled". You can disable secure-boot in your BIOS (or UEFI firmware). And that should not have any effect on which boot entries are there. You can also disable in Yast, which probably does affect your boot entries.
Leap:42.3 installation originally enabled tpm and secure boot by default. When secure boot is enabled in yast the third bios boot entry appears. If I select it in the bios boot menu it boots. The default bios boot item is the problem one.
I would suggest leaving secure boot enabled in Yast, but disabled in your BIOS. That's what will probably work best for you.
Your problem appears to be that you are using a stale boot entry with your UEFI firmware, which no longer matches the installed grub2-efi. When you use secure-boot (as set in Yast bootloader), then the code used for the boot entry is self-contained and will usually work even when it does not match the installed "grub2-efi".
What I still don't understand is why Leap had no problems, I had to run a 4.17 kernel for the wifi, but Tumbleweed just can't get it right without intervention
The more complete solution would be to update "grubx64.efi" in your EFI partition, so that it is identical to "/boot/grub2/x86_64-efi/core.efi". And since you have two EFI partitions, with a "grubx64.efi" in both partitions, you should update both of those. And, to be clear, those files will be in a directory with path "EFI/opensuse" (relative to the top of the EFI partition). If the same filename is found in other directories, that's probably from a different linux version.
"Different linux version"? I've only openSUSE and windows 10. I can possibly fix my problem (If it survives kernel updates) by using Boot0002* as the default entry but that doesn't fix the bug. What exactly causes: "failed to find grub_efi_allocate_fixed"? Where can I find documentation on my boot process? -- You are receiving this mail because: You are on the CC list for the bug.