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

English Install/Boot/Login
61

@mrmazda:

'12 Mac Pro . . . terminal didn’t accept “memory short” . . . .

butoh-mind@linux:~> sudo inxi -GxxSMC --memory-short
[sudo] password for root: 
Error 22: Unsupported option: --memory-short
Check -h for correct parameters.
butoh-mind@linux:~> sudo inxi -GxxSMC
System:
  Host: linux-f6nl Kernel: 5.3.9-1-default x86_64 bits: 64 compiler: gcc 
  v: 9.2.1 Console: tty 1 dm: LightDM Distro: openSUSE Tumbleweed 20191111 
Machine:
  Type: Desktop System: Apple product: MacPro5,1 v: 0.0 serial: C07KH09BF4MC 
  Chassis: type: 7 v: Mac-F221BEC8 serial: C07KH09BF4MC 
  Mobo: Apple model: Mac-F221BEC8 serial: J531300DQCZJC UEFI: Apple 
  v: 138.0.0.0.0 date: 07/30/2018 
CPU:
  Topology: Quad Core model: Intel Xeon W3565 bits: 64 type: MT MCP 
  arch: Nehalem rev: 5 L1 cache: 512 KiB L2 cache: 8192 KiB L3 cache: 64 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 51069 
  Speed: 1596 MHz min/max: 1596/3325 MHz Core speeds (MHz): 1: 1596 2: 1596 
  3: 1596 4: 1596 5: 1596 6: 1596 7: 1596 8: 1596 
Graphics:
  Device-1: NVIDIA GK110 [GeForce GTX 780] vendor: eVga.com. driver: nouveau 
  v: kernel bus ID: 05:00.0 chip ID: 10de:1004 
  Display: server: X.org 1.20.5 driver: nouveau 
  unloaded: fbdev,modesetting,vesa alternate: nv,nvidia compositor: marco 
  tty: 80x24 
  Message: Advanced graphics data unavailable in console for root. 
butoh-mind@linux:~>
62

@karl, et al:

Tried to run those commands, at the “clean” line I got the same “system management is locked by an application w/ pid 25933 (zypper). Close the application before trying again.”

So even though I logged out it appears that zypper is still running on the previous “dup” hang??? What is the opensuse method to quit out of zypper?

sudo zypper --kill-all

sudo --kill zypper

sudo cut zypper in half

???

63

Latest update:

So in the google I found mrmazda’s code to kill

kill -9 PID

and that did kill zypper that was prolly still running from last night . . . and then I tried to run Karl’s series of “systemctl to clean to refresh to dup” . . . and once again about 6 packages into the now 559 updates it “hung” . . . .

I opened a TTY2 and tried the

kill -9 PID

and it said, “You have to be more specific” . . . ??? so I thought it didn’t work, quit out of TTY2 and went back to TTY1 . . . and the process had indeed been “killed” . . . .

So I tried to upgrade “libcurl14” to see if that would get me around this seg fault hang problem on this very high maintenance install . . . and once again it said, “we don’t have any libcurl14 . . . nothing to do.”

So I ran the “return the helm to the graphical user” command . . . and I’m back where I was . . . about done messing with this for the day . . . .

64

Apparently you did not use the inxi from the URL I provided, or at least one that is new enough to offer that option.

# inxi -V | head -n1
inxi 3.0.37-00 (2019-11-19)
# inxi --memory-short
Memory:    RAM: total: 15.52 GiB used: 4.12 GiB (26.6%)
           Report: arrays: 1 slots: 4 modules: 2 type: Unknown

inxi -U can update itself if the -U switch is not disabled by the packager. If it is, it can be overridden via /etc/inxi.conf containing

B_ALLOW_UPDATE=true
65

@mrmazda:

Quite apparent . . . I saw that there was a linked addy in the email sent to me, but when I went to the forum it just said “inxi” . . . so I copied/pasted it into the terminal and ran it . . . I’m trying to get the system to boot from grub and then just run a normal “dup” so I wasn’t taking time to check whether I was using the right version of inxi, etc.

