I’m trying to use the Windows booting mechanism so I can install the windows update KB3033929.
I followed the directions given elsewhere to use fdisk to toggle the bootable flag off and then toggle it on for another partition.
Since installing Suse 13.1, the flag has been on for /dev/sda3, and I have been able to dual boot without problems.
So I used fdisk to turn off the flag for /dev/sda3, then turn in on for /dev/sda1. But I still got the Grub menu.
Then I set the flags to boot from /dev/sda2 and again got the Grub menu.
Then I turned off all the flag and still got the Grub menu.
Here is part of the output of fdisk:
Disk label type: dos
Device Boot Start End Blocks Id System
/dev/sda1 2048 616447 307200 7 HPFS/NTFS/exFAT
/dev/sda2 616448 451176447 225280000 7 HPFS/NTFS/exFAT
/dev/sda3 * 451176448 614646899 81735226 5 Extended
/dev/sda4 614649856 625125375 5237760 c W95 FAT32 (LBA)
/dev/sda5 451178496 501510143 25165824 83 Linux
/dev/sda6 501512192 509900799 4194304 82 Linux swap / Solaris
/dev/sda7 509902848 597610495 43853824 83 Linux
/dev/sda8 597612544 614646899 8517178 83 Linux
/dev/sda5 is /, /dev/sda7 is /home, and /dev/sda8 is not mounted.
/etc/default/grub_installdevice contains
/dev/disk/by-id/ata-WDC_WD3200BEKT...........-part3
activate
How should I set things up temporarily so that I can apply the Windows patch? TIA
If grub (or grub2) was installed in the MBR, then you will always get the grub menu. It doesn’t depend on the active bit.
Try setting the active bit on partition 1 (/dev/sda1) and turn it off for partition 3. Then, if you still get the grub menu, select Windows to boot. I’m not sure, because I have not heard any reports on this. But selecting Windows with the Windows partition active, might be sufficient. If Windows reboots, still select Windows. (Ok, if it happens too many times, you might still be in a reboot loop.)
If that doesn’t work, then the alternative is to put Windows boot code back in the MBR.
Here’s what this is probably about.
Some Windows updates want to verify that booting will work correctly. And to do that, they check the BCD (Boot Configuration Data). But you can have more than one BCD file. Windows use the active bit to decide which one is relevant.
Having the Windows boot partition as active, and then booting Windows, are probably all that is required.
Thanks for your reply.
One thing I forgot to mention is that the boot menu has always given me four choices: opensuse 13.1, advanced options for opensuse 13.1, Windows (loader) (on /dev/sda1), and Windows (loader) (on /dev/sda2). IDK whether that would matter.
Which of those do you normally use? (Rhetorical question - no need to answer).
Whichever you normally use, make that the active partition (with “fdisk”), then boot that one. Then see if you can complete that Windows update.
Report back how it went. Other users might find this a useful reference.
No does not matter. One of those Windows items is a recovery partition. Has nothing to do with boot flags and it looks like you installed grub to the MBR rather then leaving Windows boot code or specifying generic at install.
MBR Boot works like this. at power up BIOS reads the code at the fist sector of the first track of the boot drive. It then runs that code. Generic and Windows MBR code looks for the boot flag and continues the boot at that location. Grub MBR code knows where the boot partition is and goes straight there. What is in the grub menu is immaterial because all this happens well before the grub menu is read and displayed.
It’s always booted into 13.1 if I don’t press a key pretty soon in booting. But I’ve always taken the sda1 option for booting windows (7 by they way).
Okay, as suggested, I did set the flag on sda1 and turned all the others off. Then I booted, choosing sda1 from the boot menu. I ran Windows Update, and it tried to apply two updates, but one of them failed. Then I rebooted into 13.1 and changed the flag from sda1 to sda2 and booted, choosing the sda2 option. I think Windows reverted the changes upon rebooting, not sure. However, when checking the update history, I found that KB3033929 was installed successfully. So that part was good, thanks! But now I find that Microsoft .NET Framework 4.5.2 for Windows 7 x64-based Systems (KB2901983) failed to install. I’m looking into that now.
Thank you for your help, nrickert and gogalthorp. It looks like that KB3033929 problem is out of the way.
This other update failure has me a little worried though; I’ve tried a few things that didn’t work, and I wonder whether it’s related to the boot situation.
Can’t imagine .NET having anything at all to do with booting. But then this is Windows you never know. In any case it is a Windows problem not a Linux or dual boot problem