Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

English Install/Boot/Login
1

Gents:

Posted the beginnings of my recent problems with a fresh install of TW in another thread, but since then I downloaded another snap of TW, cloned it to usb drive and selected “upgrade” and the installer ran through the 160 MB of upgrades over the 11/1 snap to upgrade it to the 11/7 snap . . . .

Both times when the installer finished the install/upgrade the system rebooted right back into the TW install and everything worked in the GUI . . . this is in a '12 MacPro with 3 internal drives and 4 versions of OSX and 4 other versions of linux to choose from . . . the installer finds it way back to “sdb8 opensuse tumbleweed” and I can rifle around in the GUI, open apps . . . run zypper, etc. After the first install of the 11/1 snap I went into Yast and added the MATE pattern.

However, on cold boot and selecting the “EFI boot” disk which opens to Grub, when I select “TW” the screen immediately switching to variations of “crash” with errors like “efi not found” and other variations mentioning “kernel panic” or “trace dump” . . . I’ve tried the “recovery” options in Grub, same diff . . . .

From the 11/7 snap flash drive I can pick “boot from hard drive” and I can select “sdb8” and it goes to a command line that runs through a bunch of lines each saying “OK” . . . it has gotten down to something like “starting locale services” and then it “hangs” . . . I wait for a few minutes, then I go from there into TTY1, and I can log in and I can run commands . . . I ran the “efibootmgr” . . . and that shows a few systems, including the system that I wiped to install TW into, as being still there??

After I ran zypper ref && dup -l for the second time I saw an error “failed to import /etc/uefi/certs/188EA6FA.crt” . . . then I tried to see if I could launch a GUI app from the console so I ran “sudo gparted” . . . that failed . . . gave me a “GTK -warning 18:54:48:686: cannot open display” . . . .

As I mentioned in the other thread, over the same weekend I ran another distro install into an adjacent partition on the same disk as the TW install, and selected the “manual” or “expert” option and it all went well. Here in TW it seems to not be getting the bootloader data set properly in grub . . . I’m trying to avoid running through another install into the same partition . . . but multiple attempts to get “grub” updated don’t seem to be getting TW back into the GUI. Only right after install will it reboot into a fully working GUI, after that . . . no logging in to GUI desktop, only console system is working?

make sense?

2

What are “11/1 snap” and “11/7 snap”?

I suppose you are referring to 20191101 and 20190107 snapshots. But it would be easier to follow if you used the official name instead of using your own abbreviation.

It is not clear what you downloaded. There is a DVD installer, a NET installer, a KDE live image, a Gnome live image and a Rescue live image.

Both times when the installer finished the install/upgrade the system rebooted right back into the TW install and everything worked in the GUI

And what does that mean? It seems ambiguous. It could be saying that you booted back into the installer USB, or it could be saying that you booted into the installed system.

However, on cold boot and selecting the “EFI boot” disk which opens to Grub, when I select “TW” the screen immediately switching to variations of “crash” with errors like “efi not found” and other variations mentioning “kernel panic” or “trace dump” . . . I’ve tried the “recovery” options in Grub, same diff . . . .

Again, it is not clear what you did there.

From the 11/7 snap flash drive I can pick “boot from hard drive” and I can select “sdb8” and it goes to a command line that runs through a bunch of lines each saying “OK” . . . it has gotten down to something like “starting locale services” and then it “hangs” . . . I wait for a few minutes, then I go from there into TTY1, and I can log in and I can run commands

That hang suggests a graphics card issue.

I ran the “efibootmgr” . . . and that shows a few systems, including the system that I wiped to install TW into, as being still there??

What “efibootmgr” reports is the systems that your BIOS (or efi firmware) knows about. If you wiped a system, the BIOS might not know that you wiped it.

. . . then I tried to see if I could launch a GUI app from the console so I ran “sudo gparted” . . . that failed . . . gave me a “GTK -warning 18:54:48:686: cannot open display” . . . .

