15.3 Beta doesn't boot after this weeks update


I installed Leap 15.3 Beta about 3 months ago and it has worked fine through 2-3 updates.
This weeks update, however, stopped my PC from booting at all.

I tried a reinstall using the latest net-boot image and got the same problem; after the install is finished and I reboot it never even get to the Grub boot menu.

I’ve booted into the Rescue system on the installer USB and have reinstalled grub2 on /dev/sda but that didn’t help.

I have a 100MB EFI partition on /dev/sda1 and /dev/sdb2 is a LVM PV with a 300MB ext4 LV for /boot , a 300MB LV for swap and a 10 GB XFS LV for /

Any ideas?
It seems the latest batch of updates is buggy in some way.

I have not been having the problems that you describe.

If you are not even getting to grub, then this suggests a BIOS problem or a bad install of booting.

Have you tried booting the install media, and then taking the menu option to boot from hard drive?

I don’t think it’s a BIOS problem; at least not on its own, since it’s been working fine for the last couple of updates.

I tried reinstalling using the default EFI and BtrFS disk layout, in case the latest Grub had some LVM-bug, but got the exact same result.

Booting the install media and then opting to boot from the drive works.

It’s not a hard drive problem either since I did the fresh installs on a replacement drive.

I’ll try moving the hard drive to another PC of the same model and see if that works.

So you can at least use that to get into your system.

There’s a bug showing up for Leap 15.2 that affects a few people, but does not affect me. It seems that the new “shim.efi” does not work with some BIOS. So I’m wondering whether that could also be what you are seeing.

You might want to check what’s in “/boot/efi/EFI/opensuse”. Possibly consider making a backup copy of “shim.efi” (just give it a different name in the same directory). And then try copying the “shim.efi” from install media to replace the one that is in “/boot/efi/EFI/opensuse”. Except the file is not called “shim.efi” on the install media. Instead, it is called “bootx64.efi”. If you are using a USB for installing, look at the “EFI” partition on that USB, and then in the directory “/EFI/boot” in that partition (but the capitalization of “boot” might be different). If your installer is a DVD, then look inside a directory named “EFI” at the top level of that DVD, for the same thing.

That you can boot with install media, and then boot hard drive, suggests that it works with the “shim.efi” from the install media. But that’s not the only possibility. Booting your system directly depends on what in NVRAM (maintained by your BIOS), while booting the install media does not depend on that.

shim.efi on the PC and bootx64.efi on the USB had the exact same MD5-sum but I did try lots of variants of renaming the .efi files in /boot/efi/EFI/opensuse and mucking around with various efibootmgr commands.

The only thing that worked was running efibootmgr -c -L openSuse -d /dev/sda -p 2 -l \EFI\opensuse\shim.efi
But that only worked for the next reboot. The subsequent reboot hung again.

My current suspicion is that the NVRAM in my PC has gone NVROM and that it can’t save the efi boot order.
It doesn’t explain why the efibootmgr trick works one time but it’s the best theory I have.

I’ve found others with similar problems, like

grub2-install writes to efi/NVRAM and it’s possible that it worked for my previous openSuse installs and the first 2-3 15.3 updates, but eventually failed for this one.

After spending way too many hours fighting this I gave up, set my PC to BIOS mode and reinstalled.

Yes, I guess that’s possible.

After spending way too many hours fighting this I gave up, set my PC to BIOS mode and reinstalled.

That’s one way of solving the problem.

Another option would have been to copy the files in “/boot/efi/EFI/opensuse” to “/boot/efi/EFI/boot”, and then rename the “shim.efi” there to “bootx64.efi”. It should be able to boot that way without any NVRAM entry (that’s how an install USB works).

I am not suggesting you change to that now.

If you have installed many OS be sure to clean up NVRAM and EFI boot partition. Install new ir different OS leave cruft behind in those locations. NVRAM has limits but what they are depends on the hardware and UEFI version.

The “reinstall” was to a new drive so I’ll try plugging in the old one and report back whether it works or not.

et al:

Just stopping by to report what seems like the same issue in my edition of 15.3 Beta, just ran a roughly 386 package upgrade via TTY and on reboot it went to white-ish screen, no grub menu. Shut down and rebooted a couple times, same thing. I have a triple boot situation on this '09 MacBookPro, when I boot the OSX boot manager I selected “EFI boot” and the black grub window loads with a “MOKlist error”??? all I could do is “reboot” out of it . . . back into the white-ishness.

