First, let's clear up a terminology issue that may be leading you astray (although it's unlikely to be the cause of your main problem). You wrote:
My guess is that this means the fact that the live environment was booted in BIOS mode makes it impossible for a new kernel to be loaded and interact with the GPT, despite if the kernel supports it, and that the same problem is occurring with other distros.
The GUID Partition Table (GPT) is a disk-based data structure that defines your partitions. It does not control the boot process, although the boot process will use GPT to help it find boot files. GPT may be used in either a BIOS-mode or an EFI-mode boot, but in different ways:
- In a BIOS-mode boot, the BIOS reads the first sector of the disk and executes code stored there. This code normally loads code stored elsewhere on the disk, which then loads other code, and so on until the kernel is running. Details vary with your boot loader.
- In an EFI-mode boot, an entry in the computer's NVRAM (off the disk) points to a file on the EFI System Partition (ESP), which is a FAT partition that holds boot loaders and related data. The EFI runs this file as an EFI program, and this file (the boot loader) loads the kernel and executes it.
Note that in EFI mode, the boot process relies on data stored in NVRAM. This NVRAM-based data may be accessed and changed in an OS, but to do so, the computer must be booted in EFI mode; you can't change EFI boot variables in BIOS mode. These variables are not stored in GPT data structures, though; and the only relationship they have to GPT data is that they encode a partition's GUID value so that the EFI can load the right file from the right partition.
That out of the way, there's an elephant in the room:
when I enable support for BIOS/Legacy mode booting, all linux installations can begin but they randomly crash during the installation process.
When a program or OS (especially a mature and robust OS like Linux) fails "randomly," that's almost always a sign of a hardware problem. If I had to put money on it, I'd say "bad RAM," but there are other possibilities, too, such as a bad CPU, a bad hard disk, a damaged trace on your motherboard, or a bad power supply. You might be able to work past your EFI issues, but it's very likely it won't be any more reliable than your BIOS-mode boots. If this is a new computer, you should seriously consider returning it for a refund and get another one for this reason. If it's not new, the question is whether it might have exhibited problems before now. For instance, if you're trying to install Linux because Windows was crashing, it could well be that those crashes were caused by the same bad hardware that's causing your Linux installs to fail.
Moving on to the installation issue, your steps for booting in EFI mode sound reasonable; however, you should carefully review the boot options in your boot manager (whatever key you hit to get a menu of boot options that include your USB drive). Most EFI-based computers that also support BIOS-mode booting provide two boot options for USB drives and optical discs: One includes the string "UEFI" and the other doesn't. The string with "UEFI" in the description boots in EFI mode and the other one boots in BIOS mode. To start the installer in EFI mode, you must select the "UEFI" option.
If you're doing this, it's conceivable that your firmware is flaking out on the Frankenstein's monster nature of a dd-created USB drive. If your computer has an optical disc, try that instead. If it doesn't, try using another tool to create your USB drive. Unfortunately, this can be tricky to get right, because some tools (especially older ones) lack the ability to create an EFI-bootable image. Read the instructions for whatever you use to be sure it supports EFI-mode booting. Some tools require you to select particular options to make an EFI-bootable disk. I can't be more specific than this because I don't recall the details of what I've seen; I generally use dd-created images myself.
Another option is to use my rEFInd boot manager to control the boot process. You can download several images, including ones intended to be written to CD-R or USB flash drive. rEFInd may be able to redirect into your USB-based installer; or you can install in BIOS mode and then use rEFInd to boot the installation. (EFI-mode and BIOS-mode installs of Linux typically vary only in their boot loaders, and rEFInd on a USB drive or CD-R can fill that role.)
Best Answer
First, disable your Compatibility Support Module (CSM), aka "legacy mode support." Having it enabled complicates the boot path and sometimes directs the boot mode down that road even when you don't want it to do that. While you're in the firmware setup utility, you may want to re-enable Secure Boot. Although it does sometimes cause problems, it usually doesn't. (Many reports of Secure Boot problems actually have other causes.) You can always re-disable Secure Boot if you run out of other options. Secure Boot, as the name implies, is a security feature, so you probably shouldn't be disabling it unless you're certain you need to do so.
If that's not sufficient, use your firmware's boot manager. This tool is usually accessed by hitting Esc, Enter, or a function key (usually F8 or above). Most modern EFIs show two options for booting external boot media, one of which includes the string "UEFI" and the other of which doesn't. Pick the option that includes the string "UEFI" to boot in that mode.
If that doesn't work, then chances are your boot medium was prepared incorrectly. You didn't say what tool you used to create your USB drive, but quite a few are available. Rufus seems to have the best reputation among Windows programs and Unetbootin usually works and is cross-platform. Neither is guaranteed to work, though. Note that Rufus has at least three options for different partition table and boot loader combinations, so be sure to use an option for creating an EFI-compatible medium.