Hopefully you understand that this recent TW install has largely “gone sideways” . . . and up until yesterday it was only accessible via tty . . . wasn’t upgrading, and wasn’t booting . . . . Now with SG2 I know I can boot it, but this is a new install and I haven’t had time to add anything beyond what goes in in the stock install . . . .

It appears that there are multiple “issues” in play in this situation . . . and getting inxi tweaked to the latest edition wasn’t at the top of my concerns . . . but thanks for the data on it . . . if and when I can get this install cleaned up and running a GUI I’ll try to go back and get the “-U” going for it . . . .

66

Could be a hardware issue as reported here: “Solved. The SSD was bad. I replaced it and the installation went smoothly. Many thanks.” https://forums.opensuse.org/showthread.php/538276-new-installation-hangs

67

FWIW, your TW may have inxi installed. I don’t do full installs, so don’t know if it’s standard in TW, but the one TW has is 9 months old, while upstream changes on average every month or two.

68

OK, um . . . Manjaro install went in after the TW in the same HDD . . . no issues with that install . . . .

Yep, I was actually “surprised” that inxi was installed, I was anticipating it not working and then I would have looked at your linked data . . . but it did work, but w/o the --short memory aspect . . . . RAM is relatively new, couple years old, all matched to run on a Mac.

69

Same HDD, but different location. This will you tell anything.

Noticed folks were tinkering past weeks:

erlangen:~ # grep libcurl /var/log/zypp/history
2019-11-08 18:58:47|install|libcurl4|7.66.0-1.1|x86_64||openSUSE-20191106-0|e5007389397247224da618b59c00cfb0d3b3c8ed367768903bb464adde52702a|
2019-11-12 23:15:07|install|libcurl4|7.67.0-1.1|x86_64||openSUSE-20191106-0|9bbf14a2c6057ecabac3a7a16f8e080bc37e29d7a395e5e1ac0d50ec5d52d5bd|
2019-11-18 10:23:17|install|libcurl4|7.67.0-3.1|x86_64||repo-update|a42bf6d3053994544583fb11c49aebca7060809f759f6108e46a4c618f0b3edf|
2019-11-21 14:07:15|install|libcurl4|**7.67.0-2.1**|x86_64||openSUSE-20191106-0|6be48b0fd04e61a5b33c38751c81806230685de9ce8a6ba82467e111ad777c92|
erlangen:~ #

Never experienced any issues on host erlangen. But some users reported zypper segfaulting. What is your version of libcurl4?

70

@mrmazda: Did that, got the latest inxi . . . ran your requested command again . . . what was interesting is that this install was supposed to be “default video driver” . . . but it showed “nouveau” as the “driver” . . . but then later in zypper it shows that “nouveau will not be upgraded”??? something like that.

@karlm:

So this part is where “pilot error” had played into the mix . . . my aging eyes saw the package as “libcurl14” rather than what showed up when I ran your grep command for libcurl . . . showing “libcurl4” . . . which I then upgraded. After that I ran zypper for the 554 packages and that went through w/o a seg fault!!!

Then I went to the “grub rescue” video by Chris Titus and I ran the first two commands . . . from the TW console and got:

cd /boot
linux:/boot # ls
boot.readme                   sysctl.conf-5.3.8-1-default
config-5.3.12-1-default       sysctl.conf-5.3.9-1-default
config-5.3.8-1-default        System.map-5.3.12-1-default
config-5.3.9-1-default        System.map-5.3.8-1-default
do_purge_kernels              System.map-5.3.9-1-default
efi                           vmlinux-5.3.12-1-default.gz
grub2                         vmlinux-5.3.8-1-default.gz
initrd                        vmlinux-5.3.9-1-default.gz
initrd-5.3.12-1-default       vmlinuz
initrd-5.3.8-1-default        vmlinuz-5.3.12-1-default
initrd-5.3.9-1-default        .vmlinuz-5.3.12-1-default.hmac
symvers-5.3.12-1-default.gz   vmlinuz-5.3.8-1-default
symvers-5.3.8-1-default.gz    .vmlinuz-5.3.8-1-default.hmac
symvers-5.3.9-1-default.gz    vmlinuz-5.3.9-1-default
sysctl.conf-5.3.12-1-default  .vmlinuz-5.3.9-1-default.hmac