If the main GUI session did not start, then you won’t be able to start a GUI app from the console.

Sorry if I come across as pedantic there. But it is difficult to help if your description does not help me understand the problem.

As I mentioned in the other thread, over the same weekend I ran another distro install into an adjacent partition on the same disk as the TW install, and selected the “manual” or “expert” option and it all went well. Here in TW it seems to not be getting the bootloader data set properly in grub

You seem to be having problems that nobody else is having. But it is hard to know why when so much is unclear in your description.

3

Normal procedure here is to include kexec_reboot=0 on the installer cmdline. If the TW installer is still using kexec for rebooting, it wouldn’t be until the subsequent boot that the Grub installation gets tested.

Are all the distros installed in the same mode, UEFI vs. MBR/Legacy? What are your ‘cat /etc/fstab’, ‘efibootmgr’ and ‘parted -l outputs’?

4

@nrickert:

Alrighty, thanks for the reply, albeit yes “pedantic” in nature . . . if I knew what the “problem” is I would either “fix” it, or state it as plainly as possible, as it is it’s not clear hence the “narrative” approach, which if read could be understood. Plainly, I tried a NET installer, that broke, then I tried a plain jane DVD installer of the 11/1 snap . . . shot 64_x86, it appeared to “go well” but on cold boot did not.

I then used the plain jane snap . . . shot of the 11/7 DVD installer and I tried to use “upgrade” since there is a base system already there. From the other thread I posted in where the guy says, “Don’t use the live installer, use the regular installer” thread, it appears to me that there is some problem with the installer, possibly as far as EFI type installs goes, there appear to be other people posting issues on this forum with “grub” and “UEFI” iin the subject lines, so I don’t think my situation is entirely unique.

Also, we could take the argument that an “installer” is an “installer” and it shouldn’t matter which “installer” you use . . . it should “install” the system . . . and generally if the installer “signs off on it” it should boot up and run.

Yes

It is not clear what you downloaded. There is a DVD installer, a NET installer, a KDE live image, a Gnome live image and a Rescue live image.

Answered above.

And what does that mean? It seems ambiguous. It could be saying that you booted back into the installer USB, or it could be saying that you booted into the installed system.

The installed or then the subsequently freshly upgraded system–bare metal.

Again, it is not clear what you did there.

Super clear, grub boots TW to a black “crash” command line window, “pick any key to continue.”

That hang suggests a graphics card issue.

I’m over here in a Gecko MATE system in the same HDD that the busted up TW install is in, typing this post out . . . graphics are “perfect” to quote our fearless leader . . . .

What “efibootmgr” reports is the systems that your BIOS (or efi firmware) knows about. If you wiped a system, the BIOS might not know that you wiped it.
If the main GUI session did not start, then you won’t be able to start a GUI app from the console.
Sorry if I come across as pedantic there. But it is difficult to help if your description does not help me understand the problem.
You seem to be having problems that nobody else is having. But it is hard to know why when so much is unclear in your description.

OK, in the past when various OpenSUSE installs went sideways I was able to get into a ubuntu install and run “update-grub” and that seemed to tidy up Grub so that all the systems were “seen” and bootable from Grub, but so far numerous attempts to do that, along with several “dup -l” from within the TTY, a fresh iso used to “upgrade” the install, one that showed “installing grub” and “installing bootloader” . . . have NOT repaired whatever the problem happens to be . . . i.e., Grub not booting TW, but booting the other four linux options w/o issue.

mrmazda https://forums.opensuse.org/images/misc/quote_icon.png [QUOTE]Originally Posted by non_space https://forums.opensuse.org/images/buttons/viewpost-right.png](https://forums.opensuse.org/showthread.php?p=2919947#post2919947)

             Both times when the installer finished the install/upgrade the system rebooted right back into the TW install

Normal procedure here is to include kexec_reboot=0 on the installer cmdline. If the TW installer is still using kexec for rebooting, it wouldn’t be until the subsequent boot that the Grub installation gets tested.

