You've got a complex setup:
/dev/sda is partitioned using the old Master Boot Record (MBR) method, has a BIOS-mode Windows boot loader installed in its MBR, and appears to hold both Windows and Ubuntu installations. Based on its size, I'm guessing this is the HDD to which you referred.
/dev/sdb is partitioned using the new GUID Partition Table (GPT) system, has a BIOS-mode Windows boot loader in its MBR, has an EFI-mode Windows boot loader on its
/dev/sdb2, has an EFI-mode GRUB (Ubuntu boot loader) on its
/dev/sdb2, and seems to hold a Windows installation. Based on its size, I'm guessing this is your SSD.
/dev/sde looks like a bootable USB drive with an Ubuntu (or other Linux) installer on it. I'm therefore ignoring it.
/dev/sdf is partitioned using GPT and has what looks like an NTFS data partition with no OS installed on it. As it doesn't seem to be a boot disk, I'm ignoring it.
This is complex and complicated because Windows ties its boot mode to its partition table type: On MBR disks, Windows boots only in BIOS/CSM/legacy mode; and on GPT disks, Windows boots only in EFI/UEFI mode. You've also got both BIOS-mode and EFI-mode Windows boot loaders on your disks. This suggests a BIOS-mode Windows installation on
/dev/sda and an EFI-mode Windows installation on
/dev/sdb. (I'm guessing that the BIOS-mode Windows boot loader on your GPT
/dev/sdb is either left over from a previous installation or was accidentally installed to the wrong disk.) There's no sign of a BIOS-mode GRUB, but there is an EFI-mode GRUB on
/dev/sdb2; but the bulk of Ubuntu seems to be installed on
/dev/sda. Ubuntu is much less rigid in its linkage of partition table types and boot-mode styles, so the Ubuntu configuration, although unconventional, is not puzzling.
Note that switching between OSes installed in the two boot modes (BIOS and EFI) is tricky. You must normally use the firmware's built-in boot manager, which is usually awkward. My suspicion is that this is what you were doing; but the update broke something; perhaps it got confused because of the mixture of MBR and GPT disks and the multi-boot configuration. Note that the EFI-mode GRUB cannot redirect the boot process to boot your BIOS-mode Windows installation, but it can redirect to boot your EFI-mode Windows installation.
One caveat to the preceding analysis is that I don't know if an EFI-mode Windows boot loader, installed to the ESP on a GPT disk, could boot a Windows installation on an MBR disk. If it can, then my analysis may be a bit off; you might have been booting both Windows installations through the EFI-mode Windows boot loader. If you're certain that you could once boot both Windows versions through GRUB, then this was probably happening, but the Windows boot loader update probably changed the Windows configuration in some way that broke the ability of the EFI-mode boot loader to boot the OS.
I have two suggestions for how to proceed with a repair. Neither is guaranteed to work; in fact, they're both long shots. Thus, I STRONGLY recommend you back up your important data and be prepared to do a full re-install of the non-working Windows installation. My two ideas are:
- Use rEFInd to redirect to a BIOS-mode boot -- My rEFInd boot manager can redirect from an EFI-mode to a BIOS-mode boot. You could obtain the USB flash drive version from the rEFInd downloads page, prepare a medium with it, and edit
EFI/BOOT/refind.conf on the USB drive: Uncomment the
scanfor line and ensure that
hdbios is among the options. This should enable rEFInd to boot Ubuntu, the Windows on the GPT disk (via the Windows icon), or the BIOS-mode Windows on the hard disk (via the gray diamond-shaped icon). If this works, you could install rEFInd to the hard disk by installing the Debian package or PPA, make the same change to
/boot/efi/EFI/refind/refind.conf (in Ubuntu), and use rEFInd as your default boot program. This method is most likely to be helpful if you had been booting both Windows versions through a single Windows boot loader. In this scenario, the update changed the HDD Windows to expect to boot in BIOS mode, and rEFInd will do this.
- Convert your HDD Windows install to GPT and EFI-mode booting -- This blog post describes how to convert Windows to boot in EFI mode from a GPT disk rather than in BIOS mode from an MBR disk. (The new Windows MBR2GPT program will do the same thing in an automated way, but I'm not at all sure how well it would work on your complex triple-boot setup.) If you apply this method to your existing setup, it might get Windows on the first disk booting again. Note, however, that the system will probably boot straight to that Windows. You'll need to use EasyUEFI to adjust the boot order to make GRUB (
ubuntu) the default boot loader again; and after that, you may need to type
sudo update-grub in Ubuntu to ensure that GRUB's menu has been suitably updated. This method is most likely to be helpful if you had been picking your Windows version through the firmware's built-in boot manager before you hit GRUB. In this scenario, you probably need to bring more consistency to the configuration, and that means converting everything to boot in EFI mode from GPT disks.
As I said, neither of these approaches is guaranteed to work, and either could make matters worse. Trying rEFInd on a USB flash drive is quite low in risk; and if it works, installing it to the hard disk is also unlikely to create new problems, although there are ways in which the rEFInd installation might fail. Converting Windows from BIOS-mode to EFI-mode booting is much riskier.