zypper dup -l finds "grub2" updates . . . removing . . . multi-boot grub listings???

English Install/Boot/Login
1

Gents:

Continuing saga on the multi-boot and grub2 issues . . . seems like there is a continuing “issue(s)” with grub updates that are moving through the linux community . . . problems that haven’t seemed to have been addressed to any extent, if at all . . . .

I’ve been working through apt/zypper/pacman updates on my 5 linux installs . . . and I’ve posted about those problems and generally the sage advice is, “it’s too complicated to do what you are doing” . . . but, when it’s working, it’s working, and with “rolling” and “developmental” systems there is no choice but to “upgrade” . . . .

Today, I ran a zypper ref/dup -l and I saw in the “72 packages ±” listing a few grub2 packages . . . in the interest of “science” I ran the zypper process and then only logged out and back in for a couple hours. Just a few minutes ago I went for the reboot . . . and going into OSX boot manager are the “three” EFI boot disks . . . for the three internal drives. In the recent history the “middle” one brought up the full grub listing, but after updating grub, etc . . . now it only goes to U-MATE??? The “first” one boots to a grub error and into rescue . . . and the “third” one also boots only U-MATE . . . .

But, this is not new, in both Lu 20 & U-MATE 20, and now TW . . . in the last week or so, the “grub2” and other grub packages were listed for upgrading, and after running them the only option for booting was the system that was upgraded, i.e., first it was only Lu showing . . . I “fixed” it using the chroot data provided by one of the gurus here in this formula . . . chrooting over to Yast and I guess having that run “os-prober” . . . seems to be the only way to fix grub. When I ran “update-grub” in the ubuntu systems it would find the five linux installs, but on reboot . . . back to the single listings.

I assumed it was a “ubuntu” issue, wherein ubuntu was assuming “total authority” over grub and just setting grub to boot “itself” . . . searched some forums, added my problem onto a bug that seemed “similar” . . . . So point is that with each of the ubuntu distros I had to boot into linux using SG2 disk, find the line item that opened the OpenSUSE Grub page that listed all of the systems . . . and then chroot into Yast . . . .

And then today, TW showed the same items, and the same result transpired . . . except in this case, rather than the EFI disks going to grub error, at least I can type this out in U-MATE . . . . Haven’t tried to run YAST Bootloader yet, but there is something that “isn’t right” in the grub EFI packaging . . . it’s again breaking up . . . itself . . . and I think I have a number of threads posted here int he last 6 - 8 months that involve grub not installing itself or doing well with EFI . . . ??? Problems continue . . . the nice thing about this forum is that there is or are “responses” . . . whereas over on LP . . . not so much?

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1863434/

2

Well, as always, once you think you have something that “works” . . . something comes up so that it doesn’t . . . .

From in U-MATE I chrooted over to TW, launched YAst . . . ran the os-prober?? which is what worked to restore Grub the last two times the problem came up. Rebooted . . . and nope . . . still only U-MATE.

Thinking that it was because the latest update was run in TW, thereby breaking up TW’s relationship with Grub, I then chrooted over to the Geck partition, just next door to the TW partition . . . ran through the steps for the Yast bootloader . . . rebooted . . . and nope . . . still only U-MATE???

So I guess if I want to get into some other system I’ll have to get the SG2 disk out and see if that can boot anything . . . PITB . . . this is the third time going through this problem . . . working my way through each of the systems . . . .

3

I’m not clear on what problem you are having.

Your post seems to indicate that you are not happy with what is happening. But it does not tell me clearly what is happening.

Yes, there have been several grub updates recently. But everything is working as it should. The only place I am having issues is with IA32 architecture – a 64-bit system, but booting with 32-bit EFI (see bug 1167933).

4

@nrickert:

I’m not “unhappy” . . . because obviously the thrill of linux is having these problems show up . . . to keep it “alive” . . . I’m just “disappointed.” : -)

But, OK, before I ran the upgrade in TW this morning I had access to my “main grub” via an EFI boot disk image that loads in OSx boot manager . . . and that grub window was an OpenSUSE “square within the square” type of Grub page–listing the 5 linux options and it shows a couple OSX options . . . and it “worked” to allow arrowing down to select a linux system to boot . . . and it was “good.”

