How to re-install Tumbleweed as UEFI in place of MBR (get rid of hybrid-boot)

English Install/Boot/Login
1

Dual-booting OpenSuse Tumbleweed on a gpt nmve-drive with Ubuntu 16.04. Unfortunately, when I installed Tumbleweed alongside the already existing UEFI-booting Ubuntu-system, I didn’t select the UEFI boot-option for the installation OpenSuse DVD. Thus, I seem to have wound-up with an install suitable for an MBR-drive. This is not what I want

Here’s the current set-up:

azed@azed-H270N:~$ sudo fdisk -l
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CFB16A8E-384A-4AD4-B14B-62F840FB7E73

Device             Start       End   Sectors  Size Type
/dev/nvme0n1p1      2048   1026047   1024000  500M EFI System
/dev/nvme0n1p2   1026048 158722047 157696000 75.2G Microsoft basic data
/dev/nvme0n1p3 158722048 183298047  24576000 11.7G Linux swap
/dev/nvme0n1p4 183298048 235724799  52426752   25G Linux filesystem
/dev/nvme0n1p5 235724800 342421503 106696704 50.9G Linux filesystem
/dev/nvme0n1p6 342421504 342441983     20480   10M BIOS boot
/dev/nvme0n1p7 342441984 405512191  63070208 30.1G Linux filesystem
/dev/nvme0n1p8 405512192 500117503  94605312 45.1G Linux filesystem
azed@azed-H270N:~$

p1 is the pre-existing EFI-partition I created when installing Ubuntu. p2 is an ntfs-partition (no Windows). The Ubuntu system is on p4-5. The OpenSuse sys is on p7-8

The system boots OK: I can get into both Xenial and Tumbleweed (albeit with “nomodeset” as a BIOS-option, in the case of the latter), but I don’t like this “hybrid-boot” dog’s breakfast

Question: How do I re-install the OpenSuse system as an EFI-booting system appropriate for my GPT drive?

First thoughts:

I have no option in my computer’s BIOS settings for switching between MBR- and EFI-boots. Thus I am going to have to alter the software on my system. I don’t want to do anything that is not revertible, perhaps via a chroot

My current understanding of the boot-process is this. When Grub2 was installed on my system a small piece of code - call it “grub 1.0” - was inserted amongst the first 446 bytes of the MBR at the head of my drive. A “flag”, indicating the “active” partition, may also have been planted in the partition table stored in the next 64 bytes of the MBR. At boot, "grub 1.0 is “read” by my computer, as its first move. The function of this code, its only function, is to point the computer to the active partition - in my case p6 (?) - where the main part of grub - call it grub 2.0 - is located. This grub 2.0 then loads into the computer’s memory and takes over the rest of the boot. The point is that this set-up effectively bypasses the EFI-system set-up on my computer.

Is this basically correct?

If it is, will it be sufficient for me to uninstall grub in OpenSuse, say with:

sudo zypper -remove grub* (whatever)

Will this remove the grub 1.0 boot-loader from the MBR / remove the “flag” in the MBR partition-table, and allow the EFI-system to take back control of the boot?

Or will I have to overwrite the bootloader in the (backed-up) MBR with zeros, say with:

dd if=/dev/zero of=/dev/sda bs=446 count=1

Once the EFI-system is back in control of the boot (so I can get into Ubuntu), I can blank the OpenSuse partitions and re-install as UEFI. I don’t want to be “locked out” of my Ubuntu system

That’s my current thinking anyway. Comments / suggestions welcome

I can’t be the only person who has messed-up his Tumbleweed install in this way. All help gratefully received

2

Do i understand that correctly: Your Ubuntu boots in UEFI-mode?

As far as i know it depends on the setup of the UEFI whether a system boots in UEFI-mode or CSM-mode (=Legacy mode; how a BIOS would boot).

So depending on the UEFI-setup the openSUSE install media boots either in UEFI-mode (without a menu at the bottom of the first screen) or in CSM-mode (with F1 F2 … menu at the bottom of the first screen).

I do not quite understand how you decide which system gets booted. “nomodeset” is a kernel option and has nothing to do with UEFI/CSM-boot-mode.

All the UEFIs i have seen so far do have such an option. Could you please post more details on your hardware (brand, UEFI/BIOS-vendor, …).

Regards

susejunky

3

