Fix an overwritten efi

Hello there.
I just got done setting up my dualboot for my work setup. It worked! Unfortunately, I attempted to reuse the same efi partition while doing this. Turns out, all that accomplished was breaking it before erroring out. Right now, if I launch that partition I’m given a blank grub shell. I have no idea how to fix this. Any advice would be much appreciated.

Launch your live usb and post the output of the following commands:

sudo parted -l

efibootmgr

And just to double-check: EnOS’ uses systemd-boot as default but you chose Grub in the installer?

Here’s the result, excluding an unrelated drive

Number  Start   End     Size    File system  Name         Flags
 1      2097kB  1051MB  1049MB  fat32                     boot, esp
 2      1051MB  1001GB  1000GB  ext4         endeavouros
 3      1001GB  1002GB  1049MB  fat32                     boot, esp
 4      1002GB  1018GB  15.7GB  btrfs
 5      1018GB  1033GB  15.7GB  btrfs
 6      1033GB  1034GB  1049MB  ext4
 7      1034GB  2000GB  966GB   btrfs


Model: Unknown (unknown)
Disk /dev/zram0: 33.6GB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0.00B  33.6GB  33.6GB  linux-swap(v1)

This included endeavour and the dualbooted os.

I’ll grab the efibootmgr in a sec, doing this from the ubuntu based distro I dualbooted, so it doesn’t have it. And, yes but no. I installed it with systemdboot, but later manually changed it to grub, which was a whole messy ordeal documented in another newbie post on here.

BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0002,0005,0004,0001,0006,0000
Boot0000* EndeavourOS	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0001* Windows Boot Manager	HD(1,GPT,f1dfc8c9-c51b-40dd-a480-0020996448e9,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d0000004d000100000010000000040000007fff0400
Boot0002* ubuntu	HD(1,GPT,6c009482-5afc-4f35-bc1e-1ab79172223b,0x1000,0x1f3fff)/File(\EFI\VanillaOS\shimx64.efi)
Boot0004* ubuntu	HD(3,GPT,f55647e2-6f22-41af-8de6-44507156a681,0x747ff000,0x1f3ffd)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* UEFI OS	HD(1,GPT,6c009482-5afc-4f35-bc1e-1ab79172223b,0x1000,0x1f3fff)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0006* UEFI: KingstonDataTraveler 3.0, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(24,0)/HD(2,MBR,0x59bf9392,0xe6673f0,0x10000)0000424f

As you can see, quite the mess. I’m not entirely sure what’s what anymore with this.

I assume this is your EnOS’ ESP?
If so, what happens if you go into Bios and change the boot order?
Move UEFI OS to the top of the boot order and boot up the system.

That’s correct. I’ve tried manually booting into uefi os though and no dice. Before messing this up, that was still booting as systemdboot. I don’t remember what it did when I tried earlier but it wasn’t that.

My bios boot menu doesn’t look like this, which is confusing. There’s windows, two ubuntu’s, one as the empty grub and one the working vanillaos install, and the now broken uefi os. Of course also the kingston usb I’m live installing with.

Since you didn’t post the whole output of the parted -l I have to make the assumption that the disk is /dev/sda.

Adapt the following to correspond to your actual disk.

In the live session:

  • sudo mount /dev/sda2 /mnt
  • sudo mount /dev/sda1 /mnt/boot/efi ##assuming your ESP is mounted at /boot/efi
  • sudo arch-chroot /mnt
  • grub-install
  • grub-mkconfig -o /boot/grub/grub.cfg

If everything goes fine, type exit and press enter to quit chroot.

Reboot.

Gave that a go, and it mostly gets there. It hangs when booting on a startup job to do with something with a very short uuid. Likely boot0. Apologies for not writing that down better, it’s past 4am for me.

You need to check the UUIDs in the /etc/fstab of your installed system and make sure that they correspond to UUIDs of the relevant partitions of your disk.

Run lsblk -f to get the UUIDs of the partitions of your disk.

The /efi UUID was wrong. Fixed that and it booted perfectly again. Pleasantly surprised how easy that was. I thought this’d become like surgery. Thank you for your help! Now I just need to clean my very messy boot list :sweat_smile: Sounds like a tomorrow job.

1 Like

Great! Glad you got it working!

Yes. Have a good night sleep!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.