After I ran the TW upgrade this morning with the varying “grub” packages showing . . . that joyous Grub window showing the 5 options was eliminated . . . there is a “dmesg”?? window and down toward the bottom it says “Failed to set MoklistRT: invalid parameter” . . . and then it boots to only U-MATE . . . no other options or choices are seen or offered.

In the meanwhile I got the SG2 disk out and had to fiddle around with it to get a system to boot, other than U-MATE, and I got into my Manjaro system . . . and I ran “update-grub” which works in Manjaro . . . but trying to chroot over to the TW Yast as I did with U-MATE . . . errors out when I try to launch “yast” . . . saying something about “# . . . . the true path for yast is /usr/bin/yast . . . meaning you might need super user status . . .” returning to the “#” cursor . . . . So I don’t get Arch too well . . . I have evn less time in Manjaro than I do in OpenSUSE.

Anyway, the multi-boot listings for Grub have once again been removed in a normal update . . . it does allow me to get into U-MATE only . . . I’ve tried the chrooting over process into TW and Gecko and as that previously has “fixed” grub where all other suggestions did not. . . now it so far hasn’t “worked.” Only the SG2 disk is seeming to get me into other options away from U-MATE . . . .

And, that part is the new “anomaly” in that in the last two rounds of this problem flowing through the “apt” process, the “default” boot became the system that was most recently updated . . . i.e., first only Lu showed up, then only U-Mate, so it should have been today that only TW would boot up, but instead it reverted to the U-MATE only status. When I run “update-grub” in the console . . . all of the systems are “found” . . . only one boots.

5

@nrickert:

I looked over the bug 1167933 and scanned through the posts, beyond my pay grade to understand, but, possibly again it could be the “efibootmgr” aspect, since I am EFI booting . . . and I’ve bumped into this problem a number of times since changing from 15.1 or 15.2 to TW . . . .

But, this machine is totally in 64 bit land . . . so I don’t think the 32 bit aspect is what is hitting me . . . . I did add myself to the email list for that bug . . . .

6

I’m still unsure about what problems you are having.

I am guessing that “SG2” means the SuperGrub2 disk.

Tumbleweed is now using grub-2.04. That started in the second half of last year. Previously it had been using grub-2.02. I have not experimented with Ubuntu 20.04, because it is not yet released. But my guess would be that it is also using grub-2.04. And Manjaro/Arch probably uses grub-2.04. But your SG2 disk is probably still using grub-2.02.

Perhaps that change from 2.02 to 2.04 is affecting you. It is not causing any issues here, but then I don’t have an OSX system.

7

@nrickert:

I don’t know how else to express the issue . . . after running the TW “zypper dup -l” this morning I could no longer boot into TW, or any other linux distro, only U-MATE will boot from “EFI” disk–no other listings are showing anywhere, only grub “errors” or “grub rescue.”

After running the “grub” packages in zypper I no longer had access to the “grub” window that actually shows the 5 available distros and lets me select which one I want to boot.

The only distro I can boot is U-MATE. Yes, SG2 is Super Grub2 . . . and there I was able to select “one” other system and boot it, but it doesn’t seem to have “repaired” “grub” . . . if I want to pick another system then likely SG2 would do it.

But, first thing this morning from cold boot to EFI disk, “main grub” window loaded and I logged into TW . . . and then ran “zypper ref/dup -l” . . . on reboot now I can’t get to TW log in, or anything . . . other than U-MATE 20.04. Since I was able to chroot into TW Yast from U-MATE I assume that the “/” filesystem is still there and not wiped as has occurred in the recent weeks . . . .

8

What is the output from

efibootmgr -v

Run that as root on either Tumbleweed or Ubuntu.

9

I ran this using “sudo” in Gecko . . . . I just used SG2 to boot into TW and again try to run YAst Bootloader . . . again didn’t “refresh” “main grub” went into grub rescue . . . took a few runs on SG2 to get over to Gecko, where I repeated the Yast “os-prober” process . . . .

What’s “interesting” to me about the code below is it seems to be showing “current” is 0000??? . . . which is one of the “ubuntu” selections, but I’m now booted in Gecko in what should be “sda8” partition perhaps is the 0001 option . . . by way of using SuperGrub 2.04 beta . . .

