Grub cannot detect Windows 10 (UBUNTU INSTALLED FIRST)

Question

I have a Lenovo Yoga 2 pro triple booted with two Ubuntu (15.10, 14.04) and Windows 10. Initially I wiped the hard drive and installed Ubuntu. To install windows I reformatted the hard drive to GTP using gdisk and installed Windows on an ntfs partition.

(nothing was able to boot initially but I was able to boot into windows by accessing the boot menu from the novo button and choosing the windows bootloader(ubuntu bootloader was not present here and would go to black screen with blinking cursor if hard drive was chosen))

After rescue of the Grub bootloader using a live ubuntu cd, Windows does not appear. Running Boot repair detects Windows but, ends up messing up grub resulting in the computer restarting once it tries to access grub menu. The pastebin results from boot repair can be found here: http://paste.ubuntu.com/14692334/.

Running the windows repair environment from a usb is unable to fix the problem.( selecting repair boot, results in windows trying to fix the the bootloader but ends up stating that repair failed.)

The 100 Mib windows boot partition seems to be there but it is not detected.

Parted -l gives the following output (bottom), and os-prober only detects the other ubuntu installation. I also have tried to manually edit the /etc/grub.d/40_custom file to no avail. Also sudo update-grub does not yield any (useful) results.

Switching boot to UEFI from Legacy does not allow grub to be booted and still does not detect the windows bootloader. Any advice is appreciated -- Thanks

**Note I did find a similar situation here: Windows 8.1 doesn't appear in GRUB2 but yielded no results.

    Model: ATA SAMSUNG MZMTE256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name                          Flags
 1      1049kB  141GB  141GB   ext4            Linux filesystem
 2      141GB   192GB  50.9GB  ntfs            Microsoft basic data          msftdata
 3      192GB   192GB  472MB   ntfs            Basic data partition          hidden, diag
 4      192GB   193GB  105MB                   EFI system partition          boot, esp
 5      193GB   193GB  16.8MB  ntfs            Microsoft reserved partition  msftres
 7      193GB   203GB  10.2GB  ext4
 8      242GB   243GB  186MB   ext4                                          boot, esp
 6      248GB   256GB  8501MB  linux-swap(v1)  Linux swap


Model: SanDisk Cruzer Fit (scsi)
Disk /dev/sdb: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  16.0GB  16.0GB  primary  fat32        boot, lba

Answer 1

Many of your problems seem to boil down to problems with your EFI System Partition (ESP), which in your case is (or should be) /dev/sda4. The trouble is that the Boot Repair script has (mis?-)identified /dev/sda4 as holding GRUB's core.img file. OTOH, it's marked in the partition table as being an ESP. My suspicion is that one of two things has happened:

• When installing Windows, /dev/sda4 was used as the ESP, but the location of the partition happened to coincide with the location of a deleted BIOS Boot Partition, which holds GRUB 2 code for BIOS-mode boots. If Windows did not adequately wipe that old data, it might cause the filesystem to be misidentified by some Linux tools, which would result in the problem you're facing now.
• At some point after installing Windows, you or a repair utility mistakenly wrote GRUB data "raw" to /dev/sda4. The grub-install command in a BIOS/CSM/legacy-mode boot might do this, but normally only if the partition was flagged as a BIOS Boot Partition, which it currently is not. Nonetheless, this is a possibility if the GRUB data were written here in some other way or if the partition's type code was changed to that of an ESP after the grub-install error.

The first of these explanations is the one you should hope for, since it means that the FAT filesystem data should be intact. In this case, the first step to recovery is to back up the partition (you may need to explicitly specify its filesystem type to mount it in Ubuntu, as in sudo mount /dev/sda4 -t vfat /mnt), unmount it, create a fresh FAT filesystem on it (sudo mkdosfs /dev/sda4), re-mount it, and restore the backed-up files. This should then enable Boot Repair to work. Note that you can do all of this in just about any OS, although you'd have to mount the ESP first if you do it in Windows (see below).

Another path to recovery would be to use my rEFInd boot manager on a USB flash drive or CD-R. If the ESP's filesystem is readable to the firmware, rEFInd should enable you to boot either Windows or Ubuntu. You could then create an /etc/fstab entry to mount /dev/sda4 at /boot/efi and install rEFInd via its Debian package or PPA. (Alternatively, you could install the grub-efi package and set it up yourself.) By itself, though, this approach will still leave confusing data on the ESP, so tools like Boot Repair will continue to be less than useful; to fully recover, you'd need to back up the ESP, create a fresh filesystem on it, and restore it. For that matter, I'm not entirely sure that rEFInd's installation script (used in the packages) would work correctly given the misidentification of the filesystem, so you might need to fix that problem even with this solution.

If the filesystem on /dev/sda4 is so badly damaged that you can't recover its files, you'll need to create a fresh filesystem on it, use a Windows recovery disk to re-install the Windows boot loader, and then recover Ubuntu to bootability by using either Boot Repair or rEFInd.

Note that it's conceivable that the filesystem is readable in one or two environments but not all three. (The three environments being the EFI, Windows, and Ubuntu.) Windows doesn't normally mount the ESP, so you'd need to do so by typing mountvol S: /S in an Administrator Command Prompt window. (You can change S: to some other drive identifier, if you like.) Of course, your Boot Repair output already reveals that some Linux tools (like blkid) don't see a FAT filesystem on the disk, but it could still be readable by the kernel if you tell it to use the vfat driver, as in the mount /dev/sda4 -t vfat /mnt command I presented earlier.