Today's TW zypper dup -l wipes grub and boots to white screen????

Folks:

A few days back running a zypper in Leap 15.3 on a laptop did a similar problem of wiping grub and booting into the whiteness, this morning in my main channel TW distro on my desktop brought same problem after a “546 package” upgrade . . . possibly a kernel upgrade so it requested reboot, TW should have been top listing on grub . . . instead it went into the infinite whiteness???

Didn’t have time to mess with the “shim” file renaming suggested for the Leap 15.3 problem, even less time for it over in my main squeeze desktop, since there are five other linux distros to choose from . . . except now “grub” is gone . . . I had to revert to OSX to get some tasks taken care of . . . .

Seems like the last 5 months or so, the zypper updates have been a “wild card” on the results, rather than “business as usual, nice and tidy.” Why is this happening, seemingly over and over stuff is breaking in upgrades rather than . . . um . . . “upgrading”??? >:(:’(:o:(

Hi
No issues like that here with Tumbleweed and GNOME… graphics card?

@malcolmlewis:

Thanks for the reply . . . well, this is “multi-boot” but on this '12 Mac Pro machine I have nvidia GTX 780 card, and on my olden '09 MacBookPro it also has nvidia graphics card. The other day @nrickert diagnosed the issue having to do with the “shim” file that got renamed or messed up in the latest upgrades, for the EFI boot arena . . . I’m assuming that today’s problem is due to the same problem. It’s a little bit beyond my lowly pay grade to try to find those files in the installer media and then move them into the present install, and then rename them . . . or what-have-you.

Other posters had the same issue back a few days ago in this sub-forum, and I added myself into one thread, I was “hoping” that the TW files would have adjusted themselves by now, but seemingly not. I was also hoping that running the “os-prober” or running the opensuse version of “grub-update” would fix the problem??

My Supergrub2 disk is buried away in the laptop with the Leap 15.3 broke down system, so I’ll have to dig it out and try to get back into TW . . . later in the day . . . . : - (

Hi
I’m assuming it’s hybrid (intel/nvidia) or pure nvidia? Proprietary driver or oss?

@malcolmlewis:

In the desktop it’s a flashed card to run on Mac, pure nvidia . . . using “default” as the driver. The proprietary driver isn’t really being upgraded for to quote their linux tech guy, “that old card” . . . one of the gents here suggested going “default” and it’s been working fine.

In the meanwhile, I had fished the SG2 disk out and managed to boot into TW and I both ran Yast bootloader, followed by the “grub2-mkconfig xxxxxxxx” command, which in the past has restored grub function to show the 5 or 6 linux options . . . this time, no, that didn’t fix it . . . rebooted into the white, O the whiteness.

Back over in OSX to post this reply.

Guyz??

My question is, will there be a “fix” for this issue coming down the tubes ASAP?

My feeling is that if I wasn’t “experimenting” with my system, other than running TW, and this problem showed up in two different computers after running “zypper” . . . that there would be a “solution” provided by those folks who created the problem, rather than taking personal time to try to figure it out . . . only to have it busted up again in a future zypper dup???

The problem with “grub” has been floating around in ubuntu for at least a year . . . has that approach drifted over into OpenSUSE, such that there are problems with “EFI” and multi-boot coordination???

Hi
Check the efi entries via efibootmgr at boot add the grub option nomodeset (press e at boot screen and add at the end of the linuxefi line), see if that gets past the white screen. I think I struck something like that way back on my MacBook 2007, but that has all intel…

@malcolmlewis:

Thanks for the hints . . . the problem was that there was no “grub” window to press “e” in. Now, I’ve fiddled with SG2 “enable all disk drivers experimental” and out of the 5 or 6 options in linux to choose from, it boots only Linux Mint . . . . I’m not sure if this is relating to video driver stuff, but some of the “efi” or “EFI” files have been messed with? Because in SG2 there are a lot of options showing for various “efi_64” . . . but they don’t don’t anything. So far only the “vmlinuz” options seem to get me into a system . . . now I’m over in Gecko, which is “next door” to TW . . . .

But, seemingly the “Boot order” has been adjusted in the “efibootmgr” listings, because before yesterday TW was the number one slot, TW was the “controller” . . . but it seems to have relinquished it’s position??? I believe that 0000 is Linux Mint . . . but again, there is no “grub menu” window that opens on cold boot . . . I believe it’s going to a “grub error” TTY and then it auto-boots into LM; previously TW did a good job of handling grub functions, now it’s dropped the grub ball . . . . If I want to get into something other than LM I have to use SG2 disk and find a “vmlinuz” option.

sudo efibootmgr
[sudo] password for root: 
BootCurrent: 0000
BootOrder: 0010,0008,0000,000F,000A,0006,0005,0004,0007,000E,000C,000B,0009,0080,000D,0003,0001,0002
Boot0000* ubuntu
Boot0001* opensusetw
Boot0002* grub
Boot0003* lubuntu1910
Boot0004* grub-secureboot
Boot0005* opensuse-secureboot
Boot0006* tumbleweed-secureboot
Boot0007* opensusetw-secureboot
Boot0008* ubuntu
Boot0009* ubuntu
Boot000A* opensusetw-secureboot
Boot000B* opensuse-secureboot
Boot000C* tumbleweed-secureboot
Boot000D* Debian
Boot000E* debian
Boot000F* ubuntu
Boot0010* ubuntu
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082* 
BootFFFF* 


Hi
If you use the -v option with efibootmgr it will show where things are pointing too as well and check files exists in those locations.

If you hold the command key down at the boot sound, you should get to the OSx boot menu and be able to select the efi file to boot from for the EFI folder.

@malcolmlewis:

I ran the -v option and it shows a bunch of data, seemingly hooking up to “shim” and “EFI” folders . . . but that is like “Greek” to me.

As far as the “command” key, I believe you are meaning the “alt/option” key to bring up OSX boot manager . . . previously to this latest problem TW set up the grub menu to open on cold boot . . . but as far as the “EFI boot” disk goes, OSX doesn’t play well with others so awhile back the four “EFI boot” disks for the 4 drives available . . . got “worked over” by OSX at some point, now only one of them works to boot into . . . LM.

I’ve been trying to do this the “easy way” by running “grub2-mkconfig” just now in Gecko, but something tells me that isn’t going to “fix it” . . . . We’ll see on reboot . . . gotta do some real work for a bit . . . . In the past when OSX busted up the grub menu I had to chroot over into TW to get it to run os-prober, and that seemed to work . . . so far running Yast and os-prober while booted in TW or Gecko has not fixed this “shim” problem . . . .

Hi
Does the system support secure boot? I would select the grubx64.efi for boot… AFAIK efi boot and osX filesystem will not boot due to the filesystem, or maybe that’s because I have a really old MacBook system…

@ML:

I believe the system supports secure boot, but I don’t think I did anything to set that up in any of my installs.

The way it was in my desktop, '12 MPro . . . if I wanted OSX I held to alt/option key, but TW had it set up so that cold boot went to grub menu . . . . Now that is gone. I tried to chroot over into TW and run os-prober, which worked in the past to repair grub, but this time there was some I/O error?? possibly because the SG2 disk was in “sr0”??? So that failed to repair anything.

I have tried various options to boot into the other systems, but so far only the “vmlinuz” options work, have to sort of get from “sdb” to “gpt” definitions. Now I got into Manjaro, but when I tried to boot “Manjaro” via SG2 disk-- it errors out.

I guess at some point I’m going to have to look into the “shim” stuff, but other fish to fry now . . . PITA. Majorly.

et al:

I’ve been trying to get some console commands to run to get the “shim” files re-set in the operating system, as per @nrickert post in another thread, but so far the precise commands haven’t been posted to try to get the fix in for grub menu??

I added my issues into two bug reports:

https://bugzilla.opensuse.org/show_bug.cgi?id=1185601

I’m not sure what you are trying to do.

To just install shim into the EFI partition, you can use:

shim-install

To see other options, try:

shim-install --help

If you want to install without using NVRAM, then:

shim-install --removable --no-nvram

which will put it in “/boot/efi/EFI/boot” with name “bootx64.efi” and will install other relevant files to the same place.

Note that all commands mention probably need to be run by root.

@nrickert says in “15.3 won’t boot after zypper dup -l” thread: 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.

@nrickert:

I was referring to that post in another thread, which I had this problem happen in my laptop edition with 15.3, and then on my desktop running TW . . . question is how to restore grub menu function to both systems so that not only getting into TW, but the other 5 distros might be achieved. The hints above are not quite “step by step” or precise commands to run, for me to figure it out. Also, although both of my computers are using EFI boot, still not super clear on what “NVRAM” is and/or whether or not I “have it installed”??? I ran a custom install in both cases to install into pre-made “/” and “/home” partitions, and flagged the EFI partition in the disk as “/boot/efi” . . . . Everything was working fine until after running zypper dup -l in both cases, then on restart, no grub menu, just into the white.

I chrooted over into TW system and ran os-prober and ran the grub2-mkconfig command by booting up in SG2 disk, and I got out of the white and into just one of the distros . . . ubuntu-based Linux Mint will boot if I cold boot the computer, but there should be the grub menu and 6 systems?? to choose from. efibootmgr “sees” all of the systems as “there” but grub menu isn’t showing up. So, I don’t know if this relates to your "copy/paste the shim file and change it’s name . . . " directions . . . the “how to” on doing that is just a bit “grey” for me.

NVRAM is part of the harware for an EFI system. It’s like a small flash memory block, where boot settings can be saved. If you have an EFI system, then you have NVRAM. Whether it is working properly, is a different question.

As best I recall, the earlier thread seemed to be about NVRAM not remembering the boot settings. So I described how to manage without NVRAM. The EFI system is supposed to check for the file “bootx64.efi” in “\EFI\boot” (relative to the EFI partition), and boot that if there isn’t any NVRAM entry. The last command that I gave in my previous reply (to this thread) would set it up for booting that way.

@nrickert:

OK, thanks for the reply, so in the recent dup -l something about “shim” was messed up, such that the grub menu was removed or not found, so simply running the last command

shim-install --removable --no-nvram

would be the simplest way to fix the “failure for grub menu to show options or anything that boots” problem?? rather than the idea of copying files from an install disk into one of the /efi/ directories as you described to “peder” which seemed more complicated???

I don’t really know what is the actual problem. So this is a workaround rather than a fix. And yes, doing it that way from the command line might be easier.

No such problems encountered here. Business as usual since 2016. Host erlangen is multi booting several Linux systems as well as Windows 10:

**erlangen:~ #** efibootmgr  
BootCurrent: 0007 
Timeout: 1 seconds 
BootOrder: 0007,0000,0001,0002,0003,0004,0005,0006,0008,000B,0009,000A 
Boot0000* fedora
Boot0001* leap-15.2 
Boot0002* opensuse 
Boot0003* Windows Boot Manager 
Boot0004* tumbleweed-sdc5 
Boot0005* arch 
Boot0006* manjaro 
Boot0007* tumbleweed-nvme0n1p3 
Boot0008* ubuntu 
Boot0009* UEFI: IP4 Intel(R) Ethernet Connection (H) I219-V 
Boot000A* UEFI: IP6 Intel(R) Ethernet Connection (H) I219-V 
Boot000B* ubuntu 
erlangen:~ #

You may want to delete unneeded features, such as Compatibility Support Module, Secure Boot and some more. Keeping your list of repos tidy helps a lot:

**erlangen:~ #** zypper lr -uEP 
#  | Alias               | Name                                                                 | Enabled | GPG Check | Refresh | Priority | URI 
---+---------------------+----------------------------------------------------------------------+---------+-----------+---------+----------+--------------------------------------------------------------------------- 
 4 | KDE_Extra           | Additional packages maintained by the KDE team (openSUSE_Tumbleweed) | Yes     | (r ) Yes  | Yes     |   90     | https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ 
 5 | Packman             | Packman                                                              | Yes     | (r ) Yes  | Yes     |   90     | http://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/ 
13 | openSUSE-20191106-0 | openSUSE-Tumbleweed-Oss                                              | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/tumbleweed/repo/oss/ 
18 | repo-non-oss        | openSUSE-Tumbleweed-Non-Oss                                          | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/tumbleweed/repo/non-oss/ 
20 | repo-update         | openSUSE-Tumbleweed-Update                                           | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/update/tumbleweed/ 
 3 | BellSoft            | BellSoft Repository                                                  | Yes     | ( p) Yes  | Yes     |  100     | http://yum.bell-sw.com/ 
 7 | chrome              | chrome                                                               | Yes     | (r ) Yes  | Yes     |  100     | http://dl.google.com/linux/chrome/rpm/stable/x86_64 
11 | jalbum              | jalbum                                                               | Yes     | (  ) No   | Yes     |  100     | http://jalbum.net/download/software/yumrepo/ 
12 | myrepo              | myrepo                                                               | Yes     | (  ) No   | Yes     |  100     | dir:/home/karl/Downloads/myrepo 
**erlangen:~ #**

Check your system for orphaned and unneeded packages. Delete them using ‘zypper remove --clean-deps’ unless you definitely know you need them.

**erlangen:~ #** zypper packages  --orphaned --unneeded              
Loading repository data... 
Reading installed packages... 
S  | Repository | Name                           | Version          | Arch 
---+------------+--------------------------------+------------------+------- 
i+ | @System    | boost-license1_66_0            | 1.66.0-lp151.4.5 | noarch 
i+ | @System    | ctags                          | 5.8-9.13         | x86_64 
i+ | @System    | hd-idle                        | 1.05-1.29        | x86_64 
i+ | @System    | hll2350dwpdrv                  | 4.0.0-1          | i386 
i+ | @System    | libboost_filesystem1_66_0      | 1.66.0-lp151.4.5 | x86_64 
i+ | @System    | libboost_program_options1_66_0 | 1.66.0-lp151.4.5 | x86_64 
i+ | @System    | libboost_system1_66_0          | 1.66.0-lp151.4.5 | x86_64 
i+ | @System    | libdvdcss2                     | 1.4.2-1.1        | x86_64 
i+ | @System    | libroutino0                    | 3.1.1-1.81       | x86_64 
i+ | @System    | mfc255cwcupswrapper            | 1.1.3-1          | i386 
i+ | @System    | mfc255cwlpr                    | 1.1.3-1          | i386 
i+ | @System    | qmapshack                      | 1.15.2-2.9       | x86_64 
i+ | @System    | routino                        | 3.1.1-1.81       | x86_64 
i+ | @System    | stacer                         | 1.1.0-1          | x86_64 
**erlangen:~ #**