Move your Linux from legacy BIOS to UEFI in place with minimal downtime

I don't know about you but I don't like to reinstall my operating system. I find it a complete waste of my time for something that should just update in place. Some people, often using other platforms, prefer a good once-a-year wipe and reinstall to regain the original speed of their systems. I just don't subscribe to this point of view. There are many ways to maintain a system and I usually prefer some investigative debugging rather than wiping and hoping for the best.

For this reason, systems like my work laptop might have started their life a long time ago (Fedora 22 on an i7-based 4th generation laptop) and have by now seen three hardware refreshes, several solid state drive (SSD) upgrades, and many Fedora updates (I currently use Fedora 32).

When I switch systems, I like to take my operating system with me and expect it to boot on the new machine. But it turns out that's a disaster waiting to happen because of hardware differences between the new and old systems. The problem is that it's not as simple as pulling your hard drive from an old system and popping it into a new one and expecting everything to work as desired. This article describes how to move a Linux install from one piece of hardware, in this case, an older laptop, to a newer one.

The big caveat or the ten years of advanced warning UEFI gave us

When Unified Extensible Firmware Interface (UEFI) was introduced in the early 2000s, it was designed to replace PC (Basic Input/Output System) BIOS and provide x86 users with something more technologically advanced. People with SPARC or PowerPC Mac systems with OpenBoot PROM (OBP)/OpenFirmware had already experienced the future many years before. UEFI wanted to evict the BIOS so its predecessors would no longer shame the PC.

For UEFI technology to be widely adopted, manufacturers opted to make it optional/selectable from the machine's firmware: Do you want to boot in Legacy BIOS or UEFI mode? Over the course of the next ten years, UEFI slowly pushed Legacy BIOS out and became the default mode for machines shipped by manufacturers.

To be fair, UEFI provides multiple advantages, including these:

• It makes multi-booting more reliable and flexible.
• It gives us (Linux users) the ability to run fwupdmgr to flash the firmware in our machines from within Linux. This includes almost any firmware, even add-on cards.

On my personal systems, I simply ignored the UEFI problem and kept enabling Legacy BIOS on any fresh new machine I would obtain so I could boot my Linux OS without giving it a second thought.

Then, 2020 came, and a brand new laptop showed up with UEFI only. No legacy booting of any kind (except on external USB sticks). Months later, a new portable Xeon-based workstation made its way into our home, and again that beast would only do UEFI.

I was stuck with a master boot record (MBR) formatted SSD (Legacy BIOS) and a machine that would only boot in UEFI mode. Being a tinkerer and a Linux user, I set out to research the issue, and the solution turned out to be not too difficult and would only require about five minutes once you've determined what to do.

A word of warning and some caveats

In finding the "right procedure" for my physical systems, I corrupted the test virtual machine I was using a few times. I also corrupted one of my laptop systems once, but I had a full image of my SSD thanks to CloneZilla. Here's some advice:

• Make a full image-level backup of your system before you proceed. You'll be touching your disks, and the tools used to make it easy to delete something without confirmation. You could use CloneZilla, AOMEI Partition Assistant, dd, or even Norton Ghost to do that. There are dozens of tools that do the job just fine.
• This procedure works even if you have a dual-boot machine. It works with Logical Volume Manager (LVM), plain partitions, and also with Linux Unified Key Setup (LUKS) or any combination thereof. You simply need to be careful and adapt the instructions to your configuration.
• Doing this procedure requires that you put your beloved SSD into a machine that can do both boot modes: Legacy BIOS and UEFI. If you attempt the procedure on a BIOS-only device, you'll have to wait until you move your HDD or SSD to a UEFI machine to know it worked.
• You don't have to physically move your SSD to another machine. You could simply clone the old MBR-formatted SSD onto a new SSD in another machine and work from there. You'll change the structure of the partitions on your disk. Whether it is a temporary device or a new SSD in a new laptop is entirely up to you.
• In the unfortunate case that you don't have any disk space you can free up easily on your SSD, there are still ways to operate. The last few hundred MBs of your LVM PV (Physical Volume) could be removed from its PEs and the LVM PV be resized to make room for the EFI partition. I won't describe this here, but you'll find some references at the end of the article. Another option is to take the opportunity to buy a slightly larger SSD and restore your Linux system onto it so you have some free space.
• Work through the process slowly and don't hesitate to ask questions online if you need help. There are dozens of Linux user groups out there who will help you if you are stuck.
• This article was written on a freshly reinstalled laptop system with Fedora 33 but applies to many different configurations.
• Do not try this if you use B-tree file system (BTRFS) with Fedora 33. I could not make it work after converting my disk to GUID Partition Table (GPT) when I used BTRFS.