BootCurrent: 0000
BootOrder: 0001,000C,000B,0009,0007,000A,0006,0005,0004,0000,0080,0003,0002
Boot0000* ubuntu    HD(1,GPT,1470d224-08ec-4863-9e67-93af726f576b,0x28,0x64000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* opensusetw-secureboot    HD(1,GPT,0d8470db-279c-4890-8cdb-8af7d48ab8c4,0x28,0x64000)/File(\EFI\opensusetw\shim.efi)
Boot0002* grub    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\grub\grubx64.efi)
Boot0003* lubuntu1910    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\lubuntu1910\shimx64.efi)
Boot0004* grub-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\grub\shim.efi)
Boot0005* opensuse-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\opensuse\shim.efi)
Boot0006* tumbleweed-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI	umbleweed\shim.efi)
Boot0007* ubuntu    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\ubuntu\shimx64.efi)
Boot0009* ubuntu    HD(1,GPT,0d8470db-279c-4890-8cdb-8af7d48ab8c4,0x28,0x64000)/File(\EFI\ubuntu\shimx64.efi)
Boot000A* ubuntu    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\lubuntu1910\shimx64.efi)
Boot000B* opensuse-secureboot    HD(1,GPT,0d8470db-279c-4890-8cdb-8af7d48ab8c4,0x28,0x64000)/File(\EFI\opensuse\shim.efi)
Boot000C* tumbleweed-secureboot    HD(1,GPT,0d8470db-279c-4890-8cdb-8af7d48ab8c4,0x28,0x64000)/File(\EFI	umbleweed\shim.efi)
Boot0080* Mac OS X    PciRoot(0x0)/Pci(0x1f,0x2)/Sata(3,0,0)/HD(3,GPT,7420b4c3-007e-4b98-b566-eaa4ebf5e403,0x1d5a9f00,0x1d40da70)
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(3,GPT,7420b4c3-007e-4b98-b566-eaa4ebf5e403,0x1d5a9f00,0x1d40da70)/File(\System\Library\CoreServices\boot.efi)
BootFFFF*     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(3,0,00000000000000000000000000000000,0x5d5,0xf79)/File(\System\Library\CoreServices\boot.efi)

While I was in the console of Gecko I ran the zypper updates command, and there are the grub packages waiting to also create further trouble . . . I didn’t run the actual upgrade . . . figured I would see if we can fix the problem . . . then let Gecko break it later . . . all in the interest of “linux science.”

grub2
  grub2-i386-pc grub2-snapper-plugin grub2-x86_64-efi gstreamer-plugins-bad
10

That’s quite a mess.

I don’t know how many openSUSE systems you have on that computer. However, you have a number of boot entries that appear to be for openSUSE systems.

Most likely, boot numbers 0001, 0002, 0004, 0005, 0006, 000B, 000C
are for booting openSUSE. The trick is to find which ones work (if any).

Those entries are using two different EFI partitions. Entries 0001, 000B and 000C use the partition with

PARTUUID=0d8470db-279c-4890-8cdb-8af7d48ab8c4

while entries 0002, 0004, 0005 and 0006 use the partition with

PARTUUID=7f39c61b-b9d1-4378-8478-a5e99ae6079d

You can use the output of

blkid

to identify those partitions.

Once you have identified them, look in those partitions for directories below “EFI” with names such as “grub” or “opensuse” or “tumbleweed” or combinations. And then look at files in those directories. The ones with the most recent date are probably the ones that work.

Once you have found a boot entry that might work, you can test it. For example, if it looks as if boot entry 0006 might be the right one, then use the command

efibootmgr -n 0006

so that your next boot will try that entry. Then reboot, to test.

11

@nrickert:

Thank you, I’m very proud of my mess . . . but it was working fine before this morning’s zypper operation . . . which I think messed it up so it didn’t work.

But, thanks kindly for the details of trying to straighten it out . . . I’ll try to go through it and see if I can make sense of it . . . precerate it.

12

@nrickert:

Decided to run zypper over in the Gecko partition, figuring it couldn’t “get worse” than it is . . . and then I looked at the “blkid” data, and that kind of makes it more “clear” . . . looks like mostly it is the /dev/sda1 & /devsdb1 that are the EFI partitions . . . and possibly there are some “overlaps” . . . to add to the confusion, etc.

