Update installer to include UEFI

I purchased a new Seagate hard drive to replace a failing one. When I ran the installer and chose “Something else” I found that Seagate had not programmed it (what they call a “Logical Fault”). I created the missing GUID Partition Table and created the UEFI System Partition and a ext4 Linux partition and ran the install. Then I tried to boot using the new drive. Complete failure. All the UEFI data used by my firmware is missing.

UEFI sits between the firmware and the OS. The Windows people said “not my job”. No support from them.

The installer knows the processor I am using and the fact that the drive I’m installing is larger than 2 TB. It has all the data it needs to check or create the GPT, the EPT and populate it as well as the Linux partition and OS. Some tool is needed to fill the gap between the firmware and the OS loader.

The installer includes uefi.

If the installer includes UEFI, why did it not install the necessary data
to actually USE uefi? Where can I get the data so that my firmware can use
UEFI?

UEFI is the firmware.

If you do one of the more automatic options, like “Erase disk and install” or “Install alongside”, it should all be set up automatically.

Alexander Browne

No it isn’t! Read the standard 2.7 or the book “Beyond BIOS”.

And no it does not.

Possibly this could help you with your UEFI problem -

Good luck @rpearsonii

mdooley,

Thank you for responding, but I already did all that. The indicated
procedure assumes the internal hard disk has a working UEFI System
Partition with the UEFI code and data needed by the firmware to boot in
UEFI mode. The drive I received from Seagate had a “Logical Failure”. They
apparently skipped the manufacturing step that created the GUID Partition
Table and created the UEFI System Partition and its contents. Those
contents are what I am trying to find. The motherboard people say “not my
job”. The Windows people say “not my job”. (The “live” Windows 10 “stick”
will refuse to install Windows on any drive larger than 2 TB or with a GUID
Partition Table. I have even asked the UEFI Consortium where I can get the
code and data to make my drive bootable. No luck. UEFI is just an interface
so no one takes responsibility for it. The ESP data and code is also needed
to make external hard drives bootable. The Ubuntu MATE 18.04 install uses
the UEFI code if it is there but does not install it.

The Linux installer also has a bug. If you boot in UEFI mode it installs in
UEFI mode. The correct action is if you boot in legacy BIOS mode and the
drive is 2 TB or smaller, install in legacy BIOS mode, else install the
necessary UEFI code and data and install Linux in UEFI mode.

Robert Pearson

The computer either boots in bios mode or uefi mode. So if the installer has booted in uefi then you want the installed system to boot in uefi. It’s no good booting the installer in bios mode and installing in uefi mode (which by the sounds of it is what you are trying to do?).

You need to go into BIOS to change boot method from BIOS to UEFI. In summary:

  • BIOS boot is usable for booting from a disk that’s < 2TB.
  • UEFI boot is needed to boot from a disk that’s > 2TB.
  • MBR is fine for partitions < 2TB.
  • GPT is required for partitions > 2TB.
  • You do not need UEFI to have a non-bootable drive > 2TB - only GPT

Have you contacted the hard drive vendor and requested a return due to manufacturer defects? The installation of the Seagate firmware may be beyond user intervention/correction.

Dear Michael Dooley,

The replacement Seagate drive was yet another blank drive with no GUID
Partition Table and no UEFI System Table. I booted the
Ubuntu 18.04 DVD in UEFI mode and I created the GPT and ESP and Installed
Ubuntu 18.04 from the DVD. However, before trying to
boot from the new hard drive, I mounted the hard drive’s ESP. I then copied
the BOOT and UEFI directories from the DVD to the hard
drive’s ESP. I figured (with no help from Seagate or the firmware
manufacturer) that if the DVD can boot in the UEFI mode then the
necessary files must be on the DVD. After copying the files I booted hard
drive with UEFI boot. It worked! The reason it failed the
first time is that apparently the installer does not bother to check the
ESP of the selected drive to see if the necessary files exist.

I then tried to make an external USB hard drive bootable. I took the advice
from one responder and unplugged my internal drives
so that the only drives connected are the external USB drive and the
internal DVD drive. I booted the DVD in UEFI mode. I did everything
to the external USB drive that I did to the internal drive. But when I
tried to boot from the external drive I got the firmware message
that I need to insert the installation media (the DVD). The external drive
was not bootable.

I the tried Windows 10. I inserted the Windows installation DVD and booted
in UEFI mode. The installer gave me the message that
Microsoft will not install Windows 10 on any USB device.

I would like to have at least one bootable Ubuntu external USB drive in
case on major system failure. Other respondents have said
that it is possible and that they have done it. I just don’t know how.

Robert Pearson

This shouldn’t be necessary, and I’m pretty sure wouldn’t work anyway.

Can you explain your full setup? You’ve implied you have more than one hard drive which presumably already has an ESP partition?

stillwinter,

I have one internal hard drive to replace the old one. I have multiple external USB drives (all larger than 2 TB) but currently have only one connected. I was trying to install Ubuntu 18.04 AMD 64-bit on the external USB drive so that I could use it the next time the internal drive is corrupted. I could use the Ubuntu DVD or a “live” USB “stick”, but they loose everything when I reboot. I trashed 4 USB “sticks” trying to create a "live’ persistent “stick” but never got one to actually work. Other users say that they have been able to boot Linux from an external drive, but they did not say if the external drive was larger than 2 TB (thereby requiring UEFI booting).

It is not a critical issue (at least compared to trying to recover 15 TB of data on external drives with HFS+ filesystems). I just would like it for an emergency.
Robert Pearson

For information purposes only -

and -

Not pointing to a definite solution, but perhaps filling a hole.

I’m not sure what you mean by trashed. If you mean they were broken and unusable then this shouldn’t happen. There used to be/probably still are a lot of counterfeit usb sticks that report a higher size than they actually are. This could be one reason.

If you mean that you’ve used dd or some tool to create the live usb device and windows is now showing a reduced size (the size of the iso file), then use gparted to create a new partition table. After running that and creating a new partition the full usb stick should be useable again.

It is not necessary to use dd or any special tool. To make a live usb stick all you have to do is format the stick as fat32 (I did this with an MBR partition table on my machine). Then mount the iso file (double click the file in any recent version of windows) and copy everything onto the stick. You must have the folder “.disk” which can be hidden if you are doing this from Linux (change view options in you file manager if this is the case).

Reboot into your (EFI) boot manager. On my acer machine I press F12 just after power on. Select the USB device. You should see the grub menu and bootup is as normal.

To make a persistent live usb stick you need a casper-rw partition/file. Boot the live usb stick. Make it writeable

sudo mount -o remount,rw /cdrom 

Create a 2G casper-rw file

sudo fallocate -l 2G /cdrom/casper-rw
sudo mkfs.ext4 /cdrom/casper-rw

Edit the grub.cfg adding the word “persistent” to the kernel command line

sudo nano /cdrom/boot/grub/grub.cfg

e.g. linux /casper/vmlinuz.efi file=/cdrom/preseed/xubuntu.seed boot=casper quiet splash persistent —

Reboot and you should now have working persistence. Test by creating a file on the desktop and reboot again. It should be still there.

If you only have one drive then I would recommend using the automatic partitioning options of the installer. Something like “erase disk and install ubuntu”, but I can’t remember the exact wording.

This should install the bootloader correctly. If it doesn’t it will report an error message and installation will not be complete.

If you subsequently mess things up then you can repair grub2 using the instructions in this post Repair Grub 2 from a live DVD . If you are using a removable drive then you can use

sudo grub-install --removable

Forgot that for removable drive installs there is a preseedable value. Add to the installers kernel command line:

grub-installer/force-efi-extra-removable=true

stillwinter,

I did not intend to state that I had a second hard drive with a populated
ESP. What I did have was one hard drive (4TB) and the installation DVD. The
first time I did the installation I
created the GUID Partition Table and the (empty) ESP. After the
installation I tried booting. All I got was a message to insert the
installation media. The ESP was empty and the
system could not boot from that drive without it. I tried getting the
information from the disk manufacturer - no help. I tried getting the
information from the firmware people - no help. I
tried getting the information from Ubuntu - no help.

Then I realized that if I could boot the installation DVD in UEFI mode,
then the DVD had to have the information for the ESP. The installer just
was not checking to see if the installation
was valid. When I copied the files from the DVD ESP to the hard drive ESP,
then Ubuntu would boot from the hard drive.

I expected after the first installation completed without errors that the
system would boot from my hard drive.

After I copied the files from the DVD to the ESP on the hard drive, it did.

This is a very subtle bug invisible from the (2TB or smaller drive using
MBR and BIOS booting) perspective. I want to help Ubuntu move to the 2005

2TB GPT UEFI perspective.
Robert

The installer has a weakness with removable drives. See https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1173457 . This can be easily worked around (most of which I’ve already written), but you don’t seem to be particularly interested in getting help.