Am I using Legacy BIOS?

There are two good indicators of a machine booted in Legacy BIOS.

1) Your boot disk has DOS/MBR partitioning:

[raistlin@localhost ~]$ sudo su -

[root@localhost ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       119G  7.1G  111G   6% /

[root@localhost ~]# file -s /dev/sda
/dev/sda: DOS/MBR boot sector

2) Your Linux kernel does not have EFI variables:

[root@localhost ~]# ls /sys/firmware/efi
ls: cannot access '/sys/firmware/efi': No such file or directory

On a UEFI-mode machine, the above yields output similar to this:

[root@localhost ~]# ls /sys/firmware/efi
config_table  efivars  esrt  [...]  runtime  runtime-map  systab  vars

Inspecting the boot disk and deciding on a strategy

From the above, I discovered that my boot disk is /dev/sda. Take a closer look with parted:

[root@localhost ~]# parted /dev/sda
GNU Parted 3.3
Using /dev/sda
Welcome to GNU Parted! Type' help' to view a list of commands.
(parted) p
Model: ATA LITEON L8H-128V2 (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 1075MB 1074MB primary ext4 boot
2 1075MB 128GB 127GB primary lvm

From the above, you see that only two partitions are present. The first partition is a small 1GiB partition, formatted as ext4 and it holds the kernels. The second partition is a different beast and is using LVM. As much as I've been happy with LVM on my Linux systems, I'll not touch it for the moment.

Consequently, I will use the space occupied by the first partition to make room for GPT and UEFI.

Please note that if you're using LUKS or LVM, the conversion to UEFI procedure might also be safer if you use the boot partition and its space.

If you picked up BTRFS (the default in Fedora 33), this might not work for you, and my initial attempt failed to boot right after converting the disk to GPT.

If your boot partition is smaller than 1G and all space is occupied by partitions, it may not be safe to make /boot smaller than 512-600Mib. You might not have enough space to proceed, and perhaps now might be a good time to get a slightly larger SSD onto which you could clone your system.

My name is /dev/sda1

The boot partition on this machine is 1Gib in size and has enough free space for us to proceed:

[root@localhost ~]# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       976M  238M  672M  21% /boot

First, resize the filesystem to 512M:

[root@localhost ~]# resize2fs /dev/sda1 512M
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/sda1 is mounted on /boot; on-line resizing required resize2fs: On-line shrinking not supported

Umount it first (You can, since Linux only mounts /boot as a convenience):

[root@localhost ~]# umount /boot

[root@localhost ~]# resize2fs /dev/sda1 512M
resize2fs 1.45.6 (20-Mar-2020)
Please run 'e2fsck -f /dev/sda1' first.

[root@localhost ~]# e2fsck -f /dev/sda1
e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 414/65536 files (0.7% non-contiguous), 63590/262144 blocks

[root@localhost ~]# resize2fs /dev/sda1 512M
resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/sda1 to 131072 (4k) blocks.
The filesystem on /dev/sda1 is now 131072 (4k) blocks long.

[root@localhost ~]# mount /boot

[root@localhost ~]# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       472M  200M  237M  46% /boot

The ext4 filesystem got resized, but the partition is still 1Gib in size. You will resize it next. You will shrink the partition to a size slightly over that of the /boot file system to be safe from rounding errors. Shrink it to 700Mib, which will leave about 300Mib free. Since the filesystem inside that partition is now 512Mib, it is safe to shrink the partition from 1024Mib to 700Mib.

[root@localhost ~]# fdisk  -l /dev/sda|grep sda1
/dev/sda1  *       2048   2099199   2097152     1G 83 Linux

[root@localhost ~]# parted /dev/sda
GNU Parted 3.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) resizepart 1 700M
Warning: Shrinking a partition can cause data loss, are you sure you want to continue? Yes/No? yes
(parted) p
Model: ATA LITEON L8H-128V2 (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Disk Flags:
Number  Start   End    Size   Type     File system  Flags
 1      1049kB  700MB  699MB  primary  ext4         boot
 2      1075MB  128GB  127GB  primary  btrfs
(parted) quit
Information: You may need to update /etc/fstab.

[root@localhost ~]#

Next, extend the filesystem back to the full partition size (700Mib):

[root@localhost ~]# partprobe

[root@localhost ~]# resize2fs /dev/sda1
resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/sda1 to 170642 (4k) blocks.
The filesystem on /dev/sda1 is now 170642 (4k) blocks long.

The resize operation concludes with growing the ext4 filesystem from 512Mib back to the size of the underlying partition, which is 700Mib.

I could also have used Gparted to monitor the progress of the previous steps. Here's a screenshot of the initial situation:

As soon as you resize the filesystem, a warning shows up:

After the boot partition itself gets resized to 700M, an unallocated row shows up in Gparted:

Once the file system is extended back to the partition size, the warning goes away:

Also, as is common under Linux, I could just have done the entire operation with a single click under GParted, but it wouldn't have been as much fun:

Converting the disk to GPT

With some free space available, you are now free to convert the disk to GPT. First, you need to install some tools :

[root@localhost ~]# yum install gdisk grub2-efi-x64-modules efibootmgr grub2-tools-efi -y Last metadata expiration check: 1:32:33 ago on Wed 27 Jan 2021 05:01:42 PM EST.
Package gdisk-1.0.6-1.fc33.x86_64 is already installed.
Package efibootmgr-16-9.fc33.x86_64 is already installed.
Package grub2-tools-efi-1:2.04-31.fc33.x86_64 is already installed.
Dependencies resolved.[...]

Use gdisk to convert the partition table to GPT and create the BIOS boot partition that GRUB needs. This partition will have the number 3 (the first available partition) and be carved out of the disk's first sectors (sectors 34 to 2047).

[root@localhost ~]# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.6
Warning: The partition table header claims that the size of partition table entries is 12255407 bytes, but this program supports only 128-byte entries. Adjusting accordingly, but the partition table may be garbage.
Warning: Partition table header claims that the size of partition table entries is 0 bytes, but this program supports only 128-byte entries.
 
Adjusting accordingly, but the partition table may be garbage.
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Command (? for help): p
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Model: LITEON L8H-128V2
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 6681F0D6-F645-4F97-93A5-E7E5E3912C62
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 734681 sectors (358.7 MiB)
Number  Start (sector)
   1            2048
   2         2099200
End (sector)  Size       Code  Name
   1367187   666.6 MiB   8300  Linux filesystem
 250068991   118.2 GiB   8300  Linux filesystem
Command (? for help): n
Partition number (3-128, default 3): 3
First sector (34-250069646, default = 1368064) or {+-}size{KMGTP}: 34
Last sector (34-2047, default = 2047) or {+-}size{KMGTP}: [Press Enter to accept 2047] Current type is 8300 (Linux filesystem)
Hex code or GUID (L to sho codes, Enter = 8300): ef02
Changed type of partition to 'BIOS boot partition'
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

Here is what the disk now looks like:

[root@localhost ~]# partprobe

[root@localhost ~]# fdisk -l /dev/sda|grep sda
Disk /dev/sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors
/dev/sda1     2048   1367187   1365140 666.6M Linux filesystem
/dev/sda2  2099200 250068991 247969792 118.2G Linux filesystem
/dev/sda3       34      2047      2014  1007K BIOS boot

Next, reinstall the GRUB boot loader. If you're on a more recent version of grub, instead of using grub2-install.... please use dnf reinstall shim-* grub2-efi-* instead:

[root@localhost ~]# grub2-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

[root@localhost ~]#

If you only wanted to convert your disk from MBR to GPT, that part is now finished. At this point, I'd recommend rebooting your system to verify that your BIOS-based machine can boot the freshly converted GPT disk.

Here's what the disk now looks like:

This can also be seen from the shell:

[root@localhost ~]# fdisk  -l /dev/sda
Disk /dev/sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors
Disk model: LITEON L8H-128V2
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: 6681F0D6-F645-4F97-93A5-E7E5E3912C62
Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1367187   1365140 666.6M Linux filesystem
/dev/sda2  2099200 250068991 247969792 118.2G Linux LVM
/dev/sda3       34      2047      2014  1007K BIOS boot
Partition table entries are not in disk order.

Adding the EFI System Partition

Next, use the space freed previously to create a fourth partition: The EFI system partition.

[root@localhost ~]# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.6
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Model: LITEON L8H-128V2
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 6681F0D6-F645-4F97-93A5-E7E5E3912C62
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2-sector boundaries
Total free space is 732667 sectors (357.7 MiB)
Number  Start (sector)
End (sector)  Size       Code  Name
   1367187   666.6 MiB   8300  Linux filesystem
 250068991   118.2 GiB   8E00  Linux LVM
      2047   1007.0 KiB  EF02  BIOS boot partition
1 2 3
   2048
2099200
     34
Command (? for help): n
Partition number (4-128, default 4): [Press Enter to accept 4]
First sector (1367188-250069646, default = 1367188) or {+-}size{KMGTP}: [Press Enter to accept 1367188]
Last sector (1367188-2099199, default = 2099199) or {+-}size{KMGTP}: [Press Enter to accept 2099199]
Current type is 8300 (Linux filesystem)

Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI system partition'
Command (? for help): p
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Model: LITEON L8H-128V2
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 6681F0D6-F645-4F97-93A5-E7E5E3912C62
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2-sector boundaries
Total free space is 655 sectors (327.5 KiB)
Number  Start (sector)
End (sector)  Size
   1367187   666.6 MiB
 250068991   118.2 GiB
Code  Name
8300  Linux filesystem
8E00  Linux LVM
1 2 3 4
   2048
2099200
     34
1367188
2047 1007.0 KiB EF02 BIOS boot partition 2099199 357.4 MiB EF00 EFI system partition

Next, add a label to the EFI partition to reference it later more easily. This is also done in gdisk:

Command (? for help): c
Partition number (1-4): 4
Enter name: EFI-system
Command (? for help): p
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Model: LITEON L8H-128V2
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 6681F0D6-F645-4F97-93A5-E7E5E3912C62
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2-sector boundaries
Total free space is 655 sectors (327.5 KiB)
Number  Start (sector)
End (sector)  Size
   1367187   666.6 MiB
 250068991   118.2 GiB
Code  Name
8300  Linux filesystem
8E00  Linux LVM
1 2 3 4
   2048
2099200
     34
1367188
   2047   1007.0 KiB  EF02  BIOS boot partition
2099199   357.4 MiB   EF00  EFI-system
 Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

You should now see the partition show up under /dev/disk/by-partlabel:

[root@localhost ~]# partprobe

[root@localhost ~]# ls -l /dev/disk/by-partlabel/
total 0
lrwxrwxrwx. 1 root root 10 Jan 27 21:57 'BIOS\x20boot\x20partition' -> ../../sda3 lrwxrwxrwx. 1 root root 10 Jan 27 21:57 EFI-system -> ../../sda4
lrwxrwxrwx. 1 root root 10 Jan 27 21:57 'Linux\x20filesystem' -> ../../sda1 lrwxrwxrwx. 1 root root 10 Jan 27 21:57 'Linux\x20LVM' -> ../../sda2

The EFI boot partition must be formatted as vfat:

[root@localhost ~]# mkfs -t vfat -v /dev/disk/by-partlabel/EFI-system
mkfs.fat 4.1 (2017-01-24)
/dev/disk/by-partlabel/EFI-system has 255 heads and 63 sectors per track,
hidden sectors 0x14dc94;
logical sector size is 512,
using 0xf8 media descriptor, with 732012 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 16 sectors per cluster.
FAT size is 192 sectors, and provides 45723 clusters.
There are 16 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is 855d115e, no volume label.

It is now time for us to mount this partition and move the data from the efi sub-directory formerly located underneath /boot but first verify whether the proper files were installed (the names will vary depending on your Linux distribution). Here’s what I have on my Fedora 33 system:

[root@localhost ~]# du /boot/efi
8       /boot/efi/System/Library/CoreServices
12      /boot/efi/System/Library
16      /boot/efi/System
2508    /boot/efi/EFI/fedora/fonts
17988   /boot/efi/EFI/fedora
2748    /boot/efi/EFI/BOOT
20740   /boot/efi/EFI
20764   /boot/efi
[root@localhost ~]# df -h /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       623M  237M  340M  42% /boot

[root@localhost ~]# find /boot/efi -name shim\*
/boot/efi/EFI/fedora/shimx64.efi
 
/boot/efi/EFI/fedora/shim.efi
/boot/efi/EFI/fedora/shimia32.efi
/boot/efi/EFI/fedora/shimx64-fedora.efi
/boot/efi/EFI/fedora/shimia32-fedora.efi

[root@localhost ~]# mount -t vfat /dev/disk/by-partlabel/EFI-system /mnt

[root@localhost ~]# mv  /boot/efi/* /mnt

[root@localhost ~]# umount /mnt

[root@localhost ~]# du /boot/efi
4 /boot/efi

It is now time to add this partition to /etc/fstab and mount it:

[root@localhost ~]# echo ‘/dev/disk/by-partlabel/EFI-system /boot/efi vfat defaults 0 2’ >> /etc/fstab

[root@localhost ~]# mount /boot/efi

[root@localhost ~]#

Some verification is in order at this stage. The EFI partition should be mounted and hold the data you copied previously:

root@localhost ~]# df /boot/efi
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/sda4         365784 20832    344952   6% /boot/efi

