On 2021-11-24 12:49 p.m., Daniel Villarreal wrote:

I've not done that, but first I'd recommend doing a backup/clone to the new drive with the old setup.

As I mentioned I will be copying from one drive to the other, as I have done before.  The question is regarding any issues with switching to UEFI.  I'll also be enlarging some of the partitions too.  The Linux partitions are easy, just use cp -a to copy the contents, though I may use dd for the boot partition.  I'll probably also use dd for the Windows partition and then resize it.  Or I could just dd all partitions and then resize/move as needed. Regardless, the original drive will not be changed in the process, so no risk there.

I wholeheartedly agree with Hugh here. Doing such a fundamental transition using an existing install is more trouble than it’s worth in my experience.

On Nov 25, 2021, at 09:40, D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

Personally, I have done clean installs for these transitions. Clean installs are easy and they tend to result in a cleaner system. Superstition again.

| From: William Park via talk <talk@gtalug.org> | Personally, I don't like UEFI. I mostly like UEFI. + UEFI is less hacky than BIOS + UEFI knows it is running on a 32 or 64-bit system; BIOS thinks it is running on an 8088 + UEFI can be called from a modern OS; BIOS can only be called by 8088 code that doesn't use interrupts for I/O. - UEFI supports only one architecture on x86: 32-bit or 64-bit, even though modern processors can do both + BIOS is too simplistic but UEFI is too complicated. - old-timers kind of understood BIOS well enought to live with it (but try explaining the oddities to newbies!) - old-timers have to start over with UEFI. But they/we have had plenty of time to make our peace with it. + UEFI makes dual-booting work better. Usually. - there is plenty of room for vendors to make awkwared UEFI firmware | If you change motherboard, you can't boot. | Personal experience! That should be easy to fix. But it involves new skills. Why would the system not boot? My best guess at what you experienced is that the UEFI firmware didn't know the path the the .efi file to boot. The firmware setup screen should let you specify the path. But some firmware is pretty bad at that. In desperation, you can take matters into your own hands. The path lives in non-volatile memory. If you cannot get the firmware to set it to what you want, you can boot a live Linux USB stick and use the tool efibootmgr(8). Here's an example from my system. This is a summary that doesn't show important details. [hugh@redeye ~]$ sudo efibootmgr BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0003,0001,0002,0005,0006,0007,0008,0009 Boot0000* Fedora Boot0001* USB Floppy/CD Boot0002* USB Hard Drive Boot0003* Windows Boot Manager Boot0005* ATAPI CD-ROM Drive Boot0006* CD/DVD Drive Boot0007* USB Floppy/CD Boot0008* Hard Drive Boot0009* Realtek PXE B03 D00 BootOrder is a variable that lists the sequence of entries to try. The first is "0000" meaning Boot000, which is Fedora. The whole fedora entry looks like this: Boot0000* Fedora HD(2,GPT,f66e4ede-1301-47fd-af96-7f45aee7bc28,0x40800,0xb4000)/File(\EFI\fedora\shimx64.efi) I read that as: The entry variable is called Boot000. The * means that it is bootable. The entry label (for human purposes) is called Fedora. The path is on the second hard drive [I think that's what 2 means] which is GUID-paritioned and the ESP (EFI Sytem Partition) has a UUID of f66e4ede-1301-47fd-af96-7f45aee7bc28. There are a couple of hex numbers that I don't understand. The file's path within the ESP is EFI\fedora\shimx64.efi Trivia: Windows entries include some parts in UTF16. What a pain!