Re-installing the whole system is not needed, although it should fix things if you prefer that route. Just the bootloader part needs to be reinstalled.
When you are logged in TW, start “Bootloader” (or “YaST”, then “Bootloader” option).
In the “Boot code options” tab be sure to select “GRUB2 for EFI” (NOT simply “GRUB2”).
Leave the other option at their default values, unless you have valid reasons for not doing so.
Press OK. The next reboot should be in EFI mode (unless something else went wrong).

I have no option in my computer’s BIOS settings for switching between MBR- and EFI-boots. Thus I am going to have to alter the software on my system. I don’t want to do anything that is not revertible, perhaps via a chroot

That looks odd, IF you were actually able to install TW in “legacy” mode, there should be an option in your BIOS to enable a “CMS” or “Compatibility” mode (or “Legacy” or “MBR” or whatever it might be called depending on your BIOS provider). Disable it and you should be left with EFI booting.
To check that, boot the TW installer, if you see a line of F1-F8 “buttons” at the bottom of the screen, that’s the installer in “MBR” mode. If you don’t see them, that’s the installer in “EFI” mode.

My current understanding of the boot-process is this. When Grub2 was installed on my system a small piece of code - call it “grub 1.0” - was inserted amongst the first 446 bytes of the MBR at the head of my drive. A “flag”, indicating the “active” partition, may also have been planted in the partition table stored in the next 64 bytes of the MBR. At boot, "grub 1.0 is “read” by my computer, as its first move. The function of this code, its only function, is to point the computer to the active partition - in my case p6 (?) - where the main part of grub - call it grub 2.0 - is located. This grub 2.0 then loads into the computer’s memory and takes over the rest of the boot. The point is that this set-up effectively bypasses the EFI-system set-up on my computer.

Is this basically correct?

IF you actually installed in “MBR” mode, that’s basically correct, but p6 is not what openSUSE would normally use.

If it is, will it be sufficient for me to uninstall grub in OpenSuse, say with:

sudo zypper -remove grub* (whatever)

DO NOT simply uninstall GRUB, you would end up with an unbootable system.

4

To get more information on your computers UEFI/BIOS you can issue as “root” in a console

# dmidecode -t 0

and post the result.

To test whether your system booted in UEFI or CSM mode you can issue as user in a console

#  -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"

Regards

susejunky

5

This should be easy to fix, because Ubuntu is “UEFI-booting”.

Boot Ubuntu the UEFI way. And make sure that its grub config is up to date.


sudo grub-mkconfig -o /boot/grub/grub.cfg

When you next try to boot Ubuntu the UEFI way, there should be a boot menu entry for opensuse Tumbleweed. Use that entry.

You should now be running Tumbleweed as booted UEFI.

You now need to do three things:

(1) mount your EFI partition as “/boot/efi”;
(2) modify “/etc/fstab” so that this mount is automatic in future boots.
I think you can use Yast partitioner to do the above two steps.
(3) Use Yast bootloader, and switch from “grub2” to “grub2-efi”.

That’s it.

6

Thanks for the very prompt responses, guys

**Some clarifications:
**
#2 susejunky (also #5 nrickert)

Your Ubuntu boots in UEFI-mode?

It was booting in UEFI-mode before I installed OpenSuse, but now Tumbleweed, which thinks it’s on an MBR-drive, is doing the booting, and it is booting the Ubuntu system as MBR. Thus, when (in Ubuntu) I now do:

efibootmgr

I get:

efibootmgr: EFI variables are not supported on this system.

So depending on the UEFI-setup the openSUSE install media boots either in UEFI-mode (without a menu at the bottom of the first screen) or in CSM-mode (with F1 F2 … menu at the bottom of the first screen).

I definitely am now booting both Ubuntu and OpenSuse as MBR. When I installed OpenSuse, the DVD-drive in my BIOS boot-order was listed twice, once with a UEFI-tag, and once without. I opted for the non-UEFI option, with the consequences described. REALLY, REALLY DUMB.

I do not quite understand how you decide which system gets booted. "nomodeset" is a kernel option and has nothing to do with  UEFI/CSM-boot-mode.

I choose the system to boot via the OpenSuse boot menu, which lists both Ubuntu 16.04 and OpenSuse - both systems, though, now boot as MBR. Ignore the “nomodeset” comment - irrelevant to the current prob: I simply found that I had to add that to the OpenSuse boot-command to get Tumbleweed to boot properly

All the UEFIs i have seen so far do have such an option [to switch between MBR and EFI boot-modes]. Could you please post more details on your hardware (brand, UEFI/BIOS-vendor, …).

