I have 1 HDD and 1 SSD; W10 installed in SSD,Ubuntu and W10 installed in HDD.

I used to boot into w10(hdd) without grub menu,grub wasn't the main efi i guess. After the W10 updates i couldn't boot into W10 that is inside HDD.

-It initialized disk diagnosis and failed to repair. -I used boot-repair.iso through usb using rufus.Even that has failed to repair. -I tried to make the grup as prime booter.So i could choose w10(hdd) and boot normaly via grub.But there was w10(SSD) inside the grub menu,i couldn't boot into w10(HDD) via grub.

My humble opinion is,w10(HDD) boot files have been corrupted.And grub can not make any sense of w10(HDD) boot files.In other words Grub cant see w10(HDD) and yet can see w10 that is inside SDD.

Appendix: http://paste.ubuntu.com/24873778

Note : I use 2 w10 because when one of them failes,i use the other one.


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.

  • Would these processes corrupt my SSD boot? Should i copy the data into a portable drive? And how can i remove SSD boot from grub? Because Grub has SSD boot as sdb2,and i dont want that,i used to pick from setup which drive to use.How can i go back to good old days? Thanks for the great answer by the way. – Doğuş Jun 20 '17 at 16:37
  • Backing up important data is always a wise precaution before mucking around with partitions or boot loaders. It's not 100% clear to me what your original configuration was, but it was likely odd and, apparently, delicate. Thus, I don't recommend returning to it. There are many different ways to arrange boot orders, different boot loaders and boot managers, etc. Thus, it's difficult to recommend how to rearrange things to get something like what you had before. You may want to post a new question asking for advice on how to achieve a desired effect after you get things working. – Rod Smith Jun 20 '17 at 17:14

look in the /efi/boot dir of the HHD for the windows boot manager (bootx64.efi usually)

if it is't there, copy the one from the SSD to the HDD.

update grub

  • Ubuntu has no standard /efi/boot directory. If you mean /boot/efi (the ESP), then that's /dev/sdb2, which is on the SSD. There is no ESP on /dev/sda (the HDD). The EFI/BOOT/bootx64.efi file on the ESP might not be the Windows boot loader; that's the fallback filename and could be anything. (It's often, but not always, a copy of the Windows boot loader.) The Windows boot loader should be EFI/Microsoft/Boot/bootmgfw.efi. Copying that file from one ESP to another is unlikely to help, since the Windows boot process relies on configuration files that are unique for each installation. – Rod Smith Jun 17 '17 at 19:26
  • the directory n disk is /efi/boot..... which is mounted to boot/efi in linux. giving the linux path of /boot/efi/efi/boot. there should be a efi/boot/windows/bootx64.efi file. this is the one you want to copy. – ravery Jun 17 '17 at 19:48
  • **correction to previous comment-- /efi/windows/bootx64.efi copy this file to /efi/boot/bootx64.efi of internal drive – ravery Jun 17 '17 at 19:58
  • Ah, yes, EFI/BOOT on the ESP. That makes more sense, but the overall advice is still useless, since the HD has no ESP to which to copy the file, and the Windows boot loader configuration files require customization for each installation. See my analysis in my answer for details. – Rod Smith Jun 17 '17 at 20:45
  • @rod smith -- w10 is efi only. did you install ubuntu in bios mode? if this is the case, bios mode can not read a gpt disk. BOOTx64.efi is not a configuration file, it is a efi boot loader. – ravery Jun 17 '17 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.