Re-enabling Secure Boot and UEFI for Dual Boot

Hi,

I am looking to re-enable Secure boot and UEFI after turning them to install tumbleweed on a second drive a few months ago. I have had a look at this post (Want to update to use UEFI) explaining switching to UEFI boot. It seems to work under the assumption that there is a /boot/efi before using Yast boot loader. I don’t believe that folder exist on my system. Do I need to do anything to create it or just switch to GRUB2 for EFI in Yast, boot into the biso and change to UEFI “for windows” mode?

Any help would be much appreciated.

This will tell you whether you are using BIOS or UEFI:
Open a terminal:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

I think Tumbleweed defaults to UEFI if it is available.
If it says BIOS then maybe UEFI is not available on your system.

Note: The space between [ and -d and ] and efi are important for the output.

~>  [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
BIOS
~>  -d /sys/firmware/efi && echo UEFI || echo BIOS
 -d: command not found
BIOS
~> /sys/firmware/efi && echo UEFI || echo BIOS
bash: /sys/firmware/efi: No such file or directory
BIOS

I know my computer is capable of it as I had it working on my windows 10 drive before adding the second for tumbleweed. I think as it was disable when tumbleweed was installed it did not install the files for UEFI. Would switching to GRUB2 for EFI in Yast install everything required and work out of the box?

lidchill24:
Would switching to GRUB2 for EFI in Yast install everything required and work out of the box?

I don’t know for sure. I assume it would. Maybe there is some info in the opensuse wiki or more knowledgable people could chime in.

One thing is for sure, you can only use one method for all the booting to be done. I see you mention :Dial Boot", so take care.

Blockquote
One thing is for sure, you can only use one method for all the booting to be done. I see you mention :Dial Boot", so take care.

Hence why I am being a bit cautious, even though I can’t see why switching to GRUB2 for EFI in Yast, boot into the biso and change to UEFI “for windows” mode wouldn’t work.

Like in the other thread (you mention it above), why would you want this? (I admit that I never asked this in the other thread, but nevertheless).

Also, when you have read the other thread, you will know that the partitioning as it is, is important. Thus why did you now show anything (in fact you did not show anything at all about your system).

And why do you do

Nobody suggested it. You seem to permute on a given command at free will. That attitude could be very dangerous.

With my limited experience what snoopy suggested seemed like it would show if the files required to use UEFI are installed.

I don’t know how I would show this through the command line, but I have one drive with windows 10 and a second with tumbleweed I haven’t made any partitions on either drive.

Just for the security of secure boot and to have windows show up in grub rather than having to press f8 on boot.

And it said “BIOS”, thus you are now using BIOS booting. You told so, but we like computer confirmation.

And again, leaving out parts of a command suggested may lead to disaster, Specially when you have no idea what you are doing.

Then show:

lsblk -f

and as root:

fdisk -l

That is impossible. Without a partition table it is impossible to boot from a disk.

Very good point, I will be more careful in the future.

Sorry, I meant apart from the actual operating systems. Here is what I get

lsblk -f
NAME FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0
     squash 4.0                                                         0   100% /snap/bare/5
loop1
     squash 4.0                                                         0   100% /snap/core22/1380
loop2
     squash 4.0                                                         0   100% /snap/core20/2318
loop3
     squash 4.0                                                         0   100% /snap/core22/1439
loop4
     squash 4.0                                                         0   100% /snap/get-iplayer/523
loop5
     squash 4.0                                                         0   100% /snap/gnome-3-38-2004/143
loop6
     squash 4.0                                                         0   100% /snap/gtk-common-themes/1535
loop7
     squash 4.0                                                         0   100% /snap/snapd/21759
loop8
                                                                        0   100% /snap/gnome-42-2204/176
loop9
                                                                        0   100% /snap/wine-platform-7-devel-core20/24
loop10
                                                                        0   100% /snap/wine-platform-runtime-core20/128
loop11
                                                                        0   100% /snap/wine-platform-runtime-core20/129
sda                                                                              
├─sda1
│                                                                                
└─sda2
     ntfs         New Volume 4C585D6F585D58B2                                    
sdb                                                                              
├─sdb1
│                                                                                
├─sdb2
│    btrfs                   ff03df6c-3dc7-4e84-a949-6994b02f76a3  747.9G    16% /var
│                                                                                /usr/local
│                                                                                /srv
│                                                                                /root
│                                                                                /opt
│                                                                                /boot/grub2/i386-pc
│                                                                                /home
│                                                                                /boot/grub2/x86_64-efi
│                                                                                /.snapshots
│                                                                                /
└─sdb3
     swap   1                66be5b6f-96ee-49d6-a37f-e45e51f93627                [SWAP]
nvme0n1
│                                                                                
├─nvme0n1p1
│    vfat   FAT32 SYSTEM     8EC7-2DC2                                           
├─nvme0n1p2
│                                                                                
├─nvme0n1p3
│    ntfs         Recovery   E6F0C7A7F0C77BF5                                    
└─nvme0n1p4
     ntfs         Windows    3020CC7A20CC4894 

Doesn’t look like any UEFI

~> sudo fdisk -l
[sudo] password for root: 
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: ADATA SX6000PNP                         
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: CED6070E-1B09-42D9-B23B-0E7B62F7DE29

Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1    2048     534527    532480   260M EFI System
/dev/nvme0n1p2  534528     796671    262144   128M Microsoft reserved
/dev/nvme0n1p3  796672    1820671   1024000   500M Windows recovery environment
/dev/nvme0n1p4 1820672 1000214527 998393856 476.1G Microsoft basic data


Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM008-2FR1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CA604B2F-A82C-4B90-ACEC-2C1ACFE7BC3C

Device     Start        End    Sectors  Size Type
/dev/sda1     34      32767      32734   16M Microsoft reserved
/dev/sda2  32768 3907028991 3906996224  1.8T Microsoft basic data

Partition 1 does not start on physical sector boundary.


Disk /dev/sdb: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: KINGSTON SA400S3
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: C4262C8A-8D12-4350-AE7B-8C7E7120757C

Device          Start        End    Sectors   Size Type
/dev/sdb1        2048      18431      16384     8M BIOS boot
/dev/sdb2       18432 1871190015 1871171584 892.2G Linux filesystem
/dev/sdb3  1871190016 1875384974    4194959     2G Linux swap


Disk /dev/loop0: 4 KiB, 4096 bytes, 8 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


Disk /dev/loop1: 74.24 MiB, 77844480 bytes, 152040 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


Disk /dev/loop2: 63.95 MiB, 67051520 bytes, 130960 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


Disk /dev/loop3: 74.24 MiB, 77848576 bytes, 152048 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


Disk /dev/loop4: 126.91 MiB, 133074944 bytes, 259912 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


Disk /dev/loop5: 349.7 MiB, 366682112 bytes, 716176 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


Disk /dev/loop6: 91.69 MiB, 96141312 bytes, 187776 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


Disk /dev/loop7: 38.83 MiB, 40714240 bytes, 79520 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


Disk /dev/loop8: 505.09 MiB, 529625088 bytes, 1034424 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


Disk /dev/loop9: 453.06 MiB, 475066368 bytes, 927864 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


Disk /dev/loop11: 497.82 MiB, 522002432 bytes, 1019536 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


Disk /dev/loop10: 497.82 MiB, 522002432 bytes, 1019536 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

Looking at your results of fdisk -l there is an EFI System Partition (ESP) (/dev/nvme0n1p1) probably created and used by MS Windows (which was installed in UEFI mode).

So this proves UEFI is already in use for windows or at least can be. However does what does it mean for getting tumbleweed to use UEFI?

You are using GPT partitioning and have an ESP so you should be able to follow the link you showed in your first post.

So just switch to GRUB2 for EFI in Yast, boot into the biso and change to UEFI and it should work?

This part confuses me as I have tried finding that file path in the file explorer while showing hidden files and can not find it. Does that mean I have nothing to delete or does it have to be done in the terminal? I am not familiar with how I would do that yet

Do that at a terminal as root.

Just to explain a bit more: switching to GRUB2 for EFI may lead to errors. Because you did not boot with UEFI, your kernel is not seeing the EFI information.

However, if you already have your EFI partition mounted at “/boot/efi”, you can work around that.

If you uncheck the box “Update NVRAM Entry”, then it won’t attempt to do the part that will fail. So it will appear to work. But you won’t have a fully booting system.

Normally, it will also install fallback booting in “/boot/efi/Boot”, but only if that directory is empty. If you have been using Windows with EFI booting, then that directory is unlikely to be empty. That’s why I suggest removing everything in that directory. (You can copy the files to somewhere else, so that you can move them back later).

When you next try to boot, it should use the fallback to complete your boot installation.

Thank you for the help.

Does this mean it will never be a fully booting system or it just won’t be for the first boot after which everything should install and work?

I have had a read of the following article (UEFI boot: how does that actually work, then? | AdamW on Linux and more) explaining UEFI and can’t seem to understand why I would need to remove the “/boot/efi/EFI/Boot” files. My understanding is this is a specific file UEFI will look for in a specific location on the drive, but my windows partition and tumbleweed partitions are on separate drives so will have separate locations and thus switching tumbleweed to UEFI should not effect the windows files.

Please let me know if I am missing something here or have misunderstood as I am still getting my head around it all.

It may depend on the BIOS. Once it has booted to EFI mode, you could always use Yast Boot Loader and then check that box (update NVRAM) to make sure everything is working.

Normally, each operating system has its own boot files somewhere in the EFI partition. For Windows, that’s in a Microsoft directory.

When booting, the UEFI firmware looks at the entries in NVRAM (non-volatile RAM) to decide what to boot. But if there is nothing suitable in NVRAM, then it looks at “/boot/efi/EFI/Boot” for a file named “bootx64.efi”. That’s a fallback location.

Some operating systems will automatically place a file there as as a fallback. But openSUSE doesn’t do that unless the directory is empty.

All of this complication is because you cannot create a suitable NVRAM entry unless you booted in UEFI mode. So when switching from legacy boot you cannot directly create that NVRAM entry. So we needed a way of getting you booted in UEFI mode without an NVRAM entry.