Update grub bootsector file for Windows 7 after updating outdated softwares

Before Microsoft released an update for Windows 7 that “fixed” a bootloader issue, I used grub as my primary bootloader, and did not bothered to setup Windows bootloader to be able to load grub. After that, I made Windows loader to be primary, and both Windows and grub can load each others boot loader (in case of an emergency) with the use of a mbr file for Windows. This caused only minor problem due to the rare updates that grub version came with.

However, in openSUSE 12.3 with the new grub loader, almost every time I update the outdated software I need to recreate the mbr file for Windows to be able to load grub, and only notice that after I restart, which is greatly annoying. (Lately I rarely boot in to Linux because my work—& games :P—requires Windows.)

I also see, that yast software manager runs scripts after installation finishes. Is there a way to run additional script there that will update the mbr file (running ‘dd if=/dev/sda3 of=/windows/C/opensuse.bin count=1’) every time I installed something. It would be better if this would only occur when a critical component regarding the mbr is updated. If there is a way to detect at least the version of those component I could solve this as well on top of my primary question.

I do not know about yast, but it is possible to create RPM that contains trigger which executes script every time grub is updated.

I have been complaining about this in bug reports, most recently in the discussion of bug 812266.

Somebody has decided that grub2 should be reinstalled whenever “mkinitrd” is run.

That means that your booting is messed up whenever there is a kernel update or an update to other software that goes into the “initrd” and requires an “initrd” rebuild. I find this annoying and unnecessary. When there’s a bug fix in grub itself, it makes sense to reinstall grub. When the computer user has a reason to reinstall grub, it makes sense. But routinely reinstalling grub for kernel updates makes no sense. That was needed back in the days of lilo. It was said to be one of the benefits of grub, that you did not need to repeatedly reinstall it. As far as I know (and I could be wrong), opensuse is the only distro that does this.

#end rant

That was informative, sad and good to know. I hope it is fixed in the somewhat near future.

On the other hand I’m interested, and all ears about how the RPM trigger works. If I need to maintain my own repository or install it every time when updates arrive, it isn’t really a solution. (it would be easier to run dd by hand every time, but should keep in mind as well.)

This probably won’t really help right now (unless you can identify every package that calls mkinitrd/update-bootloader during installation). There are changes to perl-Bootloader to not reinstall grub2 during --refresh (which is used by mkinitrd) but they are not yet included in package. I hope they appear in 13.1 though.

Anyway, RPM trigggers are described here: rpm: Trigger scriptlets If you are going to try it, questions should probably go into development forum.

If mkinitrd is the process that forces the update in the boot sector, what if it is replaced with a script (with an alias) that after it calls mkinitrd it will update the mbr file, like so:

# there is a command that will make sure that the mkinitrd that is used is the mkinitrd that is the tool, and not this script. (Find it while looking for something about mc.)
mkinitrd "$@"
dd if=/dev/sda3 of=/windows/C/opensuse.bin count=1

Maybe this will be the last thing I try, due to it is very risky.

It is actually update-bootloader script (which at the end calls grub2-install - grub2-bios-setup). Usually it is not called directly, except during grub2 update.

You may be interested in this post: Format option for chainloading GRUB from BOOTMGR. Instead of copying single sector with hardcoded disk location you apparently can simply load whole core.img at once and avoid this problem altogether. This is immune to any subsequent call to mkinitrd and you only need to repeat it when grub2 is updated. Which can be implemented via e.g. RPM triggers.

I would try using /boot/grub2/i386-pc/core.img though instead of building it manually. It already has all required information and modules. You should just need to prepend lnxboot.img. Unfortunately I do not have dual boot systems to test.

I tested it and it works fine with one gotcha - when you install grub on the same disk where /boot/grub2 is located (common case when installing on boot partition) grub2 generates core.img that does not search for partition UUID, rather it simply assumes that boot drive is correct. This breaks if Windows is on another hard disk.