Hi
So your dupping took you to Leap 15.4 Beta…
Possibly, and I’m “OK” with that . . . but I think I did install it as 15.4 and the 1000 points of light upgrade took it to 15.4.1 as I saw in the repos somewhere . . . ??
Same question, if I zypper dup -ed from 15.3 to 15.4 or 15.4.1 . . . why did that mess with grub so that it won’t boot w/o SG2??
And then why didn’t running #grub2-mkconfig also not repair or re-write the grub file?? I’m asking this from within the 15.4.1 GUI . . . so the system is not “borked” . . . possibly just grub2 is???
Hi
Likely an upgrade bug and should be reported as such IMHO. openSUSE:Submitting bug reports - openSUSE
Again, it all depends on what the Leap developers are targeting, it may be the beta version is not in a position to upgrade, that’s based on my experience with SLE beta testing, they usually advise status and what is expected to work and what is not with each phase of the release cycle.
Hi
See https://news.opensuse.org/2022/03/02/leap-reaches-beta-build-phase/ There is a link to a spreadshett with test info.
Bug report filed.
The saga continues . . . when I first filed the bug the only option I saw was for “kernel” so I filed it as a kernel issue and that team seemed to respond quickly and interactively to assess the bug . . . concluding that it isn’t a kernel issue . . . bug was reassigned to the bootloader team . . . days have passed without any communication on it. That is more in line with my experience on the Launchpad bug site . . . like it might be a couple of months before someone will post . . . “hey I have this problem, too . . . .”
OK, I ran grub2-install and that went through quickly . . . then for good measure I again ran the grub2-mkconfig xxxx AND I ran Yast Bootloader AND then I shut it down.
On cold boot, back into the white room . . . .
I rebooted and selected "EFI boot" and a grub error window opens saying something about "MOKlist failed . . . parameter error" (something like that) . . . .
So, installing grub2 or re-installing it has not fixed the issue.
You could poke the bug via the YaST mailing list yast-devel@o… Currently the bug is assigned to the screening team (triage), which means no bootloader bug assignee who is not also a member of the screening team is likely to know about it. People who have been assigned to bootloader bugs include mainly Michael Chang, but also Matthias Brugger, Gary Ching-Pang Lin, Jiri Srain, Guillaume GARDET and Nicolas Patricio Saenz Julienne. You might try direct pings via their email addresses found in their assigned bugs, or by adding to CC on your own bug, but I wouldn’t add them all. Read some bugs assigned to them and compare to your own, then pick one who seems likely to be one who would or could fix it.
Don’t do everything above. Pick one, give it two weeks, and if no activity, try another. Sometimes lack of activity is due to vacationing.
Thanks for the details . . . didn’t realize that if the bug is changed from “kernel” it doesn’t just go to “bootloader” . . . but gets reviewed . . . . I check into your suggestions . . . system does boot using the external grub disk, just doesn’t fly on its’ own power . . . .
I tried to send an email to yast-devel as the “poke” . . . but it “bounced back” showing it was “rejected due to non-membership in the list” . . . .
Problem still not resolved even after running a few packages via zypper yesterday . . . reboots to the blankness, etc.
Sign up. Otherwise, you wouldn’t see any responses without visiting the web archives. YaST Development - openSUSE Mailing Lists
I fail to see how YaST is relevant for a problem that happens even before kernel is loaded.
OK, might do that . . . I did sign up for the lubuntu devel list-serve a couple years back, and then they switched over to website based and email digest and there were issues with that. I’m clearly not a dev . . . I just wanted to jangle the chain a bit on the bug post. Over in Lubuntu, when I wasn’t on the list they would “screen” the email before letting it go through . . . to various responses . . . . SUSE seems more “harsh” . . . outright rejection. Like it’s very “exclusive” . . . .
Might be a valid statement . . . I was assuming that “yast-devel” list-serve was just a place where the “devel-people” hang out and can be contacted??
Another option I hadn’t thought about, even though my IRC client has it open all the time: ircs://libera.chat/#yast
yast-devel is mailing list which is used by YaST developers. Place where “devel-people” “hang out” is bugzilla.
For any here not familiar with the special meaning white screen has in conjunction with a Mac, it seems to be the Mac BIOS’ way of saying “Your FOSS tools messed with my NVRAM, and that’s not welcome. As penalty, you will not be able to boot normally until a random number of rescue boots have succeeded, after which the convenient normal HDD boot process you expect will be re-enabled.”
Thanks for the follow up . . . I’m still not convinced that this was an OSX side issue, but rather some kind of internal zypper self-sabotage to grub2 . . . ??? I just posted this on the bug report that I filed.
Thanks for the fast service on this bug. I saw that a couple days back I booted up Leap via SG2 disk and ran a zypper dup -l and in the upgrades was a “grub2 xxx” and possibly a new kernel. Ran it through and on reboot the problem remained . . . .
Today, I again booted via SG2 and I ran Yast Bootloader, then I ran “grub2-install” and then for good measure I ran, “grub2-mkconfig” . . . . Then shut the machine down.
On cold boot the grub menu has once again returned for active duty.