The motherboard of my computer is a GA-Z270N-WIFI. The manual is in front of me. There is a “CSM Support”-option (I have also fiddled around with this in the BIOS). By default, the CSM-system is enabled. It can be disabled, but - here’s the catch - to disable it, I have to switch another option: “Windows 8/10” features from “other OS” (the default) to one of “Windows 8/10” or “Windows 8/10 WHQL”. If I select one of these two options (I have actually only tried the first), and go on to disable CSM, my computer seems to think that it should have a Windows system installed. It doesn’t find such a system. Thus, with these settings, I get no “bootable-media” at all listed in the BIOS boot-priority list. Grrr, frustrating, or what!

**#3 OrsoBruno

**

Re-installing the whole system is not needed, although it should fix things if you prefer that route. Just the bootloader part needs to be reinstalled.
When you are logged in TW, start “Bootloader” (or “YaST”, then “Bootloader” option).
In the “Boot code options” tab be sure to select “GRUB2 for EFI” (NOT simply “GRUB2”).
Leave the other option at their default values, unless you have valid reasons for not doing so.
Press OK. The next reboot should be in EFI mode (unless something else went wrong).

How do I revert this (say from a DVD rescue-sys chroot) if it doesn’t work? I would like to avoid GUIs, and work with purely terminal commands, which can be inverted. I don’t want to “brick” my system.

That looks odd, IF you were actually able to install TW in “legacy” mode, there should be an option in your BIOS to enable a “CMS” or “Compatibility” mode (or “Legacy” or “MBR” or whatever it might be called depending on your BIOS provider). Disable it and you should be left with EFI booting.

See my first clarification above

#4 susejunky

Here’s the additional info you asked for:

azed@azed-H270N:~$ sudo dmidecode -t 0
[sudo] password for azed: 
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
    Vendor: American Megatrends Inc.
    Version: F3
    Release Date: 02/21/2017
    Address: 0xF0000
    Runtime Size: 64 kB
    ROM Size: 16384 kB
    Characteristics:
        PCI is supported
        BIOS is upgradeable
        BIOS shadowing is allowed
        Boot from CD is supported
        Selectable boot is supported
        BIOS ROM is socketed
        EDD is supported
        5.25"/1.2 MB floppy services are supported (int 13h)
        3.5"/720 kB floppy services are supported (int 13h)
        3.5"/2.88 MB floppy services are supported (int 13h)
        Print screen service is supported (int 5h)
        Serial services are supported (int 14h)
        Printer services are supported (int 17h)
        ACPI is supported
        USB legacy is supported
        BIOS boot specification is supported
        Targeted content distribution is supported
        UEFI is supported
    BIOS Revision: 5.12

azed@azed-H270N:~$ #  -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"
"Legacy boot on HDD"
azed@azed-H270N:~$

**#5 nrickert
**
When I do (in the Ubuntu system):

sudo update-grub

[A more user-friendly version of “sudo grub-mkconfig -o /boot/grub/grub.cfg” - or so I’m told]

I get:

Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.10.0-38-generic
Found initrd image: /boot/initrd.img-4.10.0-38-generic
Found linux image: /boot/vmlinuz-4.10.0-37-generic
Found initrd image: /boot/initrd.img-4.10.0-37-generic
Found linux image: /boot/vmlinuz-4.10.0-35-generic
Found initrd image: /boot/initrd.img-4.10.0-35-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done
azed@azed-H270N:~$

I.e., the Ubuntu-sys doesn’t “see” the OpenSuse-system (because the Ubuntu version of grub still thinks it’s on a GPT-drive, and just consults what’s listed in the EFI-partition?)

I hope things are clearer now

My theory is that I have to stop the BIOS from “seeing” my drive as an MBR set-up. The EFI-system should then take over. No-one liked my idea of uninstalling Grub and wiping the bootloader from the (backed-up) MBR.

Any other ideas?

7

After you implmented this proposed change you have to keep in mind that you are starting Tumbleweed by using the grub.cfg from your Ubuntu install. So if you update your Tumbleweed and receive a new kernel version you need to rebuild Ubuntus grub.cfg or it will not start Tumbleweeds new kernel.

Regards

susejunky

8

Thank you for providing more information.

As confirmed by the output of dmidecode which you provided you have an UEFI that did boot in UEFI mode and is now booting in CSM-mode.

I heard that some bad-behaving UEFIs look only in “/EFI/BOOT” (of the EFI-partition) for bootloaders.

For further advice it would help if you could show the content of your EFI-partition. If your Ubuntu is still setup as before it should have this partition mounted. In Tumbleweed you may have to mount it first.

