Ubuntu – Can’t boot a live usb .iso in UEFI mode on Lenovo Edge-15 laptop

gptlive-usbsystem-installationuefi

I was trying to install Gentoo on my laptop Lenovo Edge-15, but I'm having problems booting a live usb .iso in UEFI mode. I then tried to install Ubuntu, Arch, and Fedora, and seem to be having the same problem with all of them.

Through copious amounts of experimentation/trial/error, I've gathered that my laptop is refusing to boot my USB flash drives into UEFI mode for some reason. Secure boot is disabled. I've and enabled/disabled USB booting with expected results, and I've also enabled/disabled support for Legacy/BIOS mode booting. When I support only BIOS mode booting, no Linux installation will ever start, but when I enable support for BIOS/Legacy mode booting, all linux installations can begin but they randomly crash during the installation process.

EDIT to be more specific, when loading from USB media with Legacy mode/bios mode allowed, when installing Linux, the liveCD environment always begins to load, but then randomly crashes before the system is fully set up. At this point, I am dropped into a shell with no drivers, no internet and no distribution utilities, just a few shell built ins. When I tried to install Gentoo, I actually wrote the Gentoo install .iso to it's own partition on my hard drive beforehand. Then when I tried to boot from the Gentoo USB, the Gentoo pre-install live environment loaded from this disk partition as if it was an install CD and couldn't detect the USB.

During my attempt to install Gentoo, when I reached the step for writing the boot instruction to the GPT, I got an error message saying UEFI variables are not supported on this system, despite the fact that this occurred right after (in the Gentoo process) I had just compiled the Linux Kernel and manually and specifically enabled support for UEFI variables. The same error message ocured weather I tried to write an instruction to load GRUB2 or when I used uefiloader.

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.

I have a separate laptop (it has a BIOS mode drive and no Windows OS) and I have tried the same procedures and was able to install a fresh Kubuntu.

The procedure I have been using to attempt each Linux install was to download the *.iso file on my old linux laptop, sudo su, dd bs=4M if=linux.iso of=/dev/sdb && sync (after checking the correct /dev/ with lsblk), and then booting the usb on my new laptop.

This related question directed me to check out This tool. I tried using it (with Legacy/BIOS booting enabled) and curiously, my laptop refuses to boot it. Don't know if that helps.

I had installed Kubuntu before, so I know it's possible with this hardware, but something has changed that is making it fail. It could possibly be due to the original Kubuntu installation itself a several months ago, a failed Arch Linux installation attempt later, and a failed Kali Linux installation attempt a little later.

So can anyone help me figure this out? Why is my system not booting usb ISOs in UEFI mode?

Best Answer

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.)

Related Question