So stuff is in there . . . about to do a reboot of the newly upgraded system, so I’ll see whether grub has been fixed or if I still have to use SuperGrub2 to boot as I did this morning . . . .

71

Alrighty, well on reboot going to grub and selecting TW . . . goes back to error and kernel panic. But now on third use of SG2 it gave me an “EFI boot” selection and the list of choices was much simpler . . . top hit is TW . . . and back into TW . . . . So, I’ll have to rifle around and see if grub can be repaired . . . we’re back to the grub boot problem . . . back on topic to the OP’s thread . . . .

72

Ran:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-5.3.12-1-default
Found initrd image: /boot/initrd-5.3.12-1-default
Found linux image: /boot/vmlinuz-5.3.9-1-default
Found initrd image: /boot/initrd-5.3.9-1-default
Found Manjaro Linux (18.1.3) on /dev/sdb6
Found openSUSE Tumbleweed on /dev/sdb7
Found Mac OS X on /dev/sdc2
Found Ubuntu 19.10 (19.10) on /dev/sdc5
Found Ubuntu 19.10 (19.10) on /dev/sdc6
done

Which previously showed similar results, TW options are listed, but booting from grub has not “worked” . . . ???

73

What do the following show?

  • grep GRUB_DISTRIBUTOR= /etc/default/grub
  • efibootmgr -v
    *]cat /etc/fstab
74

@mrmazda:

Thanks for the T-day question . . . .

butoh-mind@linux:~> su
Password: 
linux:/home/butoh-mind # grep GRUB_DISTRIBUTOR= /etc/default/grub
GRUB_DISTRIBUTOR="TUMBLEWEED OpenSUSE"

linux:/home/butoh-mind # efibootmgr -v
BootCurrent: 0002
BootOrder: 0002,0003,0000,0005,0080,0006,0004,0001
Boot0000* opensuse    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\opensuse\grubx64.efi)
Boot0001* debian    HD(1,GPT,36faabea-42fb-40d1-b88b-fb254febf542,0x28,0x64000)/File(\EFI\debian\grubx64.efi)
Boot0002* tumbleweed-secureboot    HD(1,GPT,0d8470db-279c-4890-8cdb-8af7d48ab8c4,0x28,0x64000)/File(\EFI	umbleweed\shim.efi)
Boot0003* ubuntu    HD(1,GPT,1470d224-08ec-4863-9e67-93af726f576b,0x28,0x64000)/File(\EFI\ubuntu\shimx64.efi)
Boot0004* siduction_2018.3.0    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\siduction_2018.3.0\grubx64.efi)
Boot0005* Manjaro    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\Manjaro\grubx64.efi)
Boot0006* grub-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\grub\shim.efi)
Boot0080* Mac OS X    PciRoot(0x0)/Pci(0x1f,0x2)/Sata(2,0,0)/HD(2,GPT,7f49ef28-6bfc-4523-a88a-1148b7b94d81,0x64028,0x1d161920)/VenMedia(be74fcf7-0b7c-49f3-9147-01f4042e6842,11f54d5c769a284a842102224bd2197e)/File(\3A593A60-4D5F-4C03-A546-64C44DD0FA3C\System\Library\CoreServices\boot.efi)
Boot0081* Mac OS X    PciRoot(0x0)/Pci(0x1f,0x2)/Sata(3,0,0)/HD(2,GPT,3447e9e0-204a-414f-a226-9f19fa88ef29,0x64028,0x1d40ffb8)
Boot0082*     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(3,0,0)/HD(2,GPT,3447e9e0-204a-414f-a226-9f19fa88ef29,0x64028,0x1d40ffb8)
BootFFFF*     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/CDROM(0,0x35,0x1680)/File(\EFI\BOOT\BOOTX64.efi)

