0

After cleaning up old unnecessary disk partitions, my UEFI/hardware will not find my single and only remaining Ubuntu installation, a perfectly working newly upgraded Ubuntu 20.04 on a disk partition /dev/sda5 on disk /dev/sda; my system will not boot that installed Ubuntu system but only enter that pre-boot BIOS/UEFI settings user interface where it does not seem to recognize any boot option at all.

As I understand it, the more modern way of booting over a UEFI enabled motherboard is to allocate a partition where grub2 will sit alongside proper configuration directing grub2 at my /dev/sda5 installed Ubuntu system. Which is arguably now missing after my cleanup of old partitions.

Space for a new partition for grub2 is not an issue: I have a ~200MB empty and contiguous unallocated disk space in my disk's partition table for that disk. I can also shrink my Ubuntu partition to get more space for a new partition if more is needed.

I have found various conflicting posts and posts answering to a very specific scenario, or to a Microsoft Windows compatibility scenario, on various stackoverflow websites (askubuntu and others) but would like to have a clean, up-to-date, UEFI oriented procedure ― for making a system boot into an existing Ubuntu system via UEFI by recreating a grub2 partition for UEFI from scratch.

In Summary

Looking for a clean scratch approach ― one based purely on a live USB Ubuntu disk and on commands/tools available on the later releases of the Ubuntu distribution, which will accomplish a UEFI compliant partition that will direct the UEFI hardware to successfully load the pre-installed Ubuntu OS partition upon boot!

What should be the cleanest series of steps, from creating a new partition for grub2 for the UEFI hardware to use, to configuring it to point to my /dev/sda5 fully operational Ubuntu?

Disk Information

as much as it matters, according to gparted the disk's partition table type is gpt.

Further Clarification Edit:

I have had no functioning UEFI partition on the same disk at the time of asking. My question assumes that one removes it and builds it from scratch: that you only have an Ubuntu OS partition on the disk and your goal is to "connect it" such that UEFI hardware will become able to boot it.

matanox
  • 2,293
  • To make things simpler: please assume no Windows dual-boot capabilities shall be required – matanox Jun 18 '20 at 15:11
  • 3
    Not clear from the above if you already have an EFI partition (FAT, boot flag, EFI type,) from which you simply removed the bootloaders (grub,...). Are you concerned about using secure-boot? Did you install your sda5 root in UEFI mode? Simplest way is just to use grub-install , or just find in your sda5 root the file grubx64.efi and copy it to the EFI /EFI/Boot/bootx64.efi and copy the /boot/grub/grub.cfg to /EFI/ubuntu/grub.cfg (better to make a 3 line grub.cfg stub which copies in the actual one each time). – ubfan1 Jun 18 '20 at 16:33
  • 4
    Default install of Ubuntu is / (root). With UEFI you have to have an ESP - efi system partition. If in housecleaning you removed that you removed the UEFI boot files. Each UEFI install has its initial boot files in the ESP & rest in the install. And UEFI has boot entries for those installs in its NVRAM. You can just reinstall grub from live installer, but newer users find Boot-Repair a bit easier but must boot live installer in UEFI mode, as it mounts necessary partition(s) and runs correct install command. https://help.ubuntu.com/community/Boot-Repair – oldfred Jun 18 '20 at 16:41
  • This comment mirrors the flow I've taken in my answer below to myself, yet it could be extra helpful to shed more light on what a UEFI install is. I mean, is that something taking place as part of initial Grub/Ubuntu installation, somehow triggering installation to the hardware NVRAM? or is part of some other process? – matanox Jun 18 '20 at 17:21
  • @ubfan1 what do you mean by installing the root in UEFI mode? do you mean whether the Ubuntu OS has been installed in UEFI mode? is that an installation option? – matanox Jun 18 '20 at 17:30
  • @oldfred I gather from Wikipedia on this that an "Extensible Firmware Interface system partition" is a partition that the UEFI hardware looks for on the disk, I'll assume this is what you call ESP-EFI in your last comment. I'd like to hope that one's typical modern UEFI hardware would just find it on the disk's partition table, rather than any process necessary for hard-wiring anything about the EFI System Partition of the disk into the hardware UEFI setup/NVRAM. – matanox Jun 18 '20 at 17:44
  • 5
  • I thought this was a sincere question and was confused by all comments. Then I realized OP wants to post own answer which arguably should have been posted on the duplicate candidate. – WinEunuuchs2Unix Jun 18 '20 at 19:44
  • 1
    OP didn't want to post own answer for the sake of posting own answer in any insincere way as you imply, OP thought they have the answer and should share it, and has now removed it after realizing it was wrong. – matanox Jun 18 '20 at 19:59
  • 1
    not really @Nmath, it's a different scenario ― no Microsoft Windows compatibility concerns, gpt disk partition, a preference for UEFI and a way to make the EFI System Partition from scratch rather than repairing one. If you think we need long answers with branching points and no linear answers for specific scenarios I would urge promoting that policy! – matanox Jun 18 '20 at 20:01

0 Answers0