And you could have a look in the internet if there is an update for your UEFI.

Regards

susejunky

9

[/QUOTE]

Okay.

I can assure you that it doesn’t work the way that you just described.

You probably installed openSUSE with the “btrfs” file system. And the grub update doesn’t see it because it doesn’t fully grok “btrfs”.

With some computers, you can hit F12 while booting (while the vendor screen is showing), and that gives a boot menu. See if you can boot to ubuntu in EFI mode that way. If you can, it will make things easier.

10

Let me add some clarification here.

Your main problem is with your BIOS settings.

If we could magically convert your openSUSE to EFI booting, then the result would be that you could not boot it at all. Because, at present, you seem unable to do UEFI booting. So you need to work out how to change the BIOS settings (or, more correctly, firmware settings) so that you can boot UEFI. Once you do that, there’s a good chance that “ubuntu” will again be UEFI bootable.

In order to make the changes you want, you will need to boot something in UEFI mode. You can either boot ubuntu in UEFI mode, or you can boot the Tumbleweed install DVD in UEFI mode, or the Tumbleweed live rescue CD (or USB) in UEFI mode. Booting something in UEFI mode is the first step toward making the changes you want to make.

11

Yes, it is essential that you do boot in UEFI mode.

Judging by the manual of your motherboard (http://download.gigabyte.eu/FileList/Manual/mb_manual_ga-z(h)_270n-wifi_e.pdf) setting the options

  • “FastBoot” to “Disabled”
  • “Windows 8/10 Features” to “Windows 8/10”
  • “CSM support” to “Disabled”

should enable UEFI booting. If that is not the case it might be worth trying to set the options

  • “FastBoot” to “Disabled”
  • “Windows 8/10 Features” to “Windows 8/10”
  • “CSM support” to “Enabled”
  • “Storage Boot Option Control” to “UEFI”
  • “Other PCI devices” to “UEFI”

Regards

susejunky

12

nrickert, susejunky, thanks again for posting.

I can boot as UEFI (or MBR) with installation DVDs - that, of course, only gets me into a rescue environment.

Tried your BIOS suggestions, susejunky - nada. Same old OpenSuse boot-menu.

What about this:

Boot the OpenSuse installation DVD (MBR) -> Rescue system -> u/name: root -> p/w <none needed>

From the rescue command-terminal:

  1. check internet connection

zypper list-updates

  1. set up a chroot:

i) mount root partition of the OpenSuse system (in my case nvme0n1p7):

mount /dev/nvme0n1p7 /mnt

ii) Bind mount some other necessary stuff:

for i in /sys /proc /run /dev; do sudo mount --bind “$i” “/mnt$i”; done

iii) insert the terminal in the root-folder of the OpenSuse sys:

chroot /mnt

terminal commands now act on the installed OpenSuse system

iv) mount other needed partitions:

mount -a

  1. Remove grub:

zypper remove grub-pc, grub-common

Q: apt-get in ubuntu can simulate a command without doing it. Possible with zypper?

Q: is this the right command to remove grub?

  1. Back-up the MBR to some external volume

dd if=/dev/nvme0n1 of=<some volume>/mbr bs=512 count=1

I will have to mount this volume (say nvme0n1p2). How do I do that?

Is the form of the above command okay? Does it matter what I call the out-file?

  1. Overwrite the grub-bootloader in the MBR with zeros:

dd if=/dev/zero of=/dev/nvme0n1 bs=446 count=1

Q: again, is this command correct

I will now have completely removed all trace of grub (MBR) from the system (or have I? What about the “flag” in the MBR partition table, if there be such a thing?).

**[NOTE: these above commands can (in principle) be reverted:

In a chroot,

Put back the MBR:

dd if=<some volume>/mbr of=/dev/nvme0n1 bs=512 count=1

Reinstall grub:

zypper install grub-pc, grub-common

done]**

Back to the job in hand:

  1. Dismantle the chroot:

i) exit the chroot

exit

ii) unmount what has been mounted:

for i in /sys /proc /run /dev; do sudo umount /mnt$i; done

sudo umount /mnt

  1. Reboot

shutdown -r now

I’m hoping that the UEFI system will now take control of the boot for lack of any other alternative (with the above steps in place, how would the BIOS know to boot as MBR?), though its possible that I may have to re-install grub (EFI) in the Ubuntu sys via a chroot from a DVD environment

