Change installed system from GRUB to GRUB for EFI before upgrade to 15.1

English Install/Boot/Login
1

My issue is quite similar to this https://forums.opensuse.org/showthread.php/537764-Upgrading-an-existing-openSUSE-installation-from-a-standard-BIOS-motherboard-to-UEFI but probably simpler.

I want to upgrade a Leap 15.0 system to Leap 15.1. Although the hardware fully supports, and is configured for, booting in secure boot UEFI mode, the system currently boots in legacy mode (don’t ask – life’s too short) but it seems that nowadays secure boot is preferred. The existing (Leap 15.0) system seems to be set up for UEFI already:

From parted -l


Model: ATA KINGSTON SV300S3 (scsi)                                                                                                                                                                                                                     
Disk /dev/sda: 480GB                                                                                                                                                                                                                                   
Sector size (logical/physical): 512B/512B                                                                                                                                                                                                              
Partition Table: gpt                                                                                                                                                                                                                                   
Disk Flags: pmbr_boot                                                                                                                                                                                                                                  
                                                                                                                                                                                                                                                       
Number  Start   End     Size    File system     Name     Flags                                                                                                                                                                                         
 1      1049kB  8389kB  7340kB                  primary  bios_grub
 2      8389kB  436MB   428MB   fat16           primary  boot, esp
 ...
 6      343GB   480GB   137GB   xfs             primary  legacy_boot, msftdata

From gdisk -l /dev/sda


Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           16383   7.0 MiB     EF02  primary
   2           16384          851967   408.0 MiB   EF00  primary

From /etc/fstab


UUID=4D09-B9A3       /boot/efi            vfat       umask=0002,utf8=true  0 0

From /etc/mtab


/dev/sda2 /boot/efi vfat rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

From file -sL /dev/sda2


/dev/sda2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 16, root entries 512, Media descriptor 0xf8, sectors/FAT 208, sectors/track 63, heads 255, hidden sectors 16384, sectors 835584 (volumes > 32 MB), reserved 0x1, serial number 0x4d09b9a3, unlabeled, FAT (16 bit)

When I tried to upgrade to Leap 15.1 the installer noticed that it had booted with UEFI but the installed system was legacy mode and it warned me in bright red text that proceeding with the upgrade was not a good idea. So I aborted the upgrade and booted Leap 15.0 and used YaST to try to change the boot loader from GRUB to GRUB for EFI. YaST didn’t like that; it gave the error:


Execution of command ""/usr/sbin/shim-install", "--config-file=/boot/grub2/grub.cfg","--no-nvram","--removable"]]" failed
Exit code: 1
Error output: Installing for i386-pc platform.
/usr/sbin/grub2-install: error: install device isn't specified.

The only anomaly that I can see in the existing installation is that /dev/sda2 is FAT16 rather than the requisite FAT32. Is that the only issue preventing the change to GRUB for EFI? Or is it more complicated than that?

Obviously if I reformat /dev/sda2 then I’ll lose its contents, but does that matter while the system is booting in legacy mode? That is, assuming that /dev/sda2’s format is the problem, if I use some partitioning tool to change it to FAT32 will the system still boot in legacy mode given the rest of /boot is on /dev/sda6? I’d rather avoid killing a working system and then having to spend time rescuing it if there is instead a right way to all this.

Your helpful advice will be gratefully received.

2

This is fixed in Tumbleweed. You can disable secure boot both in BIOS and YaST, and then after finally booting in EFI mode enable it again (if required) - first in Yast so it installs correct bootloader and then in BIOS.

3

I’m pretty sure that works, without error, in Leap 15.1. Or, at least, it works if done at the command line. I don’t know about doing that with Yast.

The only anomaly that I can see in the existing installation is that /dev/sda2 is FAT16 rather than the requisite FAT32. Is that the only issue preventing the change to GRUB for EFI?

That will only be a problem if your UEFI firmware is exceptionally fussy. Most will accept FAT16.

Obviously if I reformat /dev/sda2 then I’ll lose its contents, but does that matter while the system is booting in legacy mode?

That only matters if the content is important. If the only important content is what will be replaced by your install/update, then it should not be a problem.

Generally speaking, the safest way to switch an existing system to UEFI booting is:

1: Boot rescue media to UEFI mode. Booting the installer to the rescue system can work for this, but you have to boot to UEFI mode.

2: Mount the system that you are trying to repair.
Use something like:

mount /dev/sdaX /mnt

but replace “/dev/sdaX” with the proper device for your root file system.

3: Do other needed mount (bind mounts)


mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

4: Go into chroot mode


chroot /mnt
mount -a

That last mount command, in chroot mode, should mount anything else needed. This includes “btrfs” subvolumes, the EFI partition at “/boot/efi”, etc.

5: While still in chroot mode, run “yast” at the command line. And change to UEFI booting. Since you are running in UEFI mode in the chroot session, this should work. You will be using the command line “ncurses” version of Yast.

6: Maybe also, while still in a chroot session:


grub2-mkconfig -o /boot/grub2/grub.cfg
mkinitrd

