Dual boot with Win 10 failed after conversion to UEFI

G’day all,

I am the happy owner of a Dell Latitude E6530 (from 2012). Back in those days, it sported a 550 GB HDD and came with Windoze 7 Pro pre-installed. To remain happy, I installed openSUSE in dual boot.
In those days, it was set up with (legacy) BIOS.
Late last year I received a 500GB SSD, so I swapped the HDD. OpenSuse has in the meantime been updated to Leap 15.0 and Windoze to Ver. 10 Pro. All through clean installs and without significant problems.
Starting all over with a blank SSD, I decided to convert the thing to GPT as advised by a number of experts. I also disabled the use of legacy boot options in the hardware set-up.
Installation of Wind 10 went without a glitch, so I thought:“Cool! Let’s do Leap 15.1”. And then the "fun"started.
I conscientiously followed the installation instructions. The boot screen as displayed during the installation process showed command line and edit options but no function keys, so, UEFI was definitely recognised by the installer as the designated boot mode. I decided to go for 3 partitions: a “/” partition of 60 GB, a “/swap” partition of 8 GB and a “/home” partition of 40 GB.

In the Installation Settings screen, I changed the default location from MBR to the partition with “/boot”. (Which happens to be the ESP, I guess.)

When starting up, Windows started up as usual, but openSUSE could only start with legacy boot mode enabled. What did I do wrong?

A second thing is that, when the laptop freshly arrived with only Windoze installed, the boot mode was set as “openSUSE SecureBoot”. After conversion to GPT, this feature was lost.
Is there a possibility to download and re-install this?

Thank you in advance for reading this and all suggestions you may have.

In the meantime, stay healthy and have a nice day.



Hi and welcome to the Forum :slight_smile:
With a dual boot you would normally have;

sda1 ~260MB type ef00 /boot/efi (winX and openSUSE) for UEFI
sda2 16MB type 0c01 <winx reserved>
sda3 ? type 0700 operating system (winX) C:
sda4 60GB type 7300 operating system (openSUSE) /
sda5 40GB type 7300 /home
sda6 8GB type 7200 <swap>

If you boot from the openSUSE install media in rescue mode (UEFI boot) and show the output from;

efibootmgr -v
mount /dev/sda1 /mnt
ll /mnt/EFI
umount /mnt

That’s a red flag already.

It should show the bootloader to be “grub2-efi” (not just “grub2”). And, if using “grub2-efi” there is no option to install in the MBR.

When installing, if you use the expert partitioner then you must make sure that the ESP is mounted at “/boot/efi” but do not format it (because you want to keep the data already there).

Ahhh - after a lot of fiddling around to to get things on the road again, I obviously screwed up the entire booting… I wiped the whole slate and reinstalled Windoze. In stead of repeating the whole process and expecting a different outcome, I decided to invest a couple of hours in obtaining knowledge about EFI. That turned into days, but I still couldn’t pinpoint where i went wrong. Hence my post. So at the moment there isn’t much output for you to review, I’m afraid… As soon as I have, I will submit it anyway, which will be after installation of Leap 15.1.

Dear nrickert,

I think you hit the nail on the head here. I forgot during installation about the differences between Grub2 and GRUB2-efi and that the efi-loader will automatically be selected by operation of Secure Boot. I now have to check how I can force either Secure Boot or the use of the GRUB2-efi loader… (Had to disable Secure Boot in order to load the install medium.)
I have got my work cut out for me now:.

Thanks, you gave me something worthwhile to work with, I will be back with feedback.



So far, I got it partially nailed: enabled SecureBoot, managed to lure the installer into starting up and install from flash drive,
Sda1 up to and including 5is existing WindowsX install under UEFI

Set-backs up to this point:
sda6 was intended to be the / (root) partition, sized @ 60 GB. It now also contains /home

sda7 was meant to be the /home partition, sized @ 30 GB. Instead it now holds /boot/efi.
In itself this is not a biggie, but it is impossible to create a /home partition.

sda8 was intended as /swap, sized @ 16GB (RAM is 16GB). However,the installer has maximised the size @ 2 GB without options to overrule.
Hibernation will be allright, but wake-up will be a different kettle of fish.

Al in all, the un-allocated disk space should amount to approx. 200 GB, so I don’t see where the above constraints originate from.
At the moment I feel “up the creek without a paddle”, but maybe I’m overly pessimistic.

I made screenshots of the various partitioning screens but couldn’t attach them to this post. I will need to find another way to get them across.

Thanks for your support so far and have a nice evening,


If it were my computer, here is what I would try:

(1) Edit “/etc/fstab” so that the original ESP (the one used by Windows) is mounted at “/boot/efi”. You can get the UUID of that partition with the command “blkid”.

(2) Reboot, and make sure that the system still boots. (Should not be a problem). Check that the intended “/boot/efi” is mounted. It will have a partition under “/boot/efi/EFI” for Microsoft, but not one for opensuse.

