Dual boot question relating to UEFI

English Install/Boot/Login
1

This is probably due to my lack of understanding but I am puzzled by the way boot options are handled in a UEFI system.

Now to my issue. I have two Linux systems installed on two different HDDs, one LEAP 42.2 and one Tumbleweed. Now prior to UEFI I would be able to select the boot device in the hardware and grub would appear for that system, yes it wold probably show both but that’s not the problem. I could select either HDD and boot so that if one HDD failed I could always boot the other one.

Now with UEFI I have only one UEFI boot option set no matter which system I set it up from and that is physically on the TW HDD, so if for some reason that HDD fails I have to boot a rescue system and set up grub2 on the HDD for LEAP before I can do anything on the system. Why does it end up like this? Why not have two UEFI boot options one pointing to the HDD for LEAP and the other TW, yes I can boot either system from any HDD still but it gives me redundancy for hardware failure. The current way it works is a pain when say I update LEAP which is my backup as that will re-write the boot option to set LEAP as the first option and TW (my normal system) second.

What am I doing wrong here or is this a YYGT (Yeah You Get That)?

Stuart

2

Hi
If using openSUSE, then yes you should setup a efi partition on both disks, why because if you only have one EFI partition since they both use the same directory name ‘opensuse’ one will overwrite the other… You can have one, but then you need to look at renaming and additional maintenance on an update…

Here is my multiboot system on two disks…


lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111.8G  0 disk 
├─sda1   8:1    0   260M  0 part (efi for openSUSE and SLED)
├─sda2   8:2    0    40G  0 part 
├─sda3   8:3    0    40G  0 part 
└─sda4   8:4    0  31.5G  0 part /data
sdb      8:16   0 111.8G  0 disk 
├─sdb1   8:17   0   300M  0 part 
├─sdb2   8:18   0   100M  0 part /boot/efi (efi for Tumbleweed and WinX)
├─sdb3   8:19   0   128M  0 part 
├─sdb4   8:20   0  62.9G  0 part 
├─sdb5   8:21   0   450M  0 part 
├─sdb6   8:22   0     8G  0 part [SWAP]
└─sdb7   8:23   0    40G  0 part /

(sdb2) ls /boot/efi/EFI/
Boot  Microsoft  opensuse

mount /dev/sda1 /mnt
ls /mnt/EFI/
boot  opensuse  sled

efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,0001,0004,0000,000A,000B
Boot0000* Windows Boot Manager    HD(2,GPT,15a32993-e709-4748-a7df-23ee9fb60c25,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* opensuse    HD(2,GPT,15a32993-e709-4748-a7df-23ee9fb60c25,0x96800,0x32000)/File(\EFI\opensuse\grubx64.efi)
Boot0002* sled-secureboot    HD(1,GPT,0b434ac1-9543-4ef7-9be8-8299ea8075a0,0x800,0x82000)/File(\EFI\sled\shim.efi)
Boot0003* opensuse-secureboot    HD(2,GPT,15a32993-e709-4748-a7df-23ee9fb60c25,0x96800,0x32000)/File(\EFI\opensuse\shim.efi)
Boot0004* sled    HD(1,GPT,0b434ac1-9543-4ef7-9be8-8299ea8075a0,0x800,0x82000)/File(\EFI\sled\grubx64.efi)

So you need to look at your efi entries and point/recreate to point at the correct efi partition and disk. You can have two on a disk though if you want, manual creation and point at the partition is required.

3

Short answer - because nobody implemented it. It is relatively straightforward by creating second ESP on another disk and doing bootloader installation twice. Something like this was offered in EFI stone age for Windows (Itanium) by at least one company.

But devil is in details and it requires coordinated effort of several packages and time/resources. So your best bet is to find large SUSE customer who is interested in having it so SUSE implements it. Or do it yourself :slight_smile:

4

I have two UEFI systems, with two hard drives on each (actually, 3 hard drives on one of them). I’m doing them differently, because the UEFI implementation is a bit different.

On one of them, I have two EFI partitions, one on each of two hard drives (and no EFI partition on the third drive). Windows boots from the first drive, and opensuse from the second drive.

This is actually working reasonably well. The UEFI implementation is a bit broken. The firmware thinks there should only be one bootable operating system. But since I have two EFI partitions, it allows one operating system per EFI partition. If I tried to use only one EFI partition, then when I booted opensuse, the firmware would delete the boot entry for Windows. That’s not really a problem, because grub2-efi can boot windows anyway. But if I then booted Windows, it would put back the Windows UEFI boot entry and the firmware would delete the opensuse boot entry. And that leaves me stranded. I avoid that by having the two EFI partitions.

On the other computer, I also have two EFI partitions, one per disk. But I am only using one (the EFI partition on “/dev/sda”). This is working pretty well. I can install multiple systems.

If I install ubuntu, there will be a ubuntu boot entry and an opensuse boot entry. I can hit F12 during boot and select either. However, if I install two opensuse systems, then there is only the one boot entry.

There’s actually a workaround for that. After installing 42.2, I edited “/etc/default/grub”, and changed the “DISTRIBUTOR” line to “betasuse”. Then, after updating the boot, I now have two UEFI boot entries. One is “opensuse” that boots Tumbleweed, and the other is “betasuse” that boots 42.2. I can hit F12 during boot and choose either. But usually, I take the default, which is “opensuse”. And the grub2 boot menu allows me to choose which I want to boot.

As far as I know, I cannot call them both “opensuse” and have them use the two different EFI partitions. That’s because the opensuse installer looks for any named EFI bootable system, and deletes any that are named “opensuse” or “opensuse-secureboot” before it installs.

I do occasionally backup the first EFI partition to the second EFI partition. If the first disk fails, I can use that backup. (And it’s a 1T Seagate drive, and those seem prone to fail).

5

I have managed to add another boot option using efibootmgr which has a name of LEAP422 which should survive any install, this one points to the Leap install’s efi partition, note that Leap is on SDA and TW is on SDB (and yes I know sda is default but I like to be sure anyway). In light of what has been said I think I will manually add another called TUMBELWEED which will be there as a back up for when I update the Leap partition as I guess it will overwrite the opensuse one.

The code I used was


efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\opensuse\\grubx64.efi -L LEAP422

and the options now are


BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0001,0002
Boot0000* opensuse      HD(1,GPT,2eca2750-fed6-4e3f-887f-27f183020fda,0x800,0x61800)/File(\EFI\opensuse\grubx64.efi)
Boot0001* Hard Drive    BBS(HD,,0x0)
Boot0002* CD/DVD Drive  BBS(CDROM,,0x0)
Boot0003* LEAP422       HD(1,GPT,e26d7a71-7d17-4d76-8cf5-66d3d57bce5b,0x800,0x64000)/File(\EFI\opensuse\grubx64.efi)

I discovered that you need to reset the boot order after doing the add with


efibootmgr -o 0000,0003,0001,0002

because the add puts the new one first and in my case I dont want that.

Stuart

6

Keep in mind that you need to make sure grubx64.efi on the second partition is updated every time grub2 package is updated, otherwise it will go out of sync with content of /boot/grub2.

7

Sorry I’m not sure what you mean. The Leap stuff is all on SDA and TW is on SDB, so when either is updated surely their own stuff will get updated and therefore keep in sync since for Leap grubx64.efi will be loaded from SDA and likewise for TW will be loaded from SDB. They are not sharing the efi partitions.

Stuart

8

Hi
What happens at times is that the boot order will change, so on a efi/kernel/grub2 update, the grub2 menu will show up based on which one updated, all will still boot ok (as long as you have the probe foreign os checked), then you need to boot into your default system and change something in the bootloader [eg menu delay] (or rebuild from the command line) so it sets it to default.

I see this every now and again, it flips to Leap or SLED, but I want the Tumbleweed one as default…

9

Ah yes OK I understand what you mean, it is just the order and default boot option which changes. Yes I do realise that but the thing is now with what I’ve done I should be able to manually select a bootable option for the system I need to start even where openSUSE has messed with it because my two manually added options should not change or get deleted (hopefully).

Stuart

10

Hi
Depending on your system BIOS UEFI implementation… I’ve had no issues with my HP or Dell systems as you can select from the BIOS boot option. Probably the only thing to consider is a backup option for the efi partitions, I have a script to get all the info and tar it up…


#!/bin/bash

# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# Copyright (C) 2013-2017 Malcolm Lewis <malcolmlewis@opensuse.org>

EFI_SGDISK_BIN=`which sgdisk`
EFI_BOOT_MGR_BIN=`which efibootmgr`

if (( $# != 3 )); then
    echo "Usage: $0 <EFI_DEVICE> <EFI_PARTITION> <BACKUP_LOCATION>" >&2
    exit 1
fi

EFI_DEVICE="$1"
EFI_PARTITION="$2"
BACKUP_LOCATION="$3"
BACKUP_DATE=`date +\%m%d%y%H%M%S`

sgdisk -b /$BACKUP_LOCATION/`hostname`_$EFI_DEVICE\_backup_$BACKUP_DATE.gpt /dev/$EFI_DEVICE
mount -t vfat /dev/$EFI_DEVICE$EFI_PARTITION  /mnt
tar -C /mnt -cvzf /$BACKUP_LOCATION/`hostname`_esp_$BACKUP_DATE.tgz EFI
umount /mnt
$EFI_BOOT_MGR_BIN -v > /$BACKUP_LOCATION/`hostname`_efibootmgr_$BACKUP_DATE.txt

tar cjvf /$BACKUP_LOCATION/`hostname`_backup_$BACKUP_DATE.tar.bz2 \
    /$BACKUP_LOCATION/`hostname`_$EFI_DEVICE\_backup_$BACKUP_DATE.gpt \
    /$BACKUP_LOCATION/`hostname`_esp_$BACKUP_DATE.tgz \
    /$BACKUP_LOCATION/`hostname`_efibootmgr_$BACKUP_DATE.txt

rm /$BACKUP_LOCATION/`hostname`_$EFI_DEVICE\_backup_$BACKUP_DATE.gpt \
    /$BACKUP_LOCATION/`hostname`_esp_$BACKUP_DATE.tgz \
    /$BACKUP_LOCATION/`hostname`_efibootmgr_$BACKUP_DATE.txt