Your configuration is very strange, probably because of actions taken in step #2 that you don't know about. In brief:
- Your disk uses the Master Boot Record (MBR) partitioning scheme.
- The MBR contains GRUB code, indicating a setup of Ubuntu to boot in BIOS/CSM/legacy mode.
- Your
/dev/sda2 is a FAT partition of a size that's common for an EFI System Partition (ESP), and it contains Windows EFI/UEFI-mode boot loader files. This is consistent with an EFI-mode boot, but such a partition is normally found on GUID Partition Table (GPT) disks, not MBR disks. (MBR and GPT are more-or-less mutually exclusive; although a combination called a "hybrid MBR" is possible, this is an ugly and dangerous hack that's mostly used on Macs.)
My suspicion is that your computer was originally installed to boot Windows in EFI mode from a GPT disk, but in step #1, you installed Ubuntu in BIOS/CSM/legacy mode. (Installing one OS in EFI mode and the other in BIOS mode is awkward at best, and usually results in problems.) Then, whoever did your step #2, not understanding the setup or how best to fix it, converted the disk from GPT to MBR and tried to get it to boot Windows in BIOS mode, but failed. Although your subsequent efforts might have worked, for whatever reason they didn't, leaving you worse off than when you began.
My first suggestion is to read my Web page on the CSM. A failure to understand the issues described on that page is likely what got you into your current predicament, and a successful recovery is dependent on either your understanding those issues or good luck. Either your CSM was enabled at the start or you enabled it to install Ubuntu, and this was a mistake, because the CSM complicates the boot path and makes possible a configuration in which one OS is installed in EFI mode and the other is installed in BIOS mode. As noted above, such a configuration is awkward to control and creates new pitfalls. Thus, I recommend you disable the CSM before doing anything else. How you do this varies from one computer to another, so I can't present specific instructions on this; you'll just have to poke around in your firmware setup tool until you find an option relating to the CSM, BIOS-mode booting, legacy-mode booting, or UEFI-mode booting and set it appropriately.
With the CSM disabled, you have two basic options:
- Re-install everything -- This is likely to be the easiest approach. You should delete all the disk's partitions, convert the disk from MBR to GPT form, re-install Windows, and finally re-install Ubuntu. As noted on my CSM page, referenced earlier, you may need to take care to create EFI-bootable installation media for both Windows and Ubuntu. (See here for instructions on installing Windows 7 in EFI mode.)
- Repair what you've got -- In theory, you can repair the current configuration to boot in EFI mode. This will require converting from MBR to GPT in a non-destructive way (you can use my GPT fdisk (
gdisk)) tool to do this -- it comes with Ubuntu). With that done, you can run Boot Repair from an EFI-mode boot; or use my rEFInd boot manager on a USB drive or CD-R to boot once and then install rEFInd's Debian package or PPA. With any luck your current Windows boot loader will then work well enough to boot Windows; but if not, you may need to repair it. Perhaps you could use part of this procedure to do the job, or you might have to ask on a Windows forum for detailed instructions.
An alternative would be to leave the computer's CSM enabled and try to get it booting in BIOS mode. Since GRUB is starting already, Boot Repair won't really help, at least not initially; you must install a BIOS-mode version of the Windows boot loader -- but I'm not an expert on Windows recovery, so you may need to ask on a Windows forum about that. Also, installing a BIOS-mode Windows boot loader is likely to partially wipe out GRUB, necessitating re-installing it -- which is most easily done with Boot Repair, which you say is thinking it must boot in EFI mode. My suspicion is that this is because it's seeing /dev/sda2 and interpreting it as an ESP. If so, deleting that partition might help; but of course if you get this far, you'll have a working Windows, and there's a slim chance that deleting /dev/sda2 might make it fail. Thus, in addition to the usual CSM pitfalls, this procedure runs the risk of creating new problems once you fix one of your current ones -- or maybe even creating new problems while not fixing the current one.