(3) Reinstall booting. You can do this by going to Yast bootloader. Then change something (increase or decrease timeout by 1 second) and saving the changes. Now check that “/boot/efi/EFI/opensuse” exists. It should.

(4) Reboot again, to test everything.

(5) If all works, then you should now be able to reformat “/dev/sda7” to use for “/home”.

(6) Use the command

efibootmgr -v

Make sure that there is an entry there for Windows.

(7) Reboot again. And then repeat the last test.

I mention this, because some Dell computers from that era had the problem that the boot entry for Windows was being removed by the BIOS. By itself, this would not seem to be a problem, because there’s still a grub menu entry to boot Windows. But when you do that and boot Windows twice in succession, the BIOS is likely to remove the boot entry for openSUSE if your computer has that problem.

(8) If all is still good, then reformat “/dev/sda7” to use as “/home”.

And a note: If you do have a problem of the boot entry for openSUSE disappearing, then you should still be able to boot by using the install media and selecting “Boot from hard drive”.

Dear nrickert,

First and foremost, thank you for your quick and detailed guideline. Corona has been quite disruptive to my schedule and I expect not being able to follow your suggestions until this weekend. Since I’m infamous for undertaking things not fully prepared, I will change my ways and do some read-ahead this timerotfl!. Hence the delay.

Stay healthy, we’ll be in touch later.


From Google translate:

Learning effect: YaST2 Partitioner and YaST2 Boot Loader are comfortable to use tools for the configuration of the hard disks. They usually work very reliably. If in doubt, you should definitely create a consistent initrd with the command dracut -f and install Grub2 with the command grub2-install –target = x86_64-efi. You save yourself a lot of trial and error.


Dear Karl,

Thank you for hints. So far, the instructions previously received gave me a banging headache in trying to digest what actions are required. I will certainly look into the tools and procedures you recommend.

Have a nice day and stay healthy.


Dear nrickert,

In general, I do have some (not very much) Linux experience, gathered mainly with Ubuntu and Mint as an average user. A few escapades towards Knoppix and Debian also, but those were shortlived. Invasions into file systems and booting are pretty much new to me. (One of the blessings UEFI, shall we say?) Anyway, I tried to acquire some insight in these phenomena, but so far all it brought me are sleepless nights and an impressive quantity of headaches, which are generally caused by lack of proficiency, I guess.

Re your advice (1): I can’t see where this leads me. My objective here was to combine all booting instructions in the existing /boot/efi partition, specifically sda2 AFAIK. From your comment I understand that I should redirect the whole shebang to sda6?

With the possible limitations of forum posts in mind, I will send a detailed overview of my current SSD layout in a separate reply. Hopefully, it will clarify the situation on my side.
It will be a summary from blkid, with complementary info from Macrium Reflect 7.2 which I used to create a clone of the current disk Info from Macrium/Windoze will be in bold/Italics.

Clarification will be greatly appreciated.
Thank you in advance and have a pleasant day. Stay safe.


And here is the info aabout the current SSD lay-out:

sudo blkid - MACRIUM REFLECT 7.2

GPT disk 1 – Samsung 850 EVO 500GB

TYPE=“ntfs” 436.3MB/529.0MB – START/ENDSECTOR***= ***2.048 – 1.085.439
PARTLABEL=“Basic data partition”

TYPE=“vfat” FAT32(LBA) 26.3MB/100.0MB - START/ENDSECTOR=*** 1.085.4******40 – ***1.299.239
PARTLABEL=“EFI system partition”

PARTLABEL=“Microsoft reserved partition”
***1.299.240 – 1.323.007

/dev/sda4: ("WINDOWS OS")
TYPE=“ntfs” 38.69GB/106.73GB*** - START/ENDSECTOR=****** 1.323.008 – ***225.175.119
PARTLABEL=“Basic data partition”

TYPE=“ntfs” 142.3MB/39.60GB*** - START/ENDSECTOR=****** 225.175.120 – ***307.177.119
PARTLABEL=“Basic data partition”

/dev/sda6: ("/BOOT***/EFI")
SEC_TYPE=“msdos” UUID=“FBDA-D915”
TYPE=“vfat” 16
bitFAT 5.0MB/500.0MB - START/ENDSECTOR= 307.177.120****** – ***308.101.119

TYPE=“btrfs” 102.00GB***/ 102.00GB - START/ENDSECTOR=****** 308.101.120 – ***522.010.623

TYPE=“swap” 2.00GB/2.00GB*** - START/ENDSECTOR=****** 972.578.816 – ***976.773.134

(I am surprised by the fat that some partitions have multiple UUID’s. My gut feeling is to use PARTUUID in all situations. Am I correct?)

I trust this clarifies



The PARTUUID is for the partition table entry when GPT partitioning is used. There’s also a faked PARTUUID for DOS/MBR partitioning.

The ordinary UUID is the file system UUID.

If you reformat at partition, it’s ordinary UUID will usually change. But the PARTUUID will remain the same. If you delete a partition, and then create a new partition in its place, I’m assuming that would change the PARTUUID. But I have not tested this.