Are all the distros installed in the same mode, UEFI vs. MBR/Legacy? What are your ‘cat /etc/fstab’, ‘efibootmgr’ and ‘parted -l outputs’?

[/QUOTE]

@mrmazda:

Thanks also for the post and the questions, sounds like you are saying that the installer could “reboot itself into the newly installed system” . . . but then if there was an error somewhere it wouldn’t show up until like it has for me . . . on the cold boot to Grub???

Same basic problem with your questions as when I was having issues with nvidia drivers not uninstalling when I upgraded to 15.2 . . . losing the GUI makes it hard to run those commands and then copy/paste them . . . to a post here.

As it is now to get to the TW install I have to boot the installer, pick “boot linux from hard drive” and then wait until the dmesg stuff runs through and hangs, then open a TTY . . . run the commands and likely hand copy them out. We went through ways of doing a “pastebinit” type deal here, but got a bunch of stuff going on right now, likely it will be tomorrow before I have the time/space to run through the process to get me into TW. >:(

5

Exactly. (A simple “Yes” answer to a yes/no question is not acceptable to the forum software. It requires at least 10 characters.)

6

In principle – yes. However, we have recently learned that the installer on the live media has problems. It is actually the same installer, but the environment on the live media causes it to malfunction.

I do not have any personal experience with MAC hardware.

It actually looks to me as if your system is booting, but the GUI session is not starting.

You can maybe test that. When you get a grub menu, hit the ‘e’ key. Scroll down until you find a line that begins with “linux” or “linuxefi”. Hit END to get to the end of that line. Then append a “3” to that line – just the single character, no quotes. But make sure that there is a space before the “3” (or insert a space if needed). Then hit CTRL-X. If booting is working, that should take you to a command line boot.

If that all works, try the same thing again. But this time, instead of “3”, append “nomodeset”. And see if it boot into a GUI.

7

@mrmazda:

Thank you. [ten characters including the space]

@nrickerts:

OK, thanks for the tips to try out . . . but, if I use regular cold boot to grub, then, no, I don’t think the system is booting and GUI isn’t loading, grub goes to “efi not found, hit any key” . . . only if I use the usb installer on boot, then select “boot from hard disk” will it “boot the system, but not the GUI” . . . so the system itself is not “booting” by its lonesome . . . .

8

Okay.

When you next boot (via the usb if that is needed), can you get the output from:


/usr/sbin/efibootmgr -v
9

It wouldn’t surprise me if the Mac firmware is exposing a bug in openSUSE’s grub-efi. This smells a little bit like the MacOS boots from HD but openSUSE 15.1 does not behavior on my '07 iMac: https://forums.opensuse.org/showthread.php/535388-Installation-on-a-Mac March 2019

10

Understanding your post is time consuming and a challenge. Providing relevant and concise information may help in diagnosing the problem:

erlangen:~ # lsblk -o NAME,PARTUUID,FSTYPE
NAME        PARTUUID                             FSTYPE
sda                                              
├─sda1      2c0e640c-3df5-470a-a17c-89b17eba59d8 ext4
├─sda2      410b7947-08ad-4fb7-93ea-854f63a3bf78 ext4
└─sda4      1f1100a4-325e-4d9e-84a3-bc119b98a449 ext4
sdb                                              
** ├─sdb1      2fe6b58a-379a-4f6e-899b-8be22ef6e885 vfat**
├─sdb2      f1379b6c-304b-4606-98b8-5cec4f3dd678 ext4
├─sdb3      1e7b0509-97cf-4a62-b7fc-db46be72335b ext4
├─sdb4      ced907e6-2af7-42d8-8643-31a61479352b ext4
└─sdb5      f4880da8-3641-499b-81b6-4432b106f8ff btrfs
nvme0n1                                          
├─nvme0n1p1 6c573fc1-08a3-4a7c-94bb-5488c8a0ba91 ext4
├─nvme0n1p2 f756cc7f-1727-4f82-8c5e-5b4468a74e72 ext4
├─nvme0n1p3 63413441-e35b-41a7-9dab-536a91b8f418 ext4
** └─nvme0n1p4 0497bfdf-73d7-47a8-9d8e-6b911574f774 vfat**
erlangen:~ # efibootmgr -v 
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0005,0006
Boot0000* opensuse      HD(1,GPT,2fe6b58a-379a-4f6e-899b-8be22ef6e885,0x800,0x32800)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* Fedora        HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\FEDORA\SHIMX64.EFI)
Boot0002* sled  HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\SLED\GRUBX64.EFI)
Boot0003* manjaro       HD(1,GPT,2fe6b58a-379a-4f6e-899b-8be22ef6e885,0x800,0x32800)/File(\EFI\manjaro\grubx64.efi)
Boot0005* arch  HD(1,GPT,2fe6b58a-379a-4f6e-899b-8be22ef6e885,0x800,0x32800)/File(\EFI\ARCH\GRUBX64.EFI)
Boot0006* opensuse      HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
erlangen:~ #

