http://bugzilla.suse.com/show_bug.cgi?id=960517 Bug ID: 960517 Summary: zypper install grub2, machine is sometimes unbootable Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: jimc@math.ucla.edu QA Contact: jsrain@suse.com Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.