Fall Creators update kills bootloader on dual boot systems

OK, Microsoft....you say that you are making peace with and coexisting with Linux.

However, you still don't play nice with it.  :-(

For years, we all knew that you had to install Windows first because you didn't play nice with others, then install Linux afterward, with its GRUB bootloader that lets you boot just about any OS.

Well, I made the mistake of allowing the Windows 10 Fall Creators update to happen on my laptop while I was away on a business trip...without my SystemRescue USB drive or Linux live CD.  You guys killed my GRUB bootloader, and I can't fix it until I get home.  This cost me a day's worth of work fixing a couple of remote co-located servers, since all of the tools I need for this run under Linux.

I took a look at the EFI partition with bcdedit /enum firmware, and it seems that you apparently overwrote GRUB in my \EFI\ubuntu partition - since I tried using bcdedit set to change between the filenames in the \EFI\ubuntu partition (which is first in the boot order) - still goes straight to Windows.  Tried doing the same with a third-party utility called EasyUEFI.  No joy.

Can't you set up the Windows Boot Manager in another directory in the EFI partition and (if you must), just point to it instead??

Or, if you have to modify the bootloader to allow for the several reboots during the upgrade, just store the original setup, then restore it when the upgrade finishes?

Better yet, just let me use GRUB to boot into Windows after each step of the upgrade.  

For next time, please consider this instead, and learn to play nice with others!  We know you can, if you decide that you want to...!

Thanks.

 

Discussion Info


Last updated October 4, 2019 Views 4,716 Applies to:

It appears to me that they changed it in a way that the upgrade doesn't work, at least for my config.

I have a dual boot system setup (Win10 & Arch Linux) using Terabyte BootIt  Bare Metal. Win 10 has repeatedly downloaded and applied the update and performs the pre shutdown part successfully, but when it reboots the first time and I select Windows from BootIt Bare Metal boot menu during the upgrade, I get a nearly immediate reboot back to BootIt Bare Metal. When I select Windows from the BootIt Bare Metal menu again, it reverses the upgrade and tell me that it failed with an error code that doesn't lead to any useful information.

Gary

By the way, I've also tried the upgrade assistant and the media creation tool. Same results.

I echo that. Fall Creator update killed my grub2 boot loader and I can no longer boot into Ubuntu.

I've booted to a live USB and tried the old Boot Repair  method and that failed. Twice.

This is your problem to solve Microsoft!

And another thing. It's autumn not fall.

This is really annoying, I have exactly the same problem. It's time to switch to Linux fully and put windows in a VM. At least they won't be able to change YOUR SYSTEM as they want without any warning. 

Microsoft is just pretending that they are friendly with Linux users. In the end, they want to sell more windows copies and kill Linux is a way to expand their territory.

Hi,

have you checked if the update reactivated fastboot ? It did on my computer, and I think it would prevent you from booting on linux.

Having now updated a number of dual-boot systems, I've found that it only seems to happen on systems that use EFI to boot.  Old-school MBR systems don't seem to have this issue.  On my EFI machines, I used the Ubuntu live CD to reinstall grub2 on Ubuntu machines, but with other distros, their live-install discs should work, or use System Rescue CD.

Here's a guide for Ubuntu:

https://askubuntu.com/questions/83771/recovering-grub-after-installing-windows-7   (works with 10 also)

@Microsoft:  This doesn't absolve you of the responsibility to play nice with others!

I'm pretty sure that it did not reenable fast boot. If it did for the first reboot in the upgrade process then I disabled it again with Terabyte Unlimited's BootIt Bare Metal (BootIt BM). I use BootIt BM as my boot manager and partition manager. BootIt BM's menu allows me to choose which OS to boot each boot cycle.

For the Fall Creators Update, it repeatedly tried and failed to complete the upgrade for a couple of months. Every time it tried to perform the upgrade, it would install the preboot portion of the upgrade without error and during shutdown would run that portion of the process without an issue. However, when it rebooted the first time, it would start to put up Please Wait blue screen followed by an immediate additional reboot. During the next Windows boot cycle, it would say that an error occurred during the update process and then would back out the completed portion of the update.

Finally, I downloaded the current installation disc ISO and created a bootable USB drive with the ISO on it. After booting that USB Drive the upgrade was able to work, although intervention was still required. The Windows upgrade process doesn't like the fact that the Windows bootloader is not on the physical drive's boot sector and creates a new WinPE partition from the end of my system partition for its bootloader. The first time that the upgrade process reboots, I make sure that it boots BootIt BM (sometimes requires reboot from USB drive with BootIt BM installation media) and I check that fast boot is still disabled, delete the WinPE partition, resize the system partition to reclaim the drive space, and rewrite a Win7 master boot record onto the Windows system partition. For the Fall Creators Update from the ISO, it rebooted properly several times during the upgrade after the intervention on the first reboot.

After the Fall Creators was complete, I thought that everything was correctly configured. However, when I attempted to reboot Linux (Arch Linux with KDE), it turned out that the Windows upgrade process had written over the GRUB2 configuration in the master boot record on my EXT4 Linux root partition, even though my  BootIt BM configuration normally hides that partition when booting to Windows (and it hides the Windows system partition when booting to Linux). It apparently did not mess with anything else on the Linux root partition, because I did get the GRUB rescue console and was able to boot to Linux after telling Grub where to find the system. I then rebuilt the GRUB config file and everything works properly now.

My system is a regular BIOS system, it is not UEFI. My current motherboard is UEFI capable, but since the dual boot configuration was originally Windows 7 & Kubuntu, I have kept it a BIOS system. Every single major upgrade has clobbered the dual boot configuration in one way or another: Win 7 => Win 8.0, Win 8.0 => Win 8.1, Win 8.1 => Win 10 version 1507, 1507 => 1511, 1511 => 1607, 1607 => 1703, & 1703 => 1709.