Providing a list of boot loader files installed may be helpful. Post all efi system partitions:

erlangen:~ # find /boot/efi/ -type f
/boot/efi/EFI/opensuse/grubx64.efi
/boot/efi/EFI/opensuse/MokManager.efi
/boot/efi/EFI/opensuse/grub.efi
/boot/efi/EFI/opensuse/shim.efi
/boot/efi/EFI/opensuse/boot.csv
/boot/efi/EFI/opensuse/grub.cfg
/boot/efi/EFI/opensuse/fwupdx64.efi
/boot/efi/EFI/boot/bootx64.efi
/boot/efi/EFI/boot/fallback.efi
/boot/efi/EFI/manjaro/grubx64.efi
/boot/efi/EFI/arch/grubx64.efi
erlangen:~ # 

erlangen:~ # find /mnt -type f
/mnt/EFI/opensuse/grubx64.efi
/mnt/EFI/opensuse/fwupdx64.efi
/mnt/EFI/opensuse/MokManager.efi
/mnt/EFI/opensuse/grub.efi
/mnt/EFI/opensuse/shim.efi
/mnt/EFI/opensuse/boot.csv
/mnt/EFI/opensuse/grub.cfg
/mnt/EFI/sled/grubx64.efi
/mnt/EFI/BOOT/BOOTX64.EFI
/mnt/EFI/BOOT/fbx64.efi
/mnt/EFI/fedora/shimx64-fedora.efi
/mnt/EFI/fedora/BOOTX64.CSV
/mnt/EFI/fedora/mmx64.efi
/mnt/EFI/fedora/shim.efi
/mnt/EFI/fedora/grubx64.efi
/mnt/EFI/fedora/grubenv
/mnt/EFI/fedora/shimx64.efi
/mnt/EFI/fedora/grub.cfg
erlangen:~ #
11

Yes, that is a possibility.

12

@mrmazda:

Thanks for the reply, that seems like what is going on, because the installer shows “installing bootloader” as a process, pointed to “sdb1” . . . but somehow it isn’t, or interestingly, in the Grub menu TW shows as an option, but then doesn’t “boot” it. I gave a fast read through your linked thread . . . actually Sno Lep was probably the best version of OSX in quite awhile, I still have a partition with it on my 09 MBP, and I kept 10.9 on it until a few months back. Couple of issues, OSX does not play well with others, so OSX has to go in first, then any linux installs. Also these days rEFInd isn’t really needed, although it does provide some useful features like being able to “boot single user” from a menu; it used to be relatively easy to install, but then it got harder. And, these days linux offers the EFI boot disk image, if you pick that one it should install the EFI bootloader–using the option key, unless, like on my MBPro, if linux went in last then on cold boot it will just boot to Grub. If I were to run some OSX update it would break Grub’s auto-boot and I have to go back to using option key.

