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

[non_space]

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?

[nrickert]

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 . . . .

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.

[mrmazda]

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'?

[non_space]

@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.

What are "11/1 snap" and "11/7 snap"?

I suppose you are referring to 20191101 and 20190107 snapshots.

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

Originally Posted by non_space

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'?

@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.

[mrmazda]

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???

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

[nrickert]

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.

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.

[non_space]

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

@mrmazda:

Thank you. [ten characters including the space]

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.

@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 . . . .

[nrickert]

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 . . . .

Okay.

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

/usr/sbin/efibootmgr -v

[mrmazda]

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/showthre...ation-on-a-Mac March 2019

[karlmistelberger]

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?

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:~ #