But, today’s question is, it seems like the “efibootmgr” must be “set” to 0000 and that might be the U-MATE system that seems to be the only system that would boot, so even if I change that number to one of the other options, then would that not simply boot another system . . . but “grub” will not be re-organized??

It seems like there is “grub2” AND there is “efibootmgr” . . . and they might be “connected” or not???

I’d like to get grub back to its normal state of organization and showing the 5 options . . . will booting another number via efibootmgr do that OR just switch the choice of one system from U-MATE to another option? I need options, many options . . . . : - )))

In a few minutes I’ll try to reboot after the Gecko grub2 upgrading and see if it is any better or even worse . . . .

13

@nrickert, et al:

Well, I’ve got “good news” along with the “bad news” . . . I did run the Gecko zypper updates for grub2 . . . and then shut down and cold booted with the alt/option key held down to get the OSX Boot manager window showing the various OSX and EFI boot disks . . . and going to the “middle one” . . . goes to a “grub” heading, but then shows the “Moklist” “Invalid parameter” items that showed up after yesterday’s OpenSUSE TW zypper updates . . . and back into U-MATE we went.

Then, in the further interest of “linux science” to see if somehow I was to access the “efibootmgr” somehow directly, I restarted “hands free” . . . no keyboard stroking . . . went to a blank screen . . . and then the wonderful OpenSUSE square within the square master Grub window opened . . . and I could arrow down and select . . . in this case a non-ubuntu and a non-opensuse option . . . . No SG2 disk required . . . no keystroke, etc.

So, perhaps this is the “lazy man’s” way out of the problem, possibly it’s still “a mess” in there in Grub-ville . . . and/or efibootmgr-ville . . . but I got back to my master Grub window . . . question is whether that was a recent “fix” subsequent to yesterday’s bust-up in the TW zypper process, or whether that has been in place for awhile. Several months back I believe I did a “free hand boot” and it went to one of the ubuntu choices . . . not the master grub that is showing now.

Thanks for the attention and discussion . . . very nice forum here.

14

They are not really connected, but they are related.

Your EFI firmware (or BIOS) uses NVRAM (non-volatile RAM) to store information about boot options. And “efibootmgr” reports what is in NVRAM, and can make some changes to that.

Your BIOS (or EFI firmware) uses NVRAM content to decide what is the bootloader to use. And then it is up to the bootloader.

When using “grub2” in an EFI system, part of “grub2” is stored in the EFI partition, and part of it is stored in your linux system (typically under “/boot/grub2” or “/boot/grub”).

The cause of your boot problems is this: A tumbleweed update should have updated both the part that is stored in your linux system and the part that is stored in the EFI partition. But you may have been using a mixed setup, where the part in the EFI partition was from grub 2.04, while the part in your linux system was from grub-2.04. And those don’t mix. So the trick is to get them matched up properly. And, incidentally, the same this is probably happening with your Ubuntu booting.

15

@nrickert:

OK, thanks for the details of explanation . . . so it’s literally like “grub 2.04” and “grub-2.04” are incompatible???

So, not sure if I have the chops, but, is there a way to get it “compatible” again . . . I mean it is now again “working” without using SG2, but it also seems like this is a recurring problem when these “grub2” packages get updated . . . dropping into the various distros in intermittent destruction of my master grub boot list.

I more or less get what you were suggesting as far as changing the efibootmgr number . . . but as far as getting my grub menu to show back up in one of the EFI boot disks . . . would that be where I would have to get all of the UUID numbers modified to all go to one EFI partition grub?

Or, is this something like simply editing what, the /etc/grub/default files in each of the five distros??

Historically, if I would do an OSX security update or upgrade it would also wipe linux grub UUID numbers, and my “seat of the pants” fix was to simply run a fresh install of something linux . . . and that would again tidy grub up, but that was also when there was usually just one HDD cut into only two or three partitions . . . . I just have more or less run out of distros that I want to play with . . . 5 is “enough” . . . . : - )

I was hoping that doing the chroot across to Yast would fix grub as it did in my other recent thread . . . but for some reason this time it didn’t???

16

Oops. A typo there. One of those was supposed to be “2.02”. Either will work. But when the part started by the BIOS does not match the part installed in the operating system, you will have problems.

