I installed tumbleweed on a machine without an ACPI problem and the grub secureboot had no issues.
I installed tumbleweed on a machine with an ACPI problem using acpi=off and grub cannot create a secure boot the message follows
Execution of command “”/usr/sbin/shim-install",
“–config-file=/boot/grub2/grub.cfg”]]" failed.
Exit code: 5
Error output: Installing for x86_64-efi platform.
Installation finished. No error reported.
Could not prepare Boot variable: No such file or directory
The machine booted without secureboot so I updated the software hoping the file would be downloaded. That did not work.
Yast-bootstrap? still attempts to complete the grub installation and it still fails with the same message.
Is there a means to correct this problem an enable a secureboot?
This command should run without error. And it puts boot code into the EFI partition where most systems can use it. Whether your system can work that way, you won’t know until you try.
Respectfully, Suse installed thhe non-secureboot option into the boot partition and I can boot the installed openSuse Tumbleweed instance. I just cannot boot it with secure boot on.
I tried running yast-bootloader, it still did not find the file (I hope this did not mess your test up.)
I rebooted altering the bios to try a secure boot with the old opensuse entry --it still failed the red screen I think it said certificate error.
I am back to running without secure boot so nothing was damaged.
Thanks for trying.
I got some boot options from the ubuntu site. It may require multiple reinstallation attempts
They said to narrow down the acpi issue the following alternatives to acpi=off could possibly help find part of acpi that is failing. Could any of these help isolate the problem if I attempt to reinstall and one of these succeed in place of acpi=off. These may not be appropriate for openSUSE so I am asking.
That’s because it does not need to communicate with the BIOS/firmware.
Normally, UEFI booting for openSUSE installs boot files in “/boot/efi/EFI/opensuse”.
The command that I suggested doesn’t use that. Instead, it puts boot files in “/boot/efi/EFI/Boot”. That’s the default the firmware should use if there are no NVRAM entries. But I don’t know if there are NVRAM entries, and you probably cannot use “efibootmgr” to find out.
Not really. This is where firmware should look for bootloader on removable device. UEFI does not require firmware to automatically pick up these entries on non-removable disks. It is true that most implementations seem to do it anyway (usually this is what “boot from UEFI hard disk” or similar in BIOS boot menu refers to), but whether they are added automatically or not is vendor dependent.
But I don’t know if there are NVRAM entries, and you probably cannot use “efibootmgr” to find out.
You can. efibootmgr cannot create new entry because it expects certain information in /sys that is provided by ACPI and is not present. Listing entries involves simply reading /sys/firmware/efi/efivars and this works.
Further clarification. I believe the boots for these operating systems are on separate drives. I use the escape key to access linux (SSD SATA drive) when I want it. Windows I believe boots from the other (nvme) drive by default
from what you are indicating Boot0005 is probably blocking the alternate boot we installed from running. maybe even Boot0000.
This machine also does not power down – it hangs when powerdown is requested from linux.
Maybe it is time to remove linux from this box, if It’s acpi is not working correctly.
“Boot0005” probably boots “grubx64.efi” in “/boot/efi/EFI/opensuse”.
If you look in “/boot/efi/EFI/Boot”, there should be a “bootx64.efi”, “grub.efi”, “grub.cfg” and “MokManager.efi”.
Copy those to “/boot/efi/EFI/opensuse”, and then rename “bootx64.efi” to “shim.efi” in that same “opensuse” directory.
Then copy “shim.efi” to “bootx64.efi” and after that it should be able to secure-boot. But you may need to repeat these steps after any grub update or shim update.
The idea is that you need to be booting “shim.efi”. Since you seem to have problems installing it the right way, just make sure that the file you are booting is really “shim.efi” but with a different name.
“/boot/efi/EFI/Boot” had one additional file fallback.efi - I ignored it
I renamed files in “/boot/efi/EFI/opensuse”, there should be a “grub.efi”, “grub.cfg” and “MokManager.efi” AND shim.efi with appending .old on the end just in case.
I copied the 4 files from *.boot to *.opensuse
In opensuse
I renamed bootx64.efi to shim.efi
I copied shim.efi to shim (copy).efi and renamed it bootx64.efi
There were additional files in opensuse, I ignored them too
fwupdx64.efi, grubx64.efi
I rebooted the machine and enabled secure boot in the bios and got the red error screen again.
Turned secure boot off and no damage I can still boot without secure boot.
Since no one said not to I am going to run the initial phase of the install again using no acpi option the various acpi options noted above after I double check the ubuntu site to find out if I spelled them correctly (I am assuming these acpi settings are linux kernel configuration options). Without actually installing , just to see if I can get past the boot hang with any of them meaning I will see the installer windows. If so I will open a new task hopefully with more information as to which acpi options would permit me to attempt a install knowing more about what part of ACPI is causing the problem my machine actually has (I assume if i am successful that it would require one or possibly more of the acpi options to eliminate the ones causing the error) My order of attack will be to try single options if no success the double options then if necessary triple options, etc). At which point If I learn anything I will open a new issue focused on the specific ACPI issues identified.
Again I install nothing I will just be testing to see which if any of the acpi options other than acpi=off allows me to see the installer windows after booting the dvd.
Oops. My mistake. It needs to be renamed to “grubx64.efi”.
And yes, you can ignore “fwupdx64.efi”. As far as I know, that’s only used for installing firmware updates, and that probably doesn’t work on your system.