Dual boot not working

Today, I had occasion to install Leap 15.2 on a friends machine. The opensuse installation went well and is up and running just fine. However, Windows will not start from the grub menu.

The machine in question has Windows 10 installed on two drives, A small SSD for the system and a larger mechanical drive for data. The original installation of Windows was made using a MBR system rather than EUFI. The linux installation insisted that I install it using a MBR system as well.

When the linux installation was finished, I rebooted the machine and it went directly to Windows. So I went into the bios and changed the priority of the boot drive and rebooted. This time grub came up as expected. At the grub prompt, I selected openSUSE and it worked as expected. However, rebooting and selecting Windows, the system will not boot and shows an error that the drive, and a number which I didn’t record, is not available. As I’m not familiar with a MBR boot system and it was getting late, I didn’t go any further. I can go to the bios of that machine and select the Windows drive as the boot drive and Windows boots up properly so it’s not an emergency situation.

I thought grub went into the UEFI section of the bios and changed the order of the drives. But, there has to be more to it than that.

So, is it possible to use grub to dual boot a system like this? If so, then the number shown, unlike anything I have seen, must be in error and the cause of the error. Should I try reinstalling grub? I am a loss. Suggestions?


I guess people really need something like

fdisk -l


lsblk -f

(as root) with some explanation to what you think is to be used for what to be able to help efficiently.
Also “a number which I didn’t record” hints to you thinking that people here are so clairvoyant that they know. This is not the case.

And for your own better understanding: a system may be able to use EFI or not, but once that choice is made, it will be used for all booting. So when the system does use traditional booting of Windows, the installer should be booted in the same way and openSUSE will of course be installed also in the same way and you can forget everything you may know about EFI in handling that system.

Also "a number which I didn't record" hints to you thinking that people  here are so clairvoyant that they know. This is not the case.

Thanks for your quick reply and suggestions to start tracking the problem.

That number was presented as a drive number. It didn’t seem to be helpful to post as it referred to a drive specific to this machine. I’ll follow your suggestions and if it becomes relevant to the information provided by your suggestion, I’ll be happy to post it.

You did point out a possibility though. I didn’t think Win 10 could be installed non EFI. About all I care to know about Windows is that it has 4 little blue squares on the screen at boot and how to shut it down. I booted the installation from a DVD and it decided to use EFI. I only noticed the problem when I created the partitions on the linux drive and had to change them to MBR.

I have to see the Doctor tomorrow and am not sure I’ll be fit to pursue this for a few days. So, I’ll not be ignoring any help I can get. I’ll be back as soon as I’m able. Enjoy your 40s and 50s cause in your 60s, that “Check Engine” light will come on! And it seems like it only gets worse from there!


People need every bit of information, even if it seems irrelevant to you. Better let the people who try to help you decide how important it is.

I do not understand you here. You said in post #1 above:

The original installation of Windows was made using a MBR system rather than EUFI.

So IMHO, you not only thought that Win 10 can be installed non EFI, you were already sure it was!

For the rest I know nothing about Windows, thus the story about “4 little blue squares” says me nothing. But there may be other members here that occasionally use Windows.

Boot to openSUSE and two things to check when you have a chance, run the command (as root user) os-prober. If this see the windows drive then go into YaST → bootloader and check that probe foreign os box is checked. This should sort grub out…

This isn’t a bad suggestion . . . but from my own experience running multi-boot installs, grub is able to find and boot linux distros, but unless you go into /etc/grub/default.config ??? (i just made that up from memory, so that file that has all of the UUI (again I made that up, but it’s close) location numbers and hook them up for windows or in my case OSX . . . grub won’t boot them, or rather it won’t boot OSX, so I’m assuming that for a box stock grub install it’s only going to boot the linux options.

Again, from my experience with linux around OSX, whenever there is an update it breaks the UUII??? locations of the linux installs, and that can be somewhat time consuming to get everything back in order in grub . . . so far OpenSUSE “os-prober” as malcolm mentions has been the best at fixing that . . . for linux.

But, in my case where I have a bunch of OSX iterations and a bunch of linux distros spread across two drives, I use grub to boot the linux options, and if and when I want OSX I use a keystroke to bring up the OSX boot manger to then select OSX. Because the systems are somewhat “dynamic” I haven’t wasted time trying to get grub to boot OSX, it shows a couple of OSX options, but if I select them it errors out.

It’s one of the “joys” of dual/multi-booting . . . often the “two worlds” don’t play well with each other . . . if you have grub set to boot OpenSUSE and that is the primetime player, then just use f9 or whatever brings up the BIOS to boot windows would be my offering to this thread.


Before we get any further, I second hcvv in request for fdisk -l output. This will clarify a lot.
Right now I think the following thing has happened: Winfows 10 is installed on GPT+UEFI (“system”) drive and Leap is installed on another (“data”) drive, which happens to be MBR and had no influence on Windows booting process. Since Leap was being installed on MBR, installer itself insisted on changing the grub variant to mbr instead of uefi (even though I believe the installer itself started in uefi mode) - and now you have two incompatible booting processes involved. The easiest solution would be to actually select the boot drive in “bios”, cause grub-mbr is not able to boot uefi-based Windows installation.
Please remember that this was all a wild guess and we still need fdisk -l output to confirm.

For UEFI: try to use rEFInd or another boot manager.

For old non-UEFI system: GRUB works with Linux + Windows well.
Just follow Malcolm Lewis’s recommendations.

Sorry for the long delay in getting back. My second Covid shot took nearly a week before I felt anywhere normal.

Anyway, what I figure was wrong was that I booted the linux installation as EUFI without checking how Windows was installed. As I stated. I had never seen a non-ufi installation of Windows. While configuring the partitions for linux, the installation program told me I could not do that, so I changed the linux partition to use MBR. I think the the installation program still looked for a UFI boot process for Windows and wouldn’t boot it properly.

I ran grub2-mkconfig and all is now well. Problem solved. Thanks all for your help and suggestions.