Is a USB stick required to complete a UEFI install of Ubuntu 20.04 or can it be accomplished with two SSD disks instead?

Question

I almost follow the instructions given at How To Install Ubuntu 20.04 LTS (Focal Fossa) On UEFI and Legacy BIOS System to try to install a UEFI-based Ubuntu operating system. But it does not work, not with an erase-and-install from a UEFI-optioned Ubuntu Live SSD even.

The trick is that I downloaded the image file and copied it to an SSD instead of a USB stick, using the same dd command as in the previous reference. And the good part about that is that it shows both options, the Legacy Boot and also the UEFI boot in the Bios selection menu, for the Ubuntu Live image.

Indeed, when I boot the UEFI Live Ubuntu image on the SSD, I also have the install option to make a UEFI partition, even with a complete erase and install. And Ubuntu-Live is smart enough also that it recognizes that the disk that it is booting from is not the disk to install the regular operating system on.

Everything seems to go smoothly with the install, with the Ethernet Internet Cable plugged in for the latest updates. And at the installation's conclusion, there is even the message that it completed fine.

But alas, after the installation, there is no UEFI option for the installed Ubuntu LTS Operating System. There is just a single option for the disk. And selecting simply does not work from the BIOS menu.

The ironic part is that I am able to update the GRUB-configuration file for the Ubuntu-Live operating system. So, if I enter "c" to get to the GRUB-Live-UEFI-command-line, I am able to navigate to the .efi UEFI image as expected in its place. And I can even issue the chainloader command. See the section menuentry "GRUB chainloader".

And I do not need to load any special modules. I do, however, after the chainloader command on the Live-GRUB-command-line need to issue the boot command.

And all goes well, with the Ubuntu LTS system (regular install, not Live SSD) booting fine. I know it is a UEFI boot because I boot with the chainloader to an .efi image. Just as an aside: I tested it with Memtest86 Version 10.1.0009 that only boots in UEFI using the same technique. And it works also just the same.

So the GRUB image from the Live disk works fine. I can even update its configuration. But the one from the LTS install is hopelessly broken. I tried a lot of different references. Just recently, one reference Section 5.4. Using chroot completed without error. But, still, the install does not work. For that disk, it does not show any UEFI boot option in the boot menu. It is just one entry. And when I try to boot from that top entry, the system goes on to boot the next entry. Perhaps the bios cannot have two internal UEFI disks. It would seem odd if so.

I am stuck. I have enough space for the 3.6 GB image that needs to be copied to the USB stick Ubuntu Focal ISO Size Descriptions and Download Links. But for all of the other issues that I have encountered so far with booting, I have found that the end-resolution is workable with internal SSD drives as well. I have plenty of internal SSD drives to use as candidates, nearly for free. So these internal SSD drives (nearly perfect health, with just life-time wear issues) are a very attractive approach.

I appreciate the community's help and suggestions. Thank you.

Update: I finally got frustrated enough to order and use the USB stick according to web-published instructions. I downloaded a fresh version of ubuntu-22.04.1-desktop-amd64.iso, and I copied it using dd following the instructions at this reference. Since only the USB stick is so small, it is easy to identify which device file it is using cfdisk -l. When I go to the BIOS boot menu, I am able to see both UEFI and Legacy options for the USB stick Live Image boot. The SSD where the Desktop Version is installed, however, has only one entry; and selecting that entry does not boot, but results in an error that there is no boot-able operating system. However, I am able to select the Live USB stick, select c to enter the command line for GRUB. And I can even navigate to the SSD installation and successfully boot to it using chainloader and then boot. And I know that I am booted to the UEFI image because I booted to the .efi file and also I can check it using the /sys/firmware/efi (see: itsfoss check-uefi-or-bios) method.

Update: I downloaded the Ubuntu 22.04.1-desktop iso. As root, I opened the .iso image with Disks. There were three partitions in the image. I decided to isolate the issue. The first partition was an unknown file system type. The second one was the UEFI vfat. And the third was unknown. So I just copied the first two partitions to an SSD and I was able to boot fine, with BIOS recognizing both the Legacy and the UEFI options. Just as an aside, every time that the BIOS boot recognizes the both options, it is able to boot. And every time there is just the one option, it is not.

So I continued with the Linux install. The Linux install complained that the UEFI partition was too small. So I just resized the partition, erased it completely with dd. Then I installed a FAT32 because I expanded it to something like 10 GB, and FAT16 or FAT12 could not handle that size.

