grub2-2.02-181.2 may break booting for a small number of systems

SUSE Linux Enterprise Server 12SP5 LTSS

A system is patched with Patch SUSE-SLE-SERVER-12-SP5-LTSS-2025-629 (grub2-2.02-181.2) out of the SLES12SP5 LTSS repository.

The system stops booting and, depending on the firmware (BIOS) in use, may reset itself over and over.

Booting a rescue system, going chroot and reinstalling the bootloader into the MBR of the root disk (e.g. grub2-install /dev/sda) restores the bootloader and the system will boot fine.

It should be sufficient to remove /etc/default/grub_installdevice and afterwards run "update-bootloader --reinit".

It doesn't matter if that is done after reviving the system out of chroot, or doing that before patching the system.

Actually, it is recommended to remove grub_installdevice before patching the system.

Note: In multi-disk setups, or where softraid is used, grub_installdevice still may be beneficial. In that case make sure it points to the disk containing the /boot directory. Do not point it to a partition.

On SLES /sbin/update-bootloader is used to determine the bootdisk, and tries to  install the bootloader on the disk on which it finds /boot directory.

If grub_installdevice points to a different disk, installing the bootloader may fail and booting is impacted.

In all cases which were reported, grub_installdevice pointed to either a secondary disk, or to a /boot partition with a filesystem where embedding the bootloader was not possible. One of the security related patches in this grub2 version caused a ABI change. In the mentioned cases where a generic bootloader was installed in the MBR of the root disk _and_ grub2 was installed somewhere else, we'll see a incompatibility between the old code in the MBR and the new version of grub2.

Note that yast-bootloader will re-create grub_installdevice if it is missing during the upgrade process. Make sure to delete
it again after the update (or at least before doing the next upgrade).

For that an alternative may be to use a persistent device link instead. For example the by-id/wwn-* device links might be stable enough in a cloud environment (i.e. not change when migrating the vm around).