[root@localhost ~]# du /boot/efi
2760    /boot/efi/EFI/BOOT
2512    /boot/efi/EFI/fedora/fonts
18024   /boot/efi/EFI/fedora
20792   /boot/efi/EFI
16      /boot/efi/System/Library/CoreServices
24      /boot/efi/System/Library
32      /boot/efi/System
20848   /boot/efi

It is now time to reinstall the GRUB boot loader and enforce UEFI booting. As above, if you're a newer version of grub, instead of using grub2-install.... use dnf reinstall shim-* grub2-efi-* instead:

[root@localhost ~]# grub2-install --target=x86_64-efi /dev/sda
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub2-install: error: efibootmgr failed to register the boot entry: No such file or directory.

[root@localhost ~]#

The three error messages displayed above are normal and related to the absence of EFI firmware variables. This happens at the current point in time because you last booted the PC in Legacy BIOS mode. Once you're in full UEFI mode, these errors will disappear. Take a deep breath, reboot your PC and get ready to enter its firmware to change its boot mode.

[ You might also like: How to set up PXE boot for UEFI hardware ]

Shutting down and switching the firmware from Legacy BIOS to UEFI.

The following captures are specific to the system on which I performed the procedure. You should look up the instructions in your system's manual to figure how to switch from BIOS to UEFI. Here's an example on my laptop:

