This is for grub2-2.02~beta2-73.1.x86_64 . If you are upgrading a machine or
installing a new version of grub2, and if you fail to do "grub2-install
/dev/sda", sometimes you can reboot your machine and sometimes grub dies before
putting up its kernel selection screen.
I'm guessing this mechanism: the old code in the MBR has a blocklist to the
stage 1 inode, which was replaced and whose content is dispersed to the free
list. If the blocks are intact, the machine can boot. If something in your
dist-upgrade used the blocks for another inode, your machine is unbootable.
The behavior is seen on real and virtual machines; on SuSE 13.1 and 42.1; I
think I've seen it on i586. I'm pretty sure it wasn't happening when SuSE 13.1
was first released because I upgraded about 100 machines without incident.
The affected machines all have 1 Mb vacant ahead of the first partition, so
there is plenty of space for grub modules. An old machine that has been
upgraded many times may have only a small space before the first partition, not
enough for grub, in which case grub2-install will give error messages about
blocklists.
Using the OpenSuSE-42.1 network installer I did a clean install on a virtual
machine, having formatted the disc (which does not actually clear all blocks to
zero, though), and it booted OK. But upgrading a VM image of v13.1 using the
network installer, it was unbootable.
To recover in this case and several others, I used the rescue system:
* Boot the rescue system.
* Mount your root partition on /mnt, e.g. mount /dev/sda1 /mnt
* Bind-mount /proc /dev /sys on /mnt/proc /mnt/dev /mnt/sys. E.g.
mount -o bind /proc /mnt/proc
* chroot /mnt
* grub2-install /dev/sda #Use the right disc, e.g. /dev/vda on a VM
* exit #(from the chroot)
* umount /mnt/sys /mnt/dev /mnt/proc /mnt
* reboot -f #And it will work.
I think an effective fix would be to execute grub2-install /dev/sda in grub2's
post script, but I'm sure there are contingencies that need to be thought
about, particularly weird locations of the grub modules.