Windows 8.1, KB4019215 and KB4019114
I don’t often post about Windows, because I mainly use linux. But this is a Windows post. I should mention that the computer involved is a UEFI box, since that might be relevant.
My main desktop has both Windows 8.1 and openSUSE 42.2. On Friday, I attempted to install the May updates for Windows. The updates are the two listed in the subject line above.
The updates failed.
They seemed succeed. I got the message to restart windows to complete the update. So I rebooted. Then I saw the messages about “working with updates”. At around the 30% mark, it rebooted. Then, on reboot, it continued until the 100% mark. That looked good.
But then a message:
We couldn’t complete the updates
Don’t turn off your computer
And then another reboot. And, on checking, those two updates were listed as failed.
This morning, I tried again. And this time the update succeeded. I’m not quite sure what the difference was, though I do have a guess. So I’m posting this for the benefit of others who might be having the same problem.
I’ll note that after Friday’s failure, I did a google search. I did find a few mentions of the same problem. I did not see a solution. My guess is that relatively few people are having the same problem.
This morning it was time for me to boot to Windows. I do that twice per week, mainly to keep Windows and its anti-virus reasonably up-to-date.
So what did I do differently:
- Before booting to Windows, I changed the boot configuration of the computer. Normally, I have it boot to openSUSE. That gives me a boot menu where I can choose Windows if I like, though the default is linux. So I changed the boot configuration to make Windows the primary operating system that automatically boots. I did this with BIOS settings, though I could just as easily have done it from linux, with “efibootmgr -o x y” to set the boot order.
- This time I applied the updates one at a time. I went into Windows update, and unchecked everything except KB4019215. Then I applied the update, and did the restart that called for. That worked. Then I went to Windows update again, and applied the other “important” update (KB4019114). And that also worked.
Why my guess?
There’s actually another possible explanation. It is possible that Windows fixed their update over the weekend.
So I cannot be sure what changed. But I think my guess is the most likely. And my guess is that the change in boot configuration was what made the difference.
I’ve seen this update behavior before. I saw it with Windows Vista. I saw it with Windows 8.1. I managed to escape the problem with Windows 7, based on what I had learned with Vista.
On previous occasions, this always had to do with booting. It seems that when an update affects booting, Windows does some checking of the boot path before finally accepting the update. And if it cannot verify the boot path, it removes that update. And, of course, my system was set to boot linux by default. So Windows could not verify the boot path.
One would think that, since the system successfully booted, that would be enough to verify the boot path. But apparently, that isn’t the logic that Windows uses.
Rebooting to linux
Having completed the updates, I now had to reboot to linux.
There’s a problem here. Booting to linux, I get a menu where I can select Windows. But when the system is set to boot Windows, there is no menu.
Fortunately, I can force a menu. If I hit F12 during boot, the BIOS presents a boot menu. And, from there, I can select to boot openSUSE. And, once in openSUSE, I can use “efibootmgr” to change the boot order to put openSUSE first.
Actually, I did it a little differently. During boot I hit F2. That took me to a BIOS settings screen. And there, I was able to change the boot order to put openSUSE first.
So all’s well that ends well.