TW20260218 broke my unique grub GPT booting from legacy BIOS

[mrmazda]

On my only PC out of 40+ that is not UEFI-equipped and not booting via Grub Legacy, but is instead using Grub2 with a GPT SSD, attempting to boot since zypper dup to 20260218 causes Grub to fleetingly announce it’s loading a kernel, without first presenting any menu, upon which screen quickly turns black, and PC reboots. I had to change a heap of things in BIOS to get it to boot from USB2, but eventually I got the TW NET .iso from several months back booted and chrooted into the installed system:

1. parted shows bios_grub on /dev/sda4
2. /etc/default/grub_installdevice shows:

• /dev/disks/by-label/<SSD’s dev/sda3 by its LABEL> # flagged legacy_boot in parted
• activate
• generic_mbr

3. /dev/sda3 does not mount to /boot/, but was a clone of /boot/ before this dup. Resyncing of fonts, i386-pc & locale betwen them didn’t change anything.
4. first stanza in /boot/grub2/grub.cfg seems to be exactly as expected, but even though installed kernel count was unchanged (one removed, one installed), it’s 640 bytes smaller than the previous version.
5. normally Grub presents the stanzas in /boot/grub2/custom.cfg first, as a consequence of a copy of /etc/grub.d/41_custom named /etc/grub.d/07_custom (26 months ago). /boot/grub2/custom.cfg has not been touched in about 6 weeks, when I last had reason to change it.
6. /etc/default/grub remains untouched since I last changed it in December; contains GRUB_TIMEOUT=“15” and GRUB_DISABLE_SUBMENU=“y”
7. installed grub2 packages:

• grub2-2.14-4.1.x86_64
• grub2-common-2.14-4.1.x86_64
• grub20i3860pc-2.14-4.1.x86_64

8. In the chroot, journalctl -b -1 -p3 says no journal boot entry found for -1.
9. I don’t see any fresh Grub bugs in https://bugzilla.opensuse.org/
10. https://paste.opensuse.org/pastes/ecf1b68b0b0b is fresh /var/log/pbl.log
11. ext4 / is /dev/sda23
12. yast* are no longer installed
13. tried running update-bootloader --install from chroot, both with, and without, /dev/sda3 mounted to /boot/, and now, after appearing once during first try on powerup, screen is never anything but black without striking BBS key or BIOS Setup key during “POST”. Normally rebooting Linux puts POST messages on screen before Grub starts just like after initial powerup.

What’s needed here? Does the upgrade to 2.14 from 2.12 require a rewrite to /dev/sda4 or /dev/sda3 that didn’t happen during the dup?

[mrmazda]

@mrmazda

zypper dup to 20260218 causes Grub to fleetingly announce it’s loading a kernel

Zypper dup to 20260219 didn’t help, and as much of the fleeting message I can read before it disappears is “Welcome to Grub”. Booting the installed system works fine by typing the entire content of the Grub stanza it normally boots from using Grub from booting the TW rescue .iso. I reinstalled yast2-bootloader, but using it to change the timeout didn’t improve the behavior. What’s really weird when it reboots itself is never seeing any of the normal POST messages seen following a Linux restart — makes me think there is a more fundamental breakage of some kind in this 2.14… I have yet to find the doc that spells out how exactly what command it takes to freshly populate the bios_grub partition with 2.14 content. Force reinstalling grub2, grub2-common and grub2-i386-pc was no help. I also haven’t found anything that spells out the correct value of LOADER_LOCATION= in /etc/sysconfig/bootloader for GPT disk in legacy BIOS PC. None from type list “floppy,mbr,root,boot,custom,none” seems applicable to a bios_grub partition.

[mrmazda]

Back in business using grub2-install --target=i386-pc /dev/sda.