The Ubuntu Live disk was able to complete its install. And now as to be expected, after the system was unable to find the operating system. So I used the USB boot disk workaround in command line mode (in GRUB); I was able to navigate to the Ubuntu operating system and indeed boot from it.

But still GRUB on the SSD boot disk was not available. So I used dd with an offset and the same number of 512 Byte blocks to transfer the first partition back to the SSD from the Ubuntu .iso image. I erased the contents on the larger UEFI second partition, using dd if=/dev/zero to the FAT32 file system. Then I FAT32 rebuilt the file system and copied everything over again with gnome-disks and the root terminal.

So I was able with the USB stick to again navigate and boot to the SSD Ubuntu operating system. And I made the Grub changes recommended by PassMark Memtest GRUB install to update the GRUB on the internal SSD. I verified that the security was completely off in the BIOS and that it was running in ACHI mode. The USB stick had to boot with Legacy support though in the BIOS. It kind of worked.

It now boots from the internal SSD, but only if the USB stick is attached!!! That is bizarre, and still not a very comfortable solution. The solution should not require an external USB stick to boot!

Update: I bought another 16 GB USB stick and I installed Ubuntu ubuntu-22.04.1-desktop-amd64.iso on it using the Linux Startup Disk Creator. I changed the computer that I ran the desktop install on, roughly following the instructions at itz geek post how to install ubuntu 20 04 lts, just adjusting the size of the home partitions and root partitions, I remember. I have a larger 240 GB SSD, and that installation was somewhat successful. On one computer, it basically works, except that I cannot access the grub menu, even after reinstalling grub using grub-install, using the X64 UEFI instructions. There was a problem with grub-install not recognizing the /boot/efi directory as legitimate. The problem was I needed to pass grub-install the /boot/efi/EFI directory and everything was fine -- only with one computer.

On the one computer, with the new installation, it boots to UEFI Ubuntu fine. The other does not show the two install options and it does not boot fine.

There seems to be some incompatibility in the one computer that does not boot. Perhaps something broke down. I am not sure. An older SSD disk that I made for Ubuntu Live using dd boots fine. The whole thing is still very odd for me.

If there are additional suggestions, please let me know. Thank you.

Additional Related References:

Memtest86 hangs on Boot from USB -- PassMark Support Forums with Download Link for the 10.1.0009.zip file

Answer 1

Update: today I was able to just use SSD disks and dd if=/....iso of=/dev/sda conv=sync to generate the boot disk. This was from a different computer than the one that was giving me trouble. I used two separate SSD's, one with the image file. The other I loaded the Ubuntu 20.04.01 LTS live image on it.

Strangely enough, the image was not able to boot in uefi mode as verified with /sys/firmware/efi not existing. Strangely enough also, I was initially able to set the first partition as a 2GB FAT16 UEFI partition type. (FAT16 supports up to 4 GB). And I got a warning that Reserved BIOS space of at least 1 MB needed to be allocated in the first SSD partition.

 Device    Size  Type
/dev/sda1  1M    BIOS boot            
/dev/sda2  15.3G Linux swap
/dev/sda3  46.6G Linux filesystem
/dev/sda4  46.6G Linux filesystem
/dev/sda5   1.9G EFI System

The partition table I set is above. I again basically followed How To Install Ubuntu 20.04 LTS (Focal Fossa) On UEFI and Legacy BIOS System adjusting the partition sizes to my liking. The first time, the Unix partition tool crashed after making its partitions. I tried again and everything was fine.

I kept the live disk inside the system. Sure enough the Ubuntu install had corrupted the GRUB boot loader. It understandably installed a Legacy loader because it booted in legacy mode.

So, I had to use grub-install, following the Ubuntu man page. There are some surprises. First, the UEFI directory was initially /boot/efi. With that grub-install gives a cryptic message that this does not look like a UEFI directory. That is because grub-install expects /boot/efi/EFI as the UEFI install directory. Also, one has to select the 64 bit UEFI type of install. And a really big surprise is that the removable option has to be selected or else grub-install gives another cryptic option.

I had to carefully adjust the BIOS of the computer to boot in UEFI mode. After a few more difficulties being solved - (sorry I am limited on time now) - I set secure boot off and the OS type as not Windows, in the BIOS. I installed the PassMark 10.1.009 MemTest following the instructions linked in the question along to the link to the 10.1.009 download listed in the question.

And Thank G-d that it worked on the one computer. I have not tested it on the other (previously problematic computer). It may be that the disk now works there too, but that would be an update to the answer.