7: Exit from the chroot session (just the command "exit:).

8: Reboot

4

It is unrelated to YaST. It was problem with shim-install which is fixed in 15.1 (same as in Tumbleweed). I guess one could simply update shim to 15.1 version on 15.0, it is pretty much self contained.

5

Thank you nrickert for the detailed instructions. System maintenance isn’t my day job so the detail is always greatly appreciated.

Also thank you arvidjaar. Are you saying that if I follow nrickert’s steps it might still not work because I will still be using 15.0’s version of shim? I’ve grabbed 15.1’s version from the repositories but haven’t tried to install it yet (so don’t yet know how “self contained” it is), but if shim rather than YaST was the problem should using YaST with the updated shim – assuming it installs – now work properly on my running 15.0 installation without having to go via the rescue disk? Or are you saying that I need the updated shim before I can follow nrickert’s steps?

6

More or less. The command that was shown should not fail any more, also when called from YaST.

Or are you saying that I need the updated shim before I can follow nrickert’s steps?

No, I did not mean it. These steps do not depend on updated shim because they call shim-install when booted in EFI mode already and this problem is not triggered then.

7

Thanks arvidjaar. zypper installed the updated shim without problem and YaST changed to GRUB for EFI without any error message. I rebooted the machine OK although there was a brief heart-in-the-mouth moment when GRUB drew a rectangle on the screen before clearing it and carrying on with the boot as normal.

Now I’ll see if the upgrade to 15.1 works this time.

Thank you both for your help.

8

Unfortunately, not. I have checked and double checked (and triple checked!) the machine’s boot options: the BIOS management screen is headed “ASUS UEFI BIOS Utility” (with a footnote that copyright is held by American Megatrends, Inc.) and the Boot options screen shows that secure boot state is “Enabled”, platform key (PK) state is “Loaded” and OS type is “Windows UEFI mode”.

But my Leap 15.0 installation does not have a /sys/firmware/efi directory. No surprise then that

# efibootmgr -v
EFI variables are not supported on this system.

but I am surprised that Linux boots at all given that the bootloader is now GRUB for EFI.

Can the missing firmware be installed somehow? I have searched the repositories using YaST but cannot see anything that looks a likely candidate. Or does it mean that the standard distribution doesn’t support my hardware? That is, if the efi firmware was available it would have been installed already.

Finally, in desperation: I’m trying to avoid it because it means a great deal of effort recreating my development environment, but would a clean installation of Leap 15.1 into a new partition make these issues go away or are the problems systemic?

9

It has absolutely no impact on what your BIOS does. It is your BIOS that decides how it will boot, not anything you can do via YaST. Check your BIOS options.

10

You actually have two versions of grub installed. You have grub for legacy BIOS booting – this is mostly in “/boot/grub2/i386-pc”. And you have grub for EFI (mostly in “/boot/grub2/x86_64-efi”). And the same “grub.cfg” will work for either.

Your system configuration says you are using grub for efi. But both are there, and what works depends mostly on your BIOS and how it starts the boot process.

11

It sounds, then, like the problem is systemic. The BIOS options that I have available to me through the machine’s BIOS management screens, as quoted in my previous post, say that the machine is using UEFI mode. If the lack of an efi firmware directory (/sys/firmware/efi) is not relevant, then is efibootmgr -v actually telling me that EFI variables are supported on this machine?

12

Options that you described in your previous post simply say that if you boot in EFI mode you will have secure boot.

If the lack of an efi firmware directory (/sys/firmware/efi) is not relevant, then is efibootmgr -v actually telling me that EFI variables are supported on this machine?
If you have question about “efibootmgr -v” output then show this output. But lack of /sys/firmware/efi directory means that you are booted in Legacy BIOS mode, so efibootmgr is not going to work.

13

No. It is telling you that the kernel failed to communicate with the UEFI firmware, presumably because you did not boot with UEFI.

14

There seems to be something that you both assume that I know that I don’t actually know, so: If setting both the machine’s (ASUS UEFI) BIOS to “Windows UEFI mode” and the bootloader to “GRUB for EFI” isn’t enough to cause EFI booting, then what is needed to cause it? There are no other options to set on the machine’s BIOS nor can I see any other options in YaST beyond setting GRUB for EFI. What am I missing here?

15

I don’t know the answer to that. Different BIOS behave differently.

On my main desktop, I can hit F12 during boot. And it will give me a list of boot choices. Both UEFI boot choices and CSM (legacy) boot choices are there. If I plug in a USB that is bootable either way, I get to choose which way I want to boot it.

On my other UEFI box (a Lenovo desktop), I can use F12. But it only lists UEFI boot options unless I make BIOS setting changes – and then it only lists CSM boot options.

Some BIOS look at the “pmbr_boot” flag and use that to decide how to boot. Maybe a web search for “pmbr_boot” will give some information about that.

16

That may well be part of the problem. This UEFI fails to detect boot disk | Support | SUSE from June 2019 (enterprise SuSE I know but maybe still relevant) suggests the flag needs to be set off. YaST leaves the flag as it found it, which on my system is On probably because it has been booting in legacy mode; YaST also suggests it be left alone unless one is an expert – and you will have gathered that I am far from that – so I had ignored that drop-down list.

There is still the matter of the missing /sys/firmware/efi directory; is that not mandatory?

17

What exactly you do not understand in “this directory appears only if Linux was booted in EFI mode. If this directory is not present, it indicates your system was booted in Legacy BIOS mode”? And indeed, pmbr_boot can well cause BIOS to not attempt EFI at all: 932033 – pmbr_boot disk flag should be off for UEFI boot

18

That is a logical thing, not a physical thing. It is created by the kernel when it finds that it was booted in EFI mode and is able to communicate with the EFI firmware.

19

You may consider running a live system in UEFI mode, which is a great way to check your machine: How To Try openSUSE Without Making Any Changes To Your PC - openSUSE Wiki

20

That is of course quite possible and I think that reading this discussion I detected one. Unless you now understand from @avidjaar and @nrickerts posts above, it is that /sys (same for /dev and /proc) is a file system (of a special type) created only by the kernel at boot and existing only as long as a Linux system is running.:

boven:~ # mount | grep '/sys '
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
boven:~ #

That means you can not find it’s contents in an unused / file system. of a not booted Linux.

You will now understand that neither a person, nor the BIOS at boot time, nor Grub can ever have anything to do with it before a Linux kernel is loaded. And that what is in it can only point to what happened during boot and not to what should happen.