Q for Linux gurus: recreating EFI boot partition

In a stunning display of stupidity, I managed to delete my boot partition. I wanted to reformat an old Kubuntu 22.04 live USB stick. When I ran the partition manager to remove the old partitions, I didn’t pay attention to what drive was selected… and here we are. This happened on Monday night, and I haven’t had to reboot my computer yet, but I can’t keep this up forever.

I run Kubuntu 24.04 LTS. It is the only OS on my system. My primary hard drive is 500 GB, which contains the OS and the aforementioned boot partition. My secondary drive is 6 TB and contains my home partition.

I want to recreate the partition without having to reinstall the whole OS. Having to do so wouldn’t be as devastating as it would if I was running Windows, but it would still be a pain in the ass that I’d rather avoid.

I’ve been reading this article:

https://www.baeldung.com/linux/efi-boot-partition-restore

Since I’m only running a single OS, I like the last option, #6: skip GRUB altogether. I’ve got bootable USB sticks for both Kubuntu 24.04 LTS and rEFInd, so I should be good if anything (else) ever goes wrong.

I’ve recreated the partition, flagged it as boot, and set the mount point to /boot/efi. If I’m understanding the article correctly, I need to create an entry in efibootmgr, and… that’s it? The article says nothing about mounting the boot partition and copying/installing anything there. The article seems to be saying if there’s no bootloader in /boot/efi, the system will boot via the firmware? So I’m supposed to just leave the partition empty? Do I have this correct? That just seems wrong.

I really want to be confident that when I reboot the machine, things will go smoothly!

I only skimmed through that article. One thing I see missing is setting your partition type to “EFI System”, which should be the very first type option in fdisk.

Here is what I would do. I think you’ve already done some of them.

  1. Use your favorite partition manager, such as fdisk or gparted to recreate the EFI partition.
    1. It should be 1GB or so in size
    2. It should be set with the type “EFI System”
    3. It should be formatted FAT32/vfat
  2. Mount the partition at /boot/efi
  3. Run grub-install /dev/sda (or /dev/nvme0n1 or whatever)—that should copy the appropriate files into /boot/efi and add an entry to the EFI boot variable list
  4. Just for good measure, run update-grub.
  5. Run efibootmgr all by itself
    1. That should show the existing boot list
    2. Look at the BootOrder: line
      1. The entry will be something like 0007,000A
      2. 0007 corresponds to the entry in Boot0007
    3. Check the appropriate boot entry to make sure it points at what you want
      1. It should be something like Boot0007 Ubuntu HD(1,GPT,[…]./\EFI\ubuntu\grubx64.efi
      2. The “[…]” will be a unique ID that you can get by running blkid -p -o value -s PART_ENTRY_UUID /dev/sda1 (or whatever your EFI partition is numbered
  6. Reboot and hope it works?

I’m not quite sure I understand what you mean when you say you want to avoid grub altogether. Do you mean you want a different boot loader than grub? I recommend getting the system booting with grub, and then switch to a different boot loader, but that’s only because I know much more about grub.

Or, do you mean that you want to setup a rescue USB stick to get your system booted in the event you’re install doesn’t go correctly? Yes, that should not be difficult to do. Again, I know more about setting up a rescue with grub than rEFInd.

If you have to boot from a rescue USB drive, that shouldn’t be too terrible. Run cat /proc/cmdline and take a picture of it, or note it down. That will tell you exactly what options you need to boot your system the way it is now. Also take a look at /boot/grub/grub.cfg and look for the first entry that starts menuentry, and pay attention to the linux and initrd entries under there. You might have to type those into grub by hand on the rescue disk.

This is for grub:

  1. Boot the rescue disk
  2. At the grub menu press a key (I forget which) to get a command line
  3. Type linux (hd1,gpt2)/boot/vmlinuz then all that stuff you noted earlier
    1. It might not be (hd1,gpt2), but you can use TAB completion to get grub to list the available options, and should be able to sort out the exact path
  4. Type initrd (hd1,gpt2)/boot/initrd.img
  5. Press F10 to make grub boot
  6. Don’t get upset when it fails, go back and try again.

Linux is not Windows, the situation you’re in is completely recoverable without touching your root partition, the only trick is finding the way to fix things that works best for you.

Yes, I’ve already set up the partition as you say. I should have been more detailed about that in my OP.

Are you saying I can install GRUB directly from my already-running system? The article makes it sound like it has to be done from a live USB environment. But now that I think about it, perhaps the author is assuming that the reader already can’t boot up their computer?

As for avoiding a bootloader, the author of that article claims that a bootloader isn’t strictly necessary on modern systems; they are mainly used these days for convenience, especially for those who run multiple operating systems. So I was saying I already have other ways in (Kubuntu bootable USB stick) in case the system ever crashes and burns, so I could skip installing GRUB.

Yes, that will be the easiest. Installing from a rescue disk is possible, and can be necessary in many circumstances, but it is much easier to install from the primary system.

I think the Linux kernel can be booted directly from EFI, but why would you want to do that? Using grub or rEFIind makes it so much easier if you need to do anything other than just boot in the standard way: use an old kernel, test some new options for the command line, need single user mode. Even on something resource constrained, the few MB and seconds of boot time added by grub seem worth the added convenience.

One of the big conveniences of grub is that it handles setting up the EFI stuff, which is a huge pain otherwise. Lots of cryptic and poorly documented commands to efibootmgr, and if you mess it up, you’re right back to needing to boot from a rescue disk.

Also, if you want to boot directly from EFI, then you’ll need a special kernel image, and I don’t know if that is provided by Ubuntu. If not, you’ll have to build the kernel yourself.

None of that stuff is terribly difficult once you’ve done it a few times, but unless you are just interested in the challenge (which I totally get), just use a bootloader where someone else has done all that hard work.

Got it. I will reinstall GRUB.

One last question, to make sure I’m understanding correctly. Earlier you said:

My primary drive is nvme0n1. The EFI partition I created is nvme0n1p1, and the OS is on nvme0n1p2. I should not include the p1 when I run the grub-install command?

I finally bit the bullet and did it. Everything went off without a hitch. Thanks so much for your help!

Glad it all worked out.

Just for the record, yes, generally leave off the partition number. The grub installer will figure out which partition to copy file to, and where to put them. If it can’t figure it out, you might have to give it some hints, or perhaps things are not setup in a way that will ever work, and you need to sort it out.

This is what makes installing from the actual host system, rather than a rescue disk, so much easier. On the real host system your actual root is mounted, and /boot and /boot/efi should be in place, with the proper kernel and initial ram disk all lined up. The install script should be able to figure it out. When using a rescue disk, none of that is true. You can use often use chroot to mostly make things look right, but not always, and it may require much more manual tweaking.