Is it possible to install EFI(ESP) partition after Ubuntu & Parrot have been installed?

Question

There is a computer which has got installed with Ubuntu and Parrot Security OS. This is all fine and it is running smoothly with Grub. It can boot correctly.

When we installed Ubuntu we formatted all the HDD and forgot to install the EFI. When we tried to install rEFInd it showed that EFI is missing completely from the computer.

The question is that: how can we install EFI after when we installed all the Operation systems. Should I reinstall Ubuntu again to get it on it ?

Answer 1

It is certainly possible, but the real question is whether it's less hassle.

ESP is just small partition (512Mb is good size) with fat filesystem and special type.

• Since you need to create it, you need to have some free space for it and for that you may need to resize one of your partitions and the filesystem on it with tool like gparted.

• If you already have the nescessary space, then you need to create new partition with the appropriate type. In gparted you are looking for "esp flag", which would be "EFI System" type in fdisk (or something similar, if you are running on MBR). This is what makes EFI partition an EFI partition.

• Build the filesystem with mkfs.fat -F32 /dev/sdx

• Get uuid of the partition with blkid, set it's label or similar

• Create new entry in /etc/fstab for the new partition like so (and make sure the mountpoint exists):

UUID=xxxx-xxxx   /boot/efi    vfat    defaults    0 2

Alternatively you can use /efi or perhaps bind mount to /boot to avoid /efi/EFI path

• Install rEFInd, or GRUB for EFI to that partition. You might need to create /EFI directory on that partition

This should give you a working ESP.
You can read more and better at: https://wiki.archlinux.org/index.php/EFI_system_partition#Create_the_partition

Answer 2

I did something similar to this once. I didn't write down the exact steps, but it wasn't too hard to remedy. (I also happened to need rEFInd but this should also work without it.) It went something like this:

1. "Properly" install the same version of Ubuntu on a temp GPT-formatted disk or VM setup up as an UEFI system with a GPT virtual disk, as a "donor" dummy OS.
2. If your main OS has been updated after install, then also update the dummy install.
3. Shut down the dummy OS.
4. Using some bootable recovery media or other bootable OS, copy the EFI partition from the dummy to your real machine.
   1. An Ubuntu boot DVD can be used for this, as it comes with GParted.
   2. If doing this via VM, boot the VM to a recovery ISO, or the Ubuntu install ISO file mounted as a virtual disc. Note that you can also mount your real OS disk within the VM, as a raw VMDK (if using VirtualBox, you'll need to use vboxmanage CLI to create it, and not that the mapping is not valid across host OS reboots). This will allow you to directly copy your "dummy" EFI partition directly to your real disk, which is a real time-saver if doing this in a VM. (You can even boot your real OS in the VM this way. Linux is smart enough to not load drivers for hardware that temporarily doesn't exist, even proprietary display drivers. The kernel already has - and will automatically load - basic open-source drivers for VirtualBox and VMware integration. In fact I usually install Ubuntu onto real disks this way, for later transplant into other machines, all via VM.)
5. Before copying the EFI partition, make room for it as the first partition, by first shrinking and/or moving the existing partition out of the way. (Which is easy via GParted.) The new EFI partition won't be sda1 (as it would be with a correct install the first time), but if I remember correctly, EFI, Grub, rEFInd, etc. are OK with that.
6. Map the partition to /boot/efi, in the installation's /etc/fstab file.
7. Now you have two choices for getting a bootable system (again you can do this on bare metal or via VM with raw VMDK-mapped real disk):
   1. Use a boot repair tool such as Boot Repair to get everything to a bootable state, usually just by pressing one button.
      • Note that you must run Boot Repair from an OS in UEFI mode, whether bare metal or VM.
   2. rEFInd should also be able to work with this configuration. But if not, and you really need rEFInd, you may need to run the previous step first.
8. If you want to skip Grub and go "pure EFI", there are ways around that too, but beyond the scope of this answer (and my memory).

I'm curious as to why you want to use rEFInd? It's an amazing bit of code, and is practically required to navigate dual or triple-booting with MacOS, but if it's just dual booting with Linux/Windows, I've often found that Grub is easier, though uglier. There's less to mess with. Also, rEFInd is not "set and forget", it occasionally gets overwritten and needs reinstall, which can be a minor pain because typical *nix/Windows sysadmin skills don't map to rEFInd, and it happens infrequently enough so that you find yourself re-googling how to do it every time. (Or write it down and then try to remember where that note is.) Also, it sometimes "helpfully" creates icons to specific kernel versions, which tend to quickly become irrelevant. I believe there's a documented way to prevent that behavior or at least delete them after-the-fact, but I quit using it so I don't remember. This is just my experience though.

Good luck!