Also, whereas I guess you could add OSX into Grub, I think it is time consuming to do, so I don’t use Grub to boot OSX in any of my machines, just linux.

@karlmistelberger:

Yes, it does seem complicated, but thanks for the thoughts on it . . . I’ll check into it later on, again, same problem, not GUI for copy/pasting . . . but, the “/mnt” thing looks promising . . . .

13

et al:

Got back to the TTY and ran as many of the commands as I could, some of them “worked” . . . some didn’t, again, hard to get that data posted over here . . . after I ran those commands I ran another zypper ref && dup . . . supposedly “9.2 MB” to download and install, got to package #4 “openSUSE-release-20191112-314.1x86_64.rpm” . . . and it stalled . . . walked away for a few minutes and when I came back it was still hanging there. Tried to ctrl-x out of it, but TTY1 didn’t respond, went to TTY2 and tried the same command, but it was “locked” by zypper, so I just rebooted out of it and into another recently installed linux system that is working just fine.

Yes, all are UEFI. “/etc/fstab” showed “swap, /, /home, and /boot/efi” as I had it set in the installer. I believe the “efibootmgr” shows /boot/efi as “UUID=67E3-17ED” and “parted -l outputs” shows all three disks with flash drive and all of the internal partitions, including efi, etc.

I tried this adding the 3 and it still went to the "efi not found, hit any key to continue, and then went to the command line showing “panic” and “dump trace” rebooting in 90 seconds.

This command brought back “unknown column, NAME” when I tried to put “NAME, PARTUUID, FSTYPE” and then also didn’t work when I tried just “lsblk -o”

erlangen:~ # efibootmgr -v 
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0005,0006
Boot0000* opensuse      HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\OPENSUSE\GRUBX64.EFI)

I changed the numbers to what was showing on the TW line, output, it showed the other options as well . . .

erlangen:~ #

Providing a list of boot loader files installed may be helpful.  Post all efi system partitions:

erlangen:~ # find /boot/efi/ -type f
/boot/efi/EFI/opensuse/grubx64.efi
/boot/efi/EFI/opensuse/MokManager.efi
/boot/efi/EFI/opensuse/grub.efi
/boot/efi/EFI/opensuse/shim.efi
/boot/efi/EFI/opensuse/boot.csv
/boot/efi/EFI/opensuse/grub.cfg
/efi/Trashes/._502
/efi/Trashes/._501
erlangen:~ #

I believe I copied the “opensuse” lines out of that data.

erlangen:~ # find /mnt -type f

erlangen:~ #

Running this command just brought a boot cursor, no data found or shown on it.

14

Bump. I modified the data that Karl provided, that I copied from the console by hand and posted it in the last two posts . . . nothing to be derived or learned from any of that??

15

The EFI information looks normal.

I do not know what would cause a panic when booting to init level 3 (command line).

16

@nrickert:

OK, yes it does seem like the EFI info looks normal, but what about the suggested “find /mnt type -f” ??? Karl showed he had data for that command, but, in my case there was none, it just returned to the flashing cursor line???

17

Typically, “/mnt” is an empty directory – unless you happen to have mounted something there.

18

@nrickert:

OK, I didn’t know, but what was the purpose of running that command then? I thought it was to show the next step in the EFI boot process, as to what would be “mounted” or not mounted . . . .

So seems like something somewhere in the install is not working to actually boot the system, a so far unidentified error . . . .

I hesitate to spend more time running a fresh install on it, as I have done so a couple three times on this particular version of OpenSUSE TW . . . recovery can’t fix it, grub won’t boot it, but I can wend my way into the install via TTY, otherwise only after fresh install will it reboot into a fully functioning GUI . . . otherwise . . . “dump trace panic” . . . ???

Is there a way to add a new sudo user to the system, along with the password via the TTY??

19

There is a “useradd” command. And the man pages document it.

20

Follow-up with

sudo passwd <newusername>

Or, use text mode YaST for both:

sudo yast

Either way you can first login as root and then skip the sudos. :slight_smile: