Must a 20.04 live-boot installer be UEFI/GPT to create a UEFI/GPT SSD install?

[sudodus]

I do have a question about the SSD drive I want to install to: Is my current formatting of it correct or workable?

Right now I have that (empty) SSD formatted like this:

(a) its partition table is set as GPT;
(b) it has a 200 MB allocated empty space at its beginning;
(c) its first partition is a fat32, one-GB to be used as the ESP;
(d) its second partition is the large (893 GB) partition where root and home will go;
(e) it has a small (2 MB) unallocated empty space at its end.

Is this the way I can have the SSD drive set up ahead of running an installer on it, to create a UEFI/GPT SSD drive? Will the installer put the boot files on what I have set up as the fat32 ESP drive?

Or should I delete all this and be creating the partitions as part of the install process? I've already tried this install once with a previous 4-GB live boot USB key, instructing in the process NOT to wipe the drive, but UEFI did not appear in the partition-setup pop-up "use as" menu.

(I think that previous key was set up to be a BIOS boot, and thus didn't work for UEFI.)

- You need only 1 MiB unallocated drive space at the head end of the drive, unless you want something else to get the best possible alignment of partition boundaries. There may be special preferences for the SSD hardware.

- 1 GiB for the ESP is a waste of drive space. I think 256 MiB is enough.

- You need no bios_grub partition. But if you want to boot in BIOS mode, you need such a partition when using GPT. In that case 1 MiB is enough (unless you want something else to get the best possible alignment of partition boundaries).

See more details about partitioning at this link: help.ubuntu.com/community/DiskSpace.

---

Edit:

There is a simple way to create a USB boot drive, that can boot both in UEFI mode and BIOS mode.

- Use the Ubuntu Startup Disk Creator, which clones the content from the Ubuntu MATE iso file to the USB drive.

The boot mode (UEFI or BIOS) is selected by the computer's built-in UEFI/BIOS system, and you set the preferred boot mode in a menu of that system. In most computers it is also possible to use a hotkey to get a temporary boot menu. (I think you know how to manage this in your computer. If not, please ask and we will try to help.)

The following command line can be used to check if Ubuntu MATE (any live or installed Linux system) is running in UEFI mode or BIOS mode:

test -d /sys/firmware/efi && echo efi || echo bios

[watchpocket]

Thanks for the responses. I'll report back once I've performed a UEFI install (or install attempt).

[watchpocket]

Its Ubuntu's Ubiquity that will not let you choose where to install grub2's UEFI boot files.
You can do a work around, or reinstall grub after your install. Default will install /EFI/ubuntu into first drive seen. If you disconnect all other drives, either logically in UEFI or physically then it will install to your external drive.
Posted work around to manually unmount & mount correct ESP during install #23 & #26.

The way I'm doing that work-around is by physically unplugging my non-target (internal) drives.

But there are other mysteries preventing me from doing a UEFI-GPT install.

Again, I am not dual-booting. I'm installing Ubuntu-MATE directly from a flash drive installer to an external SSD. Nothing else in the chain.

The target external 960-GB SSD I want to install to is, at the moment, empty. But I believe I have it correctly formatted:

Its partition table is GPT.
I've put 8 MB of empty space at the beginning, and at the end, of the SSD.
The first partition (sdc1) is the fat32 ESP, sized at 550 MB. (This is the size recommended by rEFInd creator Rod Smith.)
The 2nd, large, partition (sdc2) is ext4, sized at 893 GB.
/ (root) and /home will go on this 2nd large partition.

I have the Ubiquity installer for Ubuntu-MATE 20.04.1 on a USB flash drive (made with Startup Disk Creator) working as it should. (Except, of course, for Ubiquity's UEFI bug).

I've only just learned that the installer USB drive must itself boot in EFI mode, not BIOS mode. Since my only working system is a BIOS 18.04, I am able to boot the Installer in EFI mode only because I installed the rEFInd boot manager on a separate USB flash drive.

So I boot from that rEFInd flash drive. When rEFInd boots, it is guaranteed to be booting in EFI mode.

Once booted in EFI mode via the USB rEFInd flash drive, I plug in the USB Ubiquity installer, so that it's booted in EFI mode. Remember that my internal non-target drives are unplugged, and the install target is the external SSD described above.

It's here that I get lost, because Ubiquity has no selection for UEFI. It wants to format partitions as BIOS. Also, I already have my partitions formatted, but Ubiquity wants to format them, and is clunky about letting me leave the formatting of them alone.

(Maybe I should go ahead and format them with the installer the exact same way I've already formatted them. But that shouldn't be necessary, should it?)

Is it possible to unzip the .iso of 20.04 and just copy over all the files and folders onto my sdc2 ext4 partition? Instead of moving the .iso into the installer and creating/using the installer in the standard way?

If so, I would need to know exactly which files and folders to put in the ESP. I would guess the boot, EFI,and install folders would go in the ESP, but this is just a guess, I don't really know. What about casper, which contains an intird archive and the vmlinuz executable?

If this idea of copying is just wrong and hare-brained and won't work, how exactly should one proceed in the installer? Do everything the BIOS way and then fix things afterward? I wouldn't know which startup and-or GRUB files or folders to put into the ESP.

I do know that the ESP needs to be mounted as /boot/efi and sdc2 needs to be mounted as / (root) but I'm not sure where I define that from. I'm not sure the installer allows to mount /boot/efi.

In the install process, in defining the ESP, when I get to the pop-up menu that says "Use this partition as", I just don't know how to proceed. Maybe selecting "Use as BIOS partition" (or whatever is the exact wording there) is the only way to go, with the idea that I'll have to go in afterward and muck around to somehow whip it into shape as a functioning EUFI system.

reinstall grub after your install

For me, easier said than done. In order to do that, I would need to know more specifics about it than I know now. Like which files exactly.

What approach is best to take here?

[oldfred]

How you boot install media, is then how it installs.
You should not need to use rEFInd to boot live installer. You just choose the UEFI:flash drive entry in your UEFI boot menu, often f12, but varies by vendor.

Shows live installer with screen shots. Both BIOS purple accessibility screen & UEFI black grub menu screen
https://help.ubuntu.com/community/UEFI

The rEFInd boot manager only boots in UEFI mode, but is one of the few that some how can use UEFI's reboot feature to reboot into a BIOS boot. So using rEFInd may not guarantee UEFI boot.

The Ubuntu live installer ISO is by default configured to boot in either UEFI or BIOS boot mode, but depends on the install tool used. Some only create a BIOS installer or an UEFI installer.

It used to be you could just extract the ISO to a FAT32 partition and that would boot in UEFI mode only. But they added a couple of linked files which are not allowed in FAT32, breaking that method.
https://bugs.launchpad.net/ubuntu/+s...a/+bug/1849534

I would also suggest a smaller / (root) of 30GB or so and rest as /home or data partition(s). My current install is using about 9GB including /home, no snaps, and all data normally in /home in a data partition.

More details on UEFI install in link in my signature.

Updates for ISO to USB.
https://help.ubuntu.com/community/Installation/iso2usb

[sudodus]

You are making things complicated. Try this way:

0. Unplug the internal drive(s).

1. In the computer's UEFI/BIOS system, set it to boot in UEFI mode. If this is not possible, then you have to accept booting in BIOS mode (alias CSM alias legacy boot).

Please notice that Ubuntu works well (without any limitations) both in UEFI mode and BIOS mode, so there is nothing wrong with booting in BIOS mode in a computer, that you cannot boot in UEFI mode. And Ubuntu can boot in both UEFI mode and BIOS mode with a GPT as well as with an MSDOS partition table.

2. Boot into a live Ubuntu session from the USB boot drive. You can check the boot mode with

test -d /sys/firmware/efi && echo efi || echo bios

3. Start the installer and let it use the whole drive (the external SSD) where you want to install Ubuntu. Then it will automatically create necessary (and suitable) partitions for you. When you select this option it will overwrite whatever is on the drive, and it will warn you about that: 'Erase disk and install Ubuntu'. See the attached screenshot.

Please notice that frequent backup is more important if you encrypt the drive because it is very difficult to recover or repair a disk with a damaged file system. And there is no back door, so you must remember that passphrase. In other words, encrypt only if you need it, and then set up a good backup routine.

[watchpocket]

I've had partial limited success with my install.

It's true I don't need to first boot rEFInd to boot the installer in EFI mode. My installer
wasn't booting in EFI mode because in the F10 boot menu, I had been selecting "Generic Flash
Drive" instead of "EFI Shell." Selecting the latter booted the installer in EFI mode by itself,
without having to boot to rEFInd first.

The other reason I had trouble earlier was that in Ubiquity, I had chosen to not format partitions (I
figured that because I'd already formatted them, I didn't need to now). That made it so
that, in the formatting pop-up menu, there was no entry to select to use the ESP as the ESP.
So I chose 'format' and was able to select the entry for the ESP partition.

So, I was finally able to run the installer in EFI mode and the installation got 95% of the way
through, when the installer crashed. The crash was due to a bug described here.

Reading through all the responses, the fix for the crash was to run the installer as a "normal" installation
with the third-party-install and driver-update checkboxes unchecked. So I did that and the
installation went all the way through and finished properly.

However, the drive doesn't boot.

I'm hoping some of the below may provide clues. (The /sys dir below is empty.)
(I plan later to make a smaller /home partition.)

[rj@rjbox:~]  [v5.4.2]  zsh  2012  --> lf /media/rj
total 12
4 drwxrwx---+  3 root root 4096 Sep 30 19:19 ./
4 drwxr-xr-x   3 root root 4096 Apr  5 21:05 ../
4 drwxr-xr-x  20 root root 4096 Sep 30 18:13 8961ed2b-21e9-4ba0-a497-34256815e869/
[rj@rjbox:~]  [v5.4.2]  zsh  2012  -->
[rj@rjbox:~]  [v5.4.2]  zsh  2013  --> lf /media/rj/8961ed2b-21e9-4ba0-a497-34256815e869
total 2097256
      4 drwxr-xr-x   20 root root       4096 Sep 30 18:13 ./
      4 drwxrwx---+   3 root root       4096 Sep 30 19:19 ../
      0 lrwxrwxrwx    1 root root          7 Sep 30 18:09 bin -> usr/bin/
      4 drwxr-xr-x    4 root root       4096 Sep 30 18:20 boot/
      4 drwxr-xr-x    2 root root       4096 Sep 30 18:13 cdrom/
      4 drwxr-xr-x    5 root root       4096 Jul 31 12:33 dev/
     12 drwxr-xr-x  140 root root      12288 Sep 30 18:19 etc/
      4 drwxr-xr-x    3 root root       4096 Sep 30 18:13 home/
      0 lrwxrwxrwx    1 root root          7 Sep 30 18:09 lib -> usr/lib/
      0 lrwxrwxrwx    1 root root          9 Sep 30 18:09 lib32 -> usr/lib32/
      0 lrwxrwxrwx    1 root root          9 Sep 30 18:09 lib64 -> usr/lib64/
      0 lrwxrwxrwx    1 root root         10 Sep 30 18:09 libx32 -> usr/libx32/
     16 drwx------    2 root root      16384 Sep 30 18:07 lost+found/
      4 drwxr-xr-x    2 root root       4096 Jul 31 12:28 media/
      4 drwxr-xr-x    2 root root       4096 Jul 31 12:28 mnt/
      4 drwxr-xr-x    2 root root       4096 Jul 31 12:28 opt/
      4 drwxr-xr-x    2 root root       4096 Apr 15 07:09 proc/
      4 drwx------    3 root root       4096 Sep 30 18:15 root/
      4 drwxr-xr-x   14 root root       4096 Sep 30 18:13 run/
      0 lrwxrwxrwx    1 root root          8 Sep 30 18:09 sbin -> usr/sbin/
      4 drwxr-xr-x    2 root root       4096 Jul 10 09:59 snap/
      4 drwxr-xr-x    2 root root       4096 Jul 31 12:28 srv/
2097156 -rw-------    1 root root 2147483648 Sep 30 18:08 swapfile
      4 drwxr-xr-x    2 root root       4096 Apr 15 07:09 sys/
      4 drwxrwxrwt    2 root root       4096 Sep 30 18:20 tmp/
      4 drwxr-xr-x   14 root root       4096 Jul 31 12:30 usr/
      4 drwxr-xr-x   14 root root       4096 Jul 31 12:37 var/
[rj@rjbox:~]  [v5.4.2]  zsh  2014  -->

[rj@rjbox:~]  [v5.4.2]  zsh  2025  --> lf /media/rj/8961ed2b-21e9-4ba0-a497-34256815e869/boot  
total 189780
    4 drwxr-xr-x  4 root root     4096 Sep 30 18:20 ./
    4 drwxr-xr-x 20 root root     4096 Sep 30 18:13 ../
 4628 -rw-------  1 root root  4738430 Jul  9 19:50 System.map-5.4.0-42-generic
 4632 -rw-------  1 root root  4743112 Sep 10 06:12 System.map-5.4.0-48-generic
  236 -rw-r--r--  1 root root   237773 Jul  9 19:50 config-5.4.0-42-generic
  236 -rw-r--r--  1 root root   237769 Sep 10 06:12 config-5.4.0-48-generic
    4 drwxr-xr-x  2 root root     4096 Sep 30 18:08 efi/
    4 drwxr-xr-x  4 root root     4096 Sep 30 18:20 grub/
    0 lrwxrwxrwx  1 root root       27 Sep 30 18:19 initrd.img -> initrd.img-5.4.0-48-generic
78332 -rw-r--r--  1 root root 80209089 Sep 30 18:18 initrd.img-5.4.0-42-generic
78352 -rw-r--r--  1 root root 80229765 Sep 30 18:20 initrd.img-5.4.0-48-generic
    0 lrwxrwxrwx  1 root root       27 Sep 30 18:09 initrd.img.old -> initrd.img-5.4.0-42-generic
  180 -rw-r--r--  1 root root   182704 Feb 13  2020 memtest86+.bin
  184 -rw-r--r--  1 root root   184380 Feb 13  2020 memtest86+.elf
  184 -rw-r--r--  1 root root   184884 Feb 13  2020 memtest86+_multiboot.bin
    0 lrwxrwxrwx  1 root root       24 Sep 30 18:19 vmlinuz -> vmlinuz-5.4.0-48-generic
11392 -rw-r--r--  1 root root 11662080 Jul 31 12:46 vmlinuz-5.4.0-42-generic
11408 -rw-------  1 root root 11678464 Sep 10 06:36 vmlinuz-5.4.0-48-generic
    0 lrwxrwxrwx  1 root root       24 Sep 30 18:19 vmlinuz.old -> vmlinuz-5.4.0-42-generic
[rj@rjbox:~]  [v5.4.2]  zsh  2026  -->

[rj@rjbox:~]  [v5.4.2]  zsh  2031  --> lf /media/rj/8961ed2b-21e9-4ba0-a497-34256815e869/boot/efi 
total 8
4 drwxr-xr-x 2 root root 4096 Sep 30 18:08 ./
4 drwxr-xr-x 4 root root 4096 Sep 30 18:20 ../
[rj@rjbox:~]  [v5.4.2]  zsh  2032  --> lf /media/rj/8961ed2b-21e9-4ba0-a497-34256815e869/boot/grub 
total 2384
   4 drwxr-xr-x 4 root root    4096 Sep 30 18:20 ./
   4 drwxr-xr-x 4 root root    4096 Sep 30 18:20 ../
   4 drwxr-xr-x 2 root root    4096 Sep 30 18:16 fonts/
   4 -rw-r--r-- 1 root root     712 Jul 31 12:33 gfxblacklist.txt
  12 -r--r--r-- 1 root root    9171 Sep 30 18:20 grub.cfg
   4 -rw-r--r-- 1 root root    1024 Sep 30 18:16 grubenv
2340 -rw-r--r-- 1 root root 2395475 Sep 30 18:16 unicode.pf2
  12 drwxr-xr-x 2 root root   12288 Sep 30 18:16 x86_64-efi/

  1 # /etc/fstab: static file system information.                                                                                                                                                          
  2 #
  3 # Use 'blkid' to print the universally unique identifier for a
  4 # device; this may be used with UUID= as a more robust way to name devices
  5 # that works even if disks are added and removed. See fstab(5).
  6 #
  7 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
  8 # / was on /dev/sdb2 during installation
  9 UUID=8961ed2b-21e9-4ba0-a497-34256815e869 /               ext4    errors=remount-ro 0       1
 10 # /boot/efi was on /dev/sdb1 during installation
 11 UUID=6DE5-0FF8  /boot/efi       vfat    umask=0077      0       1
 12 /swapfile                                 none            swap    sw              0       0

Here's the drive in GParted:

Screenshot at 2020-09-30 20-01-32.jpg

On a different target SSD, I used the erase-disk install method suggested by sudodus (but I didn't encrypt and I didn't use LVM). I unchecked the driver-update box but did check for software updates (I checked both in the install for the SSD discussed above). The installer ran ok, but again, I can't boot to this drive either. Both drives were installed to while internal non-target drives were unplugged.

[oldfred]

External drives only boot from /EFI/Boot/bootx64.efi.
That may show as UEFI:your drive or the same as you used to boot live installer, EFI Shell.

What brand/model system?
Do not normally see shell as boot option, but some systems have it.
Most just have two entries for live installer if configured for both BIOS & UEFI or only one UEFI:flash if just a flash drive with UEFI only. "flash" is name or label of flash drive you have installer on.

[watchpocket]

External drives only boot from /EFI/Boot/bootx64.efi.

In light of this knowledge I've just created /EFI/Boot/ folders in my external drive. (permissions -r--r--r-- on both). Then I copied into that /EFI/Boot/ folder these 3 files from my live-installer flash drive's /EFI/BOOT/ folder:

bootx64.efi
grubx64.efi
mmx64.efi

I don't know if grubx64 and mmx64.efi actually belong there or not, but I copied them anyway since they were in the installer's /EFI/BOOT folder. After this, I still couldn't boot from the external drive I installed 20.04 on.

(I did a fresh install on that drive earlier today -- the thing I did differently than yesterday's installs was, I selected to have the boot files put in the ESP partition (sdb1) instead of just on sdb. ISTR that it's usually recommended NOT to put them on a specific partition, but thought I try that anyway.)

Next step is to bring Boot-Repair in. I still have a /sys folder that's empty, which is no doubt one part of my problem of not being able to boot. I just don't get why /EFI/Boot and its files -- and the /sys folder's dirs & files -- weren't created automatically as part of the UEFI install.

Also, shouldn't /EFI/Boot/bootx64.efi go in the ESP partition?

That may show as UEFI:your drive or the same as you used to boot live installer, EFI Shell.

Well, since I couldn't boot to it, nothing showed as a selection for the external drive.

When I unplug my internal working drives, and I press the F10 key as I boot with the USB live-installer flash drive plugged in, the menu I get shows the following:

"ubuntu" (which if I select does nothing but an infinite-loop restart);
"INTERNAL EFI SHELL: USB Device Hard Drive" (this is the full name of the "EFI Shell" I referred to above. If I select it, the installer boots in UEFI mode.)
"Generic Flash Drive" (if I select this, the installer boots in BIOS mode.)

What brand/model system?

Intel. I got the box from System 76, which pre-installs Ubuntu (though that was several versions ago):

Machine: Type: Desktop System: System76 product: Wild Dog Performance v: wilp6 serial: <filter>
Mobo: Intel model: DP45SG v: AAE27733-405 serial: <filter> BIOS: Intel v: SGP4510H.86A.0108.2009.0114.2036
date: 01/14/2009

Despite the 2009 date, this box's BIOS menu does have a setting (which is activated) to boot UEFI instead of BIOS.

Most just have two entries for live installer if configured for both BIOS & UEFI

That's basically what I have, as mentioned above. Now to apply Boot-Repair to my external 20.04.

[oldfred]

Have you checked that you have latest UEFI available for that system?

Not sure you can just copy the boot files from a live installer to boot a full install. Grub/shim are smaller versions just to boot live installer. After install the full versions with added support are installed. And a /EFI/ubuntu/grub.cfg which is only 3 lines is created to configfile into full grub.cfg in your actual install.

Lets see details, use ppa version with your live installer (2nd option) or any working install, not Boot-Repair ISO:
Please copy & paste the pastebin link to the Boot-info summary report ( do not post report), do not run the auto fix till reviewed.
https://help.ubuntu.com/community/Boot-Repair &
https://sourceforge.net/p/boot-repair/home/Home/

You may need advanced mode to choose install & then choose drive to install into.
If UEFI system, be sure to boot live installer in UEFI mode, so repairs or reinstall of grub is in UEFI mode.

[watchpocket]

Hold on, I'll do this from the installer.