Save the settings and exit the firmware. Your PC will reset, and it will attempt to boot from your disk in UEFI mode. You might have to select your disk manually the first time you will be booting in UEFI mode.

Successful boot

Right after bootup, log in and start enjoying your UEFI-rejuvenated Linux. Yes, all of your files, accounts, and programs will still be there.

[root@localhost ~]# efibootmgr
BootCurrent: 0014
Timeout: 0 seconds
BootOrder: 0014,0013,0009,000D,0007,000A,000B,000C,0008,0012
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  Rescue and Recovery
Boot0006  MEBx Hot Key
Boot0007* USB CD
Boot0008* USB FDD
Boot0009* ATA HDD0
Boot000A* ATA HDD1
Boot000B* ATA HDD2
Boot000C* USB HDD

Boot000D* PCI LAN
Boot000E* IDER BOOT CDROM
Boot000F* IDER BOOT Floppy
Boot0010* ATA HDD
Boot0011* ATAPI CD
Boot0012* PCI LAN
Boot0013* Windows Boot Manager
Boot0014* Fedora
[root@localhost ~]# fwupdmgr get-devices|grep -i lenovo
 │ Vendor: │ Vendor: Vendor:
LENOVO (DMI:LENOVO)
DMI:LENOVO
DMI:LENOVO

Gparted shows the final state of the disk:

[ Free cheat sheet: Get a list of Linux utilities and commands for managing servers and networks. ] 

Wrap up

Whether you like to reinstall fresh or update your operating environment in place, there are many ways to successfully get there. I know where my own preference lies and this blog post attempts to share some of the tips I've recently learned. Be careful. Check the output of your commands. Ask for help if you need some. Also, there are tools in other operating systems to make it easier to convert if you're so inclined—one such example is the free AOMEI Partition Assistant for Windows platforms.

Amusingly, even though this laptop running Fedora 33 successfully switched from BIOS to UEFI with GPT, no firmware updates were available for it through LVFS since the system was too old.