GRUB won't boot Windows 10

I was going to replace my old hdd with a larger one, and I used dd to clone the entire drive. After cloning and replacing the hdds, I was able to boot into Windows 10 but not openSUSE. Henceforth, I took the below steps to make openSUSE bootable without checking windows boot-ability; so I don’t know at which step things went wrong. Here are what I’ve done:

  1. Updated grub from a live environment, which made openSUSE bootable but Windows disapeared from GRUB menu.
  2. Used gparted auto-scanning to fix GPT-table issues due to hdd-cloning, which made new free space available.
  3. Enlarged my LUKS LVM by creating a new partition after the Windows partition and using the LVM features to span across the disk (enlarging without adjacent free space).
  4. Updating GRUB from inside the openSUSE with os-probing enabled, which made Windows appear in the GRUB menu BUT not bootable.

Here is my current setup:

/dev/sda1 EFI boot
/dev/sda2 LUKS LVM (openSUSE)
/dev/sda3 Windows Reserved
/dev/sda4 NTFS (Windows 10)
/dev/sda5 LUKS LVM (used to enlarge to the first LVM)

What can I do to make Windows bootable?

Can you boot to Windows via the EFI boot menu at machine boot?

check files in /boot/efi to be sure the windows boot stuff is still there

You mean via GRUB boot menu? As I mentioned, I tried with no success. Windows is not bootable while openSUSE is.

Yes, the files are still there.

I have to mention that I also tried disabling secure boot and still was not able to boot to Windows.

No I mean the BIOE/EFI boot menu

Well, I’m not sure if I have such option! Any special way to activate it? Because when I googled it, they just mentioned pressing F2 and Del, which in my case just bring about BIOS.

If this is an UEFI machine and it seems to be then should be a hot key at boot but different machine may use different keys some common ones are F10 or F12 but may be different. Often the splash screen shows option keys if not dig out machines docs

Then it just seems to be legacy bios with secure boot support.

I wonder if it did not change GUIDs in partition table. I would try Windows recovery first.

Wouldn’t Windows recovery just overwrite the grub? I really don’t wish to do so. I would prefer a Linux-native solution. Doesn’t matter if it’s the hard way. I guess I will learn some new stuffs during the process, and I love learning.

But you say you have an EFI boot partition this does not exist for legacy BIOS. Also never heard of secure boot on a BIOS only on UEFI. If UEFI then you should have a boot menu to select OS and determine boot method. Trouble is that the hot key is not standard and depends on the hardware.

Both OS must boot using the same method in order to chain from one to the other. You can’t have one OS boot in legacy mode and the other in EFI. Won’t work.

To install for EFI boot you must boot the installer in EFI mode. If not it installs MBR boot. If you have a /boot/efi directory then openSUSE is installed to use EFI boot. If not there it is set to boot MBR/legacy

OH MY GOD I WAS JUST SO DUMB. After cloning my hdd and trying to fix the issues that followed, I discovered if I press F12 during boot, a menu would appear that let me choose which device to boot from. I thought that was just a shortcut to avoid the hassle of changing the boot order from BIOS. I used that to boot from my live cd SO AS TO REBUILD MY GOD**** GRUB.

And now after reading what you mentioned about EFI boot menu and the consistency required for chainloading, it just occurred to me maybe that’s the root of the problem.

So regarding your question… yes, I have /boot/efi/EFI and there I can see folders for both opensuse and Microsoft. One thing is the contents in /boot/efi/EFI/opensuse/grub.cfg are not similar to what’s in /boot/grub2/grub.cfg. But I guess that’s supposed to be so.

In any case, I guess I probably had installed Windows 10 (and openSUSE) on bios mode, and now rebuilding grub from EFI mode has caused problems for Windows. This is just a theory and I’m going to start messing around with it.

Thank you gogalthorp. Please let me know any other information you think relevant.

If you see both openSUSE and Windows directories in /boot/efi then both at least at one time were set to boot EFI. openSUSE for sure is since the directory exists. it would not on an MBR boot set up

So could you boot Windows from efi boot menu?

Was Windows an option?? It could be that the UEFI flash is not right.

efibootmgr can be used to mode the flash entries. See man efibootmgr for details

Well, Windows was an option but it didn’t boot. I didn’t notice any difference in booting, so I’m thinking maybe it is not an entirely different menu considering the top title just reads “Boot Menu.” Maybe it’s just the same shortcut menu that I thought.

I will look into that. Thank you.

However… I’m thinking arvidjaar was making a point:

[quote=“arvidjaar,post:8,topic:120571”]

I wonder if it did not change GUIDs in partition table. I would try Windows recovery first.[/QUOTE]

When I opened gparted after placing the new HDD in, it informed me about two problems: the first one was something like “the backup is not placed at the end of the disk” and the second one was about “not all the free space is available to system” Considering that on the previous HDD, Windows was the last partition, it seems possible that the operation done by gparted has modified the partition info related to Windows.

I’m going to do more research on this. Any ideas are hugely welcomed.

Alright, the problem is resolved. Somewhere along the way, GPT had turned into Hybrid-MBR. I used gdisk to set the protective flag on and now I have bootable Windows and openSUSE. I should mention that I have done a huge lot of things in the meanwhile. So while I’m not sure Hybrid-MBR was the only cause of the problem, I can say that it was the last thing that made everything work.

This means at some point you installed one or the other OS was installed MBR boot. GPT supports both EFI and MBR boot but you can not chain between OS’s if they use different boot methods.

Yes that must be the case. Thanks, especially for the notes about chainloader.