I’m typing this in the OSX partition . . . seems like the only way to “fix” this is re-install . . . somewhat “loathe” to spend that time if the problem will remain as it has for “Peder” . . . . Don’t have to read the details of this post, just reporting that essentially GUI is wiped.

Is there a “recovery” app on the Leap 15.3 netinstaller?? If I could boot that and get the system to boot or get to a TTY to be able to zypper the next level of upgrades that would be a time saver on this problem . . . . : - 0

The NET installer should have a boot menu entry to boot from hard drive. You can check whether that works for you.

Could be this issue: https://github.com/rhboot/shim/pull/364

Computers are complex and users tend to fix problems by adding more complexity which makes troubleshooting even more difficult. When in trouble always try to delete everything you know you don’t need, such as secure boot, CSM, nonstandard repos and many more. Anything can happen. Recent upgrades to Tumbleweed seemed to break device notifier. Further investigation showed that the USB cable connecting the front panel to the main board went bad.

When working with a beta system always install another system known good. This will chop off a few GB from your disk, but furthers troubleshooting.


Thanks for that reply, I’ll check it later on today . . . .


I can’t tell if that data relates to my case or not . . . it looks “French” to me . . . .

In my case I tried to use the 15.3 install medium to first run “rescue” but that wouldn’t accept my login name and password . . . then I tried “upgrade” try to get the GUI to boot, but that needed a download . . . but I’m running a triple boot situation.

So, finally I remembered that my ancient '09 MBP has an actual Optical drive, so I booted my DVD of SuperGrub2 and picked the most recent “vmlinuz” option and got into the system . . . I dropped into a TTY and tried to run a zypper, but zypper said “nothing to do” . . . .

I’m assuming that @nrickert’s suggestions to copy the shim file over to the shim file would prolly “be the fix” . . . might be beyond my pay grade . . . . I was hoping that a fix for this issue would show up in an update, since <burp> something got “messed up” in the EFI boot realm . . . ??? I might “wait” a bit for that to happen . . . . >:(:cry:

Yes, copying all the files from /boot/efi/EFI/opensuse to /boot/efi/EFI/boot and renaming shim.efi to bootx64.efi made it boot in UEFI/SB mode.

I just had a similar problem with my file server, running Leap 15.2. After a regular update (including a kernel), I rebooted to have it drop into the EFI shell.

So, I hooked up my USB DVD player and tried to boot off the installation DVD. That took a few tries, including messing with the boot device sequence in the BIOS. Once booted off the DVD, I unlocked the encrypted partitions, the headed to a shell. Clearly my hardware was all fine.

Using some of the information here, I got it to boot again. The two most useful commands were “efibootmgr -v” to show what’s what, and then “efibootmgr --create” to add a new entry. For some reason, the update blew away the openSUSE entry from the NVRAM EFI list. I had to add it again.

After re-adding the openSUSE entry in the EFI boot device list, I had to go into the BIOS and re-add it at the top of the boot device sequence list.

Maybe this will help.

This problem has also hit me in my TW distro . . . @peder did you just run

sudo cp /boot/efi/EFI/opensuse   /boot/efi/EFI/boot

while booted in OpenSUSE and then navi into /boot/efi/EFI/boot directory and rename the files?? Or was this something where the install media has to be plugged in and you navi’d around to make copies and move them into the filesystem . . . and then rename them??


Thanks for sharing your experience . . . I spent some time on this problem this morning, I can boot an install using the SuperGrub2 disk, but so far trying to “grub2-mkconfig” is not fixing the problem. I got the hint to run efibootmgr -v . . . which didn’t exactly clear things up for me because I have a multi-boot situation going, but all of the installs were listed there, it’s just that Linux Mint is now in the “first boot” position . . . and these days ubuntu is only booting itself . . . . I need to get TW back in the top position, but will that “–create” option let me move the 4 digit numbers around?? So far grub-update in LM and Manjaro, finds and lists all of the distros, but grub menu isn’t showing up, grub is “busted down by the side of the road,”

The boot order is listed at the top of the efibootmgr output run man efibootmgr to get instructions on changing order. The list itself does not define the boot order


OK, thanks for stopping by, “read the man pages” . . . sounds like sage advice that I may check into. However, the issue isn’t in getting one system to boot out of the few that I have, but . . . to get the grub menu first to show up at all . . . and then to have it be operational. In my case in two different computers, blithely running zypper after using grub menu to select OpenSUSE options to then run a “ref&& dup” resulted in the wiping of the grub menu or anything.

Messing around with various methods of “grub2-mkconfig” have brought back the single system that is at the top of efibootmgr list . . . but, that isn’t “the problem solved.”