Fall Creators update kills bootloader on dual boot systems

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

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!

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.