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.
About the author
Vincent Cojot is a repentless geek. When he's not fixing someone else's OpenStack or RHEL environment, he can be seen trying to squeeze the most efficent use of resources out of server hardware. After a career in the banking and telco industries, he thinks there's nothing as much fun as working for an Open-Source software company.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit