My openSUSE /boot/efi is likely get deleted by me or a fresh installed ubuntu 18.04 or just ge hidden, I couldn’t find openSUSE in UEFI and Ubuntu boot menu again. I made a bootable USB with openSUSE-Leap-15.1-NET-x86_64.iso, from it’s boot I choose enter “boot from harddisk”, then it led me to the openSUSE in my harddisk. I want to know why and it’s a secure boot?
It is hard to know what you did there.
Yes, if you delete the ESP partition, you will have problems. But a Ubuntu install should not do that.
Another possibility, is that you have a fussy BIOS that cleans up NVRAM by deleting boot entries that it decides are not needed.
I’m not sure, but I don’t think “boot from hard disk” with the installer would actually work on a UEFI system if the ESP had been deleted.
You can probably use Yast bootloader to reinstall booting for your system. But if you have a fussy BIOS, that might remove the Ubuntu boot entry.
May the ESP didn’t get deleted, I don’t know and forget the detail, but why the openSUSE menu is hidden from BIOS if ESP didn’t get deleted , while the bootable USB can boot the openSUSE?
The BIOS sees the NVRAM entries. Here “NVRAM” is short for “non volatile ram”. NVRAM is like a small flash drive built into your hardware.
The command
/usr/sbin/efibootmgr -v
should list the boot entries that are in NVRAM.
If the NVRAM entry is gone, your BIOS won’t boot it.
The BIOS does know about a USB and how to boot that without an NVRAM entry. The boot code is in “\EFI\boot” in the EFI directory of the USB. When you boot from the USB, and choose the “boot from disk” entry, it look inside the ESP and grub runs the file “\EFI\opensuse\grub.efi” that is in the ESP. So that file must exist if you can boot with the USB, but it seems that the NVRAM entry has gone missing.
Yes it seems like it, awesome answer! And I also want to know that the bootloader in the USB same with the bootloader in NVRAM which in the hard disk? Upgrading openSUSE doesn’t change the bootloader in NVRAM? And secure boot that the bootloader verified by UEFI firmware built-in CA?
The bootloader in the USB (assuming the installer USB) includes secure-boot support. So the bootloader uses files
- shim.efi (but actually named “bootx64.efi” on the USB, because that’s what the BIOS will use)
- grub.efi
- grub.cfg
The bootloader in NVRAM is really just the path to the bootloader in your ESP. And if secure-boot support is included (that’s the default), then it uses “shim.efi” which in turn uses “grub.efi” and “grub.cfg”. But the content of “grub.cfg” will be different between the USB and what’s in your ESP.
Upgrading openSUSE doesn’t change the bootloader in NVRAM?
Upgrading will reinstall the bootloader. But the NVRAM entry will probably finish up the same as before. The files “shim.efi” and “grub.efi” may be updated versions. And “grub.cfg” will have been update to now contain the UUID of the partition containing “/boot” so that grub can find its menu in “/boot/grub2”.
And secure boot that the bootloader verified by UEFI firmware built-in CA?
The way this normally works, is that “shim.efi” has been signed by Microsoft, and your UEFI firmware is set to verify Microsoft signatures. In turn, “shim.efi” contains the openSUSE CA certificate. And that openCA certificate is used to verify the signature of “grub.efi” and the signature on the kernel that you are loading.
Hi, I like to ask little more. As the first stage bootloader in the bootable USB has never updated, how long can it lasts to boot my openSUSE 15.1 on HDD? If the time is too short, how can I add the openSUSE entry to NVRAM?
As far as I know, it should last until the end-of-life of Leap 15.1.
The files that matter are “shim.efi” and “grub.efi” in the EFI partition of that USB. And you probably could manually update them if you wanted to, by mounting that partition and manually copying the files. However, “shim.efi” has never been updated since Leap 15.1 was released, and I think “grub.efi” was only updated once (in June).
Can you provide the output from:
/usr/sbin/efibootmgr -v
so that we can see what is currently in NVRAM.
minepc@alphaz:~$ efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002
Boot0001* ubuntu HD(12,GPT,xxxxxxx-xxxx-xxxx-xxxx-xxxx,xxxxxxxx,xxxxxx)/File(\EFI\Ubuntu\grubx64.efi)
Boot0002* UEFI OS HD(12,GPT,xxxxxxx-xxxx-xxxx-xxxx-xxxx,xxxxxxxx,xxxxxx)/File(\EFI\BOOT\BOOTX64.EFI)
So far, so good. You have an NVRAM entry for “Ubuntu”.
When I install Ubuntu, I usually get two NVRAM entries (one for secure-boot and the other without secure-boot). You only have the one without secure-boot.
Can you show the output from:
ls /boot/efi/EFI/opensuse
I’m suspecting that you have fussy UEFI firmware that deletes most of the NVRAM entries. So you may need to manage with only one entry. You could either use the Ubuntu entry to boot openSUSE or the openSUSE entry to boot Ubuntu. Maybe it is best to set it up so that either way works. Then, whichever NVRAM entry sticks around can be used for either system.
Is openSUSE still secure boot?
sudo ls /boot/efi/EFI/opensuse
boot.csv grub.cfg grub.efi grubx64.efi MokManager.efi shim.efi
Yes, openSUSE supports secure-boot. And you apparently did install support for secure-boot, which still works even if secure-boot is disabled.
You should be able to get a boot entry for openSUSE as follows:
Yast –> System –> Boot Loader
The first screen should show that you are using “GRUB2 for EFI”, and the box for secure-boot support should be checked. Best to not change any of that.
Click on the “Bootloader Options” tab. And then change something. I usually change the timeout either increase by 1 second or decrease by 1 second. If you don’t change anything, Yast won’t do anything. But if you change something, then Yast will reinstall the bootloader.
What will probably happen, is that now you will get the openSUSE boot menu, but you will stop getting the Ubuntu boot menu. But there should be an entry to boot Ubuntu from the openSUSE boot menu.
Give that a try, and tell us what happens.
Thank you more than you can think!