I'm going to answer myself although I'm open to more suggestions on a proper fix.

My laptop is dual-boot Linux and Windows - Linux being my OS of choice but since I got the laptop with a Win10 license I'm keeping it too. Each OS has its own dedicated partition, Linux detects the Windows one and setups GRUB with dual boot options (always boots last pick). The MBR is standard with the only change being after the Windows install I set the Linux partition back to Active so GRUB can present the choices.

For a long time I've had this issue that after the initial install, the next Cumulative Update would fail. I've tried reinstalling fresh, stuck to Windows Updates drivers only, etc. Eventually the next Cumulative Update would get shipped and laptop would fail to update again. I looked at all troubleshooting option, skimmed through the WU logs, tried all possible fixes out there (rebuilding WU catalog, etc.) but nothing worked.

The symptoms were WU reporting an error during the update phase following the first reboot and rebooting again to undo the update. The latest reported error codes in the updates history were 0x800f0922 and 0x80070643 (I could get alternatively either one for the same update - the last failed ones were 2018-11, 2019-01 and 2019-02).

As it turns out all I had to do was make Windows partition active again before reboot and the update went through. Besides pointing out how ridiculous this is, I'm wondering if there could be ways to avoid this, ex add hooks to set active partition before reboot following a WU install and back afterward, or verified Windows bootloader configuration that would provide similar behavior (allow selecting OS at boot and making last choice the default). I would also hope someone from MS sees this and either fix it or at least improve error reporting do ppl don't spend months/years figuring it out.

  • A also noticed one weird thing lately... It appears shutdown is also affected by the active flag; when windows isn't active instead of shutting down it just logs out (if logged in), blanks momentarily and return to the login screen (not even rebooting). Reboot/Sleep works as usual though. I'm not sure if it's a new behavior as I almost never shutdown - either reboot or put to sleep. Feb 26 '20 at 10:50

So the fix where you have Linux/Windows dual boot using standard DOS MBR and GRUB on the Linux partition set active to perform OS selection is to set the Windows partition active before reboot after installing Windows Updates and set it back to Linux afterward.

My Windows partition is the 2nd and Linux is 3rd partition, so I created these two DISKPART scripts (The DRTAIL command is only to verify it's the right partition, can be removed):





I have a cmd file that runs this:


DISKPART /S C:\diskpart_p%1.txt

Finally with a pair of shortcuts I run the command with the right partition. The shortcut is configured to run as Administrator.


C:\Toggle_Partition.cmd 2


C:\Toggle_Partition.cmd 3

For the sake of future readers:

Install Grub2 1. stage into the MBR not into the Linux partition.

Leave active flag on the Windows partition.

The bootmanager of Windows becomes active then. Create an entry like 'bcdboot c:\windows /s c: /f BIOS' Delete other entrys with bcdedit or easyBCD.

  • Wouldn't Windows then wipe Grub every once in a while? Then I have to boot Linux from a recovery CD and reinstall it. My method allow restoring Grub easily even from Windows. It's just sad Windows fails in such an obscure way when it's partition isn't active. Feb 21 '20 at 15:16
  • This is not my experience. Unless Windows becomes installed from scratch it never touches the MBR. It only insists on the active flag pointing to the win partition. In fact the user has to to get involved if the MBR is broken.
    – Dieter
    Feb 26 '20 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.