So, not sure if I have the chops, but, is there a way to get it “compatible” again . . . I mean it is now again “working” without using SG2, but it also seems like this is a recurring problem when these “grub2” packages get updated . . . dropping into the various distros in intermittent destruction of my master grub boot list.

I’m not sure how things got out of sync for you. It has been working fine here.

One possible problem, is with your Gecko install. Gecko does not set up grub in the standard way. When I have used Gecko, one of things I would do after the install (and after booting the system) was go into Yast Bootloader, and have Yast reconfigure booting to do it the right way. Yast sets up the various pointers so that updates to “grub” shouldn’t break anything.

I more or less get what you were suggesting as far as changing the efibootmgr number . . . but as far as getting my grub menu to show back up in one of the EFI boot disks . . . would that be where I would have to get all of the UUID numbers modified to all go to one EFI partition grub?

The simplest step would be to delete NVRAM entries that are not working.

I’ll use the example of 0006, since that’s what I used before. But I don’t know if that is one that should be deleted. In any case, the way to delete it would be:

efibootmgr -b 0006 -B

But change that “0006” to the one that you want to delete. And you can just use “6” instead of “0006”.

Or, is this something like simply editing what, the /etc/grub/default files in each of the five distros??

I’m not sure what you are looking for there. But the “GRUB_DISTRIBUTOR=” line defines the name of the NVRAM entry, except that if blank it defaults to the distro name. But Ubuntu does that a bit differently, and I have not tried changing “GRUB_DISTRIBUTOR” in Ubuntu.

Historically, if I would do an OSX security update or upgrade it would also wipe linux grub UUID numbers, and my “seat of the pants” fix was to simply run a fresh install of something linux . . . and that would again tidy grub up, but that was also when there was usually just one HDD cut into only two or three partitions . . . . I just have more or less run out of distros that I want to play with . . . 5 is “enough” . . . . : - )

If OSX deletes NVRAM entries, you can put them back with

efibootmgr -c (options)

Check the man page for “efibootmgr”. For me, in this computer, the following command would work:


efibootmgr -c -d /dev/sdb -p 1 -l '\EFI\opensuse\shim.efi' -L opensuse-secureboot

You would probably need to boot your install media to the rescue system to get a command line where you can run that command. Or boot live media, and get to a root command line.

17

@nrickert:

OK, thanks very kindly for walking me through that . . . . Whereas it does seem like in the recent history distros are “bleeding” over into other distros, like where the data in what was sdb7 seemed to be deleted by something being done in TW . . . . In the recent round of installs, that deleted system was Manjaro, and after we discussed that situation at length in another thread here I ran a re-install of Manjaro . . . so that was the “last man in” . . . to the game.

And, subsequently to that install I am rotating each day through one of the 5 linux distros and running upgrades as they appear . . . this post was dealing with the aftermath of running a zypper ref/dup in TW showing “grub2” updates . . . leaving the EFI grub disk blank and others leading to grub rescue . . . so if I need to get to a grub rescue prompt I think I can get there . . . I just never knew anything to type in there . . . .

So, again, in terms of the efibootmgr . . . that is still seemingly selecting the “boot order” of the various options, but isn’t in and of itself providing the “menu listing” of bootable options that grub2 window is or would provide??

I’m in Manjaro right now, and seemingly it isn’t “finding” . . . /etc/grub2/default or /etc/grub/default . . . so it’s either pilot error or they do it yet another way. For the rest of the NVRAM numbers that will take some time to consider and test out . . . .

18

Yes, that’s about right.

It is files with names such as “grub.efi” or “grubx64.efi” or “shim.efi” that provide the menu. And, strictly speaking, “shim.efi” simply does a secure-boot check and then calls “grub.efi” to do the rest of the work.

I’m in Manjaro right now, and seemingly it isn’t “finding” . . . /etc/grub2/default or /etc/grub/default . . . so it’s either pilot error or they do it yet another way.

Perhaps a typo. It is usually “/etc/default/grub” to set the defaults.

19

@nrickert:

“typo”?? perhaps . . . more like a gaffe . . . couldn’t find it in my “cliff notes” “how to fix stuff in linux” notebook . . . so I got it reversed . . . . Today, back to TW . . . just ran another dup -l . . . keeping my fingers crossed, etc. Nothing about “grub” was mentioned in the listings of packages . . . .