If this doesn’t work, I can at least get the OpenSuse boot back (in principle) by reverting the elimination of grub (MBR)

What could possibly go wrong?

Comments / criticisms welcome. Comments on the form of the commands above particularly welcome.

I have a recent back-up of my Ubuntu-system, and I could make another one. I have previously restored my ubuntu-system from a backup (as a test, soon after I installed), so I could, in principle completely rebuild my pre-OpenSuse set-up (the alternative), but I want to avoid that

13

To me it is still not clear

Does your UEFI not boot in UEFI mode?

OR

Does your UEFI boot in UEFI mode but cannot find a valid UEFI bootloader?

However when i understand your first post correctly you once were able to boot Ubuntu in UEFI mode but since you installed Tumbleweed UEFI boot does not work any longer.

It really would be helpful to know what the contents of your UEFI partition (type: 0xEF00) is.

Regards

susejunky

14

I’m not quite sure why you want to do all this.

As far as i understand you currently have a working Tumbleweed installation that boots in CSM/MBR mode. That means you have a working GRUB2-environment for CSM/MBR boot. That should be able to boot your Ubuntu installation as well and if not we should be able to repair it. This GRUB2 environment should not interfere with any UEFI boot at all.

You would like to boot Tumbleweed and Ubuntu in UEFI mode. To achive that the very first thing to do is to get your UEFI to boot in UEFI mode. The next step would be to establish a working GRUB2 environment for UEFI boot.

At the moment i could think of the following reasons why your system does not boot in UEFI mode:

  • Your UEFI is faulty. Thats not very likely. You had been able to boot Ubuntu in UEFI mode. However doing a firmware update could cure such a problem.
  • Your UEFI setup is not correct. To sort this out you should try the setups i mentioned an report exactly what happens.
  • Your UEFI works fine and is setup correctly but it cannot find a valid UEFI bootloader. To look into this needs to look at your current EFI partition and - if necessary - a repair/new setup of GRUB2 for UEFI boot.

Regards

susejunky

15

That should be good enough.

mount /dev/nvme0n1p7 /mnt

After you have done that, you need:


mkdir /mnt/boot/efi
mount /dev/nvme0n1p1 /mnt/boot/efi

Bind mount some other necessary stuff:

for i in /sys /proc /run /dev; do sudo mount --bind "$i" "/mnt$i"; done

Yes, you need that.

And, in future, use “CODE” tags rather than “QUOTE” tags for command lines.

No need to remove grub.

After the “chroot”, the easiest thing to do will be to run “yast” at the command line.

This will give you an awkward command line “ncurses” version of Yast.

Select “System”. Hit TAB and select “bootloader”.

Tab to the line where it says that grub2 is your bootloader. Use up/down arrows to change that to “grub2-efi”.

Then do finish/save/okay (whatever) to save those changes. That should do all of the work for you. Then “exit” from the chroot environment.

umount -R /mnt

That “umount” is not strictly needed. Then reboot.

After this, you should be able to boot opensuse either with UEFI or with legacy MBR booting. It’s then between you and your BIOS as to which you pick.

Once you get into your system, change “/etc/fstab” to always mount the EFI partition at “/boot/efi”. You can use Yast partitioner for that, but this time use the GUI Yast rather than the command line version.

16

OK. I am in an Ubuntu Live DVD environment booting as UEFI.

efibootmgr

gives:

BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0003,0005,0000,0002
Boot0000* Windows Boot Manager
Boot0002* ubuntu
Boot0003* Hard Drive
Boot0004* UEFI: Generic STORAGE DEVICE 9451
Boot0005* UEFI: Generic STORAGE DEVICE 9451, Partition 1
ubuntu@ubuntu:~$

Re: my last post (the command list)

It occurs to me that I don’t need a chroot to uninstall grub / backup the MBR; I can do all that from within the OpenSuse system (duh!). I only need a chroot if my “totally get rid of grub (MBR)” idea doesn’t work. I would, of course, test-out the proposed chroot before I actually did anything.

Doing everything from the OpenSuse desktop makes everything (in principle) simple:

Remove grub with zypper (whatever) -> back-up MBR -> over-write the grub boot-loader in the MBR with zeros -> re-boot

I’m hoping:

the BIOS system can’t find anything in the MBR to boot -> the UEFI boot-system takes over and allows me to UEFI-boot into ubuntu -> I can then wipe the OpenSuse partitions and do a proper UEFI-install (*).

If I need to (step 2, above, fails), I can re-install the ubuntu (EFI) bootloader from a chroot (done it before)

