Dualboot chainloading of Grub fails after update


I have two systems that are configured in the same way. Both are MBR dual boot with Grub being chain loaded via the Windows Boot loader. To make this work I have had to create a “phantom” MBR file from the first 512 bytes of the Thimbleweed boot record on the drive /dev/sda5 (note I used YaST to install grub on /dev/sda5 not /dev/sda. This MBR files is then put of the Windows partition and referenced in the windows BCD. I think this is all standard for dual booting with windows first.

However when I did my last update the Kernel got updated and so presumably so did the boot record of /dev/sda5. Both systems then failed to boot, one dropping into the Grub Rescue prompt and the other just hanging with the word GRUB on the screen. Booting from a rescue SD card, and making a new copy of the /dev/sda5 boot record and installing it on the Windows partition made it all bootable again.

Firstly is this what would be expected? Secondly, is there any permanent fix or am I going to have to recreate the boot sector for windows every time the kernel is updated.


I used to boot this way (with Windows 7 controlling the boot).

Whenever grub was reinstalled, I had to make a fresh copy of the boot record and copy that into the Windows system.

As long as you boot this way, you are probably stuck with doing that. Keep a bootable live USB handy.

I eventually went to an alternative approach.

In your case, it is unlikely that the kernel install caused this. However any update of grub2 will result in the bootloader being reinstalled, and you will have this problem. And, yes, Tumbleweed did recently update grub2.

My alternative approach:

When you use Yast bootloader, there’s an option to install generic code in the MBR. The generic code is actually in the file “mbr.bin” which is part of “syslinux” and is likely to be on your system. The file “mbr.bin” is 440 bytes long.

In the same directory “/usr/share/syslinux” there is a file “altmbr.bin”. This one is only 439 bytes long. You are expected to append 1 byte to the end of that file. At the time, I was booting from partition 5, so I appended a byte containing ‘0x05’ (binary 5). There are shell tricks to enable you to write that 1 byte output. And I then used “dd” to write that the MBR.

The result: My system now always boots partition 5, regardless of the active flag in the MBR. Since partition 5 is openSUSE, I get a nice boot menu. I set the active flag in the MBR on partition 3, which is the main partition for Windows 7. And now Windows 7 is always happy with the boot setup, because it thinks the Windows partition is the active one. And I no longer have to worry that an update will break booting.

Normally kernel installation just updates grub2 configuration file. It probably was grub2 update.

Firstly is this what would be expected?

In general, yes. Even if location of grub2 core.img has not changed, its size may have and the first sector you are using encodes full size of core.img. Depending on exact details of your installation both symptoms you described are quite possible.

Secondly, is there any permanent fix

Possibilities are

  1. Create script that updates file on Windows partition when bootloader has been updated in Linux. Script may run periodically (cron job/systemd timer), on shutdown or after grub2 installation (create dummy package that installs trigger to be run after grub2-i386-pc package has been updated).
  2. Create standalone grub2 image that chainloads Linux bootloader. Standalone image has internal RAM disk and you provide grub.cfg that is included on this disk and read by grub during startup. This script may do anything.

or am I going to have to recreate the boot sector for windows every time the kernel is updated.

Except that it is not kernel it certainly won’t harm.

Thanks to you both for the input, very interesting. I have already created an update script. How would I arrange for it to be run when Grub updates? Can I link it in somehow to software updates.

The other approach I was thinking of if it’s only a change to Grub2, I was thinking I may just freeze the Grub2 package and allow it to update once a year or so … I mean it is doing what I want now with no issues! Can you see a problem, with that approach?

My MBR TW installations have had grub* locks several years without issues. When a zypper lock contains a wildcard, and zypper offers option to “remove” lock to install/remove/update a locked package, what it really does is ignore the lock for that transaction. Such a lock remains in place until manually removed.

The problem isn’t the grub2 package itself. The problem is that when this is update, a script is run to reinstall the bootloader.

I have not tried this, but it is worth a try. Use Yast Boot Loader

There’s a selection there, between “GRUB2”, “GRUB2 for EFI” and “not managed”. Try setting it to not managed. I think, if you do this, the script that runs after grub2 updates won’t try to reinstall booting.

Doesn’t “not managed” include not regenerating grub.cfg at appropriate times, as when new kernel is installed?

Probably. I’m testing that in a VM, but it won’t be a good test until there’s a kernel update. I presume that using “grub2-mkconfig” will still update “grub.cfg”, but I need to test that, too (after the next kernel update).

Okay, I have now tested this.

Setting the boot loader to “not managed” does result in “grub.cfg” not being updated after a kernel update. However, I can still run

grub2-mkconfig -o /boot/grub2/grub.cfg

to for the update (so that the new kernel will be loaded).