linux:/home/butoh-mind # cat /etc/fstab
UUID=dac6d73c-5e42-47ce-af39-ba762532645d  swap       swap  defaults      0  0
UUID=d8c52ffb-c429-46c4-bb8f-b786ca361672  /          ext4  defaults      0  1
UUID=64c5dba2-bacd-4459-9904-6bda0fbe24e7  /home      ext4  data=ordered  0  2
UUID=67E3-17ED                             /boot/efi  vfat  defaults      0  0
75

The disjunction among these may be the problem. The space in the distributor name could also be its own problem. It should be more like this:

# grep GRUB_DISTR /dev/etc/default/grub
GRUB_DISTRIBUTOR="opensusetw"
# efibootmgr -v | grep opensusetw
Boot0000* opensusetw    HD(1,GPT,...)/File(\EFI\OPENSUSETW\GRUBX64.EFI)

Notice the three case-indifferent appearances of opensusetw in the outputs, and no other opensuse variants. GRUB_DISTRIBUTOR= is what determines what directory name belongs in /etc/efi/EFI/ to be able to boot successfully.

(Chroot if necessary to do this.) I suggest to try to fix by cutting GRUB_DISTRIBUTOR= down in size and with no whitespace, then use YaST to update bootloader by changing the timeout. Before booting, check content of /etc/efi/EFI/ to see if there is a fresh entry matching your new GRUB_DISTRIBUTOR= name. If yes, then try a normal boot. I’m rather lost in this thread. Before starting, use efibootmgr to delete any unneeded or unwanted entries. Are you securebooting? If not, remove opensuse-secureboot.

76

That should not be a problem. The first word in DISTRIBUTOR is used, and it is forced to lower case.

The main oddity that I see is that there are possibly some stale entries. And I see references to at least 4 different EFI partitions:


7f39c61b-b9d1-4378-8478-a5e99ae6079d
36faabea-42fb-40d1-b88b-fb254febf542
0d8470db-279c-4890-8cdb-8af7d48ab8c4
1470d224-08ec-4863-9e67-93af726f576b

That’s not necessarily a problem. But if some of those partitions no longer exist, then it could be an issue.

Note that the value shown in “efibootmgr -v” output matches the PARTUUID of the EFI partition.

77

@mrmazda:

Alrighty, I’ll take a look at it some time tomorrow . . . editing the GRUB_DISTRIBUTOR items was suggested through this thread . . . didn’t see anything then about lower case or upper case . . . but it was pointed out that I had two “tumbleweed” entries . . . so I tried to reverse the name of the TW name so it didn’t match the Gecko item, and I changed the ubuntu name so it didn’t match . . . . None of those changes showed up in the Grub boot list that the TW, Gecko, and Manjaro installs are in . . . .

@nrickert:

OK, thanks for finding that data . . . there are three drives in the computer, each of them has an EFI partition . . . and for some reason the two ubuntu installs, both in sdc . . . and pointed to sdc1 . . . each have there own “efi boot” disk in the OSX boot manager window . . . . So I don’t know if that explains the “4 different EFI partitions” or not . . . a fair number of installs have gone into the various partitions . . . . Seems like erasing the partitions doesn’t clean up the Grub items in total??

78

It does not clean up the NVRAM entries, although that depends on the UEFI implementation.

Looking at one entry, I see:


Boot0006* grub-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\grub\shim.efi)

That is probably from your Gecko install.

If I wanted to remove just that entry, I would use:

efibootmgr -b 0006 -B
79

@nrickert:

Thanks, but the Gecko MATE rolling install is the longest lived install in that disk among the linux options . . . and has been more or less trouble free and reliable . . . .

The Siduction install was problematic and unfriendly to the other linux installs around it . . . if there is some detritus related to the Siduction install I would follow that advice . . . .

80

I was just explaining the command to use. It is up to you to decide which, if any, of those NVRAM entries to remove.

The “0006” that I suggested comes from the “efibootmgr -v” output for that entry. You should be able to adapt that idea to apply to other entries. Or just leave those entries there. They probably aren’t causing any problems.