If the proposed solution doesn’t work, for whatever reason I can - in principle - restore my system, using the OpenSuse rescue sys on the installation DVD, to the state it was in before the solution was attempted; so I’m no worse off (if no further forward).

What do you think? I’m especially interested in what people think of assumption (*)

Quitting the Live DVD

17

You never told us about that Windows in Boot0000!

Your boot order is 0004,0003,0005,0000,0002 so your UEFI will try to boot from “UEFI: Generic STORAGE DEVICE 9451” which seems to me like a removable device and if that is not there at boot time the boot might fail. You should change that order with efibootmgr to something like 0002,… .

However that is not the information i asked for. What i would like to see is what files/directories there are on your EFI partition (nvme0n1p1).

Regards

susejunky

18

Will this do?

azed@azed-H270N:~$ ls -l /boot/efi
ls: cannot open directory '/boot/efi': Permission denied
azed@azed-H270N:~$ sudo ls -l /boot/efi
[sudo] password for azed: 
total 4
drwx------ 4 root root 4096 Oct 21 10:04 EFI
azed@azed-H270N:~$ sudo ls -l /boot/efi/EFI
total 8
drwx------ 2 root root 4096 Oct 21 10:04 BOOT
drwx------ 3 root root 4096 Oct 21 10:04 ubuntu
azed@azed-H270N:~$ sudo ls -l /boot/efi/EFI/BOOT
total 1216
-rwx------ 1 root root 1169992 Oct 21 10:04 BOOTX64.EFI
-rwx------ 1 root root   72144 Oct 21 10:04 fbx64.efi
azed@azed-H270N:~$ sudo ls -l /boot/efi/EFI/ubuntu
total 3472
-rwx------ 1 root root     108 Oct 21 10:04 BOOTX64.CSV
drwx------ 2 root root    4096 Apr  9  2017 fw
-rwx------ 1 root root   65032 Oct 21 10:04 fwupx64.efi
-rwx------ 1 root root     117 Oct 30 16:07 grub.cfg
-rwx------ 1 root root 1133944 Oct 30 16:07 grubx64.efi
-rwx------ 1 root root 1168464 Oct 30 16:07 mmx64.efi
-rwx------ 1 root root 1169992 Oct 30 16:07 shimx64.efi
azed@azed-H270N:~$
19

Good start.

BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0003,0005,0000,0002
Boot0000* Windows Boot Manager
Boot0002* ubuntu
Boot0003* Hard Drive
Boot0004* UEFI: Generic STORAGE DEVICE 9451
Boot0005* UEFI: Generic STORAGE DEVICE 9451, Partition 1
ubuntu@ubuntu:~$

Again, please use CODE tags rather than QUOTE tags for command line text.

At that stage, you should be able to do:

efibootmgr -o 2,0

to make ‘ubuntu’ first in boot order.

And then, maybe turn on secure-boot in your BIOS. That forces UEFI booting. And ubuntu probably installed secure-boot support (or at least I hope it did).

I only need a chroot if my “totally get rid of grub (MBR)” idea doesn’t work.

I’m pretty sure that won’t work.

Remove grub with zypper (whatever) -> back-up MBR -> over-write the grub boot-loader in the MBR with zeros -> re-boot

Honestly, this is pointless. Okay, there is a point to backing up the MBR. But the remainder of that does nothing useful.

I’m hoping:

the BIOS system can’t find anything in the MBR to boot -> the UEFI boot-system takes over and allows me to UEFI-boot into ubuntu -> I can then wipe the OpenSuse partitions and do a proper UEFI-install (*).

It doesn’t usually work that way.

If I need to (step 2, above, fails), I can re-install the ubuntu (EFI) bootloader from a chroot (done it before)

Based on your “efibootmgr -v”, it looks as if the ubuntu UEFI bootloader is already installed. You just need to change the boot order.

20

Thank you very much!

So there is “/boot/efi/EFI/ubuntu/grubx64.efi” which looks like a valid GRUB2 UEFI bootloader. Now you should check the file “/boot/efi/EFI/ubuntu/grub.cfg” which should look somehow like this

search --fs-uuid --set=root da3df628e-8771-455f-bcfa-17fde9d3565
set prefix=(${root})/boot/grub
configfile $prefix/grub.cfg

“da3df628e-8771-455f-bcfa-17fde9d3565” will be different in your case. Check that it is the UUID of your Ubuntu root partition.

Then you should be able to proceed as nrickert told you.

Regards

susejunky