Restore EFI boot partition

Question

I am triple booting Ubuntu, Debian, and Fedora. When I installed Fedora from a liveCD I got excited and kept hitting next, not realizing I was not installing GPT, but rather LVM.

After doing this I cannot boot from a hard disk. The EFI menu doesn't even show my hard drive as a boot option (although it detects it in hardware).

I have a work-around currently, which is odd in how it works, I use a liveboot USB (Yumi) and choose to run Linux from hard drive, and I can choose between the distros I have on my computer. However I need this USB to boot into a distribution.

I am unsure exactly how to restore my system.

My computer came with Ubuntu installed, ASUS XC200 (netbook). I called Asus tech support, they wanted to re-image.. I will not give up so easily.

My /dev/sda1 (fat32, with boot flag) has an EFI directory on it for Ubuntu (assuming Ubuntu was loading GRUB> chainloading Debian).

How do I start to fix this? And what information do people need?

(I have no CD/DVD Player)

Note with efibootmgr:

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.

When I run modprobe there is nothing with efivars.

---

Update/Things I tried so far:

---

I tried the answers posted below [1], [2] currently, good research, and in most cases I believe they would work. They did not however in my situation.

Current Tools

Disks--

• Lost extra flashdrives with Kali
• & Debian
• & Ubuntu 14.04
• still have Yumi with Ubuntu 12.04.

Steps taken recently (after following answers):

• Ran Live Ubuntu
• Wiped /dev/sda except the fat partition (GPT/ESP)
• Tried to do install of Ubuntu, didn't work problem with grub and EFI on my GPT partition
• Used fsck just in case (fine)
• Used parted/gparted to wipe all then make GPT and other partitions(set boot flag on ESP)
• Tried Install again (didn't work same error)
• Partitions looked funny, (missing space)... Scratched Head
• Wiped partitions/Made partition for LiveUSB onto Harddrive
• Used dd to write LiveUSB to /dev/sda4 (believe this was number)
• This booted, but needed my USB to be in place so was useless
• Tried to use gfdisk, made me reboot lost session
• Split my LiveUSB
• Downloaded Arch .iso, and dd'd onto 2nd USB partition (LiveUSB)
• Kept Ubuntu LiveUSB session up, went through partial install (up to chroot of Arch while in live session)
• Had problems with things working right
• Ran Arch Live, went through install (zapping and initial creation of partitions worked better than on parted/gparted)
• Used directions to dosyslinux (from within Arch Install Guide)
• Basically rewrote all my efi to brand new
• Running great on Arch
• Unsure whether/how to answer my own question

Answer 1

Forget grub entirely - it is nothing but a distraction. It isn't even a boot-loader anymore; on EFI systems the bootloader is built-in to the firmware. grub is just a boot-manager in that context - and almost definitely entirely redundant. What's more - it is probably the grub install that broke everything in the first place.

These are the things you need:

1. A FAT-formatted GPT partition of type ef00.
2. A UEFI-compatible system kernel located on that partition (such as the linux kernel).
3. The path to that system kernel saved to a UEFI environment variable (commonly Boot0000-{UUID}, but this also depends on the value of BootOrder-{UUID}).

Strictly speaking, that is all. You can achieve the above setup with nothing more than gdisk and the efibootmgr command-line tools.

Pragmatically, a boot-manager does make sense - but grub is the most complicated of all of those available. As is elsewhere recommended, rEFInd is probably the best of the bunch.

I have written a step-by-step tutorial before on how to partition, format, and setup a rEFInd-enabled EFI system partition before here. Here also is another answer on this subject, in which you might find some further explanation about the assertions I make here.

Answer 2

When I reinstalled my ESP and grub I used rEFInd: http://sourceforge.net/projects/refind/files/?source=navbar (the flashdrive variant) to boot into my distribution.

After booting mount your ESP into /boot/efi

mount -t vfat /dev/yourESPdev /boot/efi

Then you should be able to reinstall grub with this EFI directory.

grub-install --efi-directory=/boot/efi

This should restore grub. If your ESP was deleted and you had to recreate it, then you will have to update it's UUID in /etc/fstab. Use blkid to list the UUIDs of your devices. After updating the UUID of your device in /etc/fstab, run update-grub.

You will probably also have to create a new efi entry for grub. Use something along the lines of:

efibootmgr -c -d /dev/yourHD -p ESP_PartionNumber -L "Boot Title" -l '\\EFI\\DIST\\grubx64.efi' -u "root=/dev/yourRootFS"

Where ESP_PartitionNumber is the number of your ESP on the hard drive (/dev/sda1 would be 1), and DIST is a folder whose name is specific to your distro unless you created it. The folder is in /boot/efi/EFI. Boot Title is simply the title you want for your EFI entry.

It has been some time since I reinstalled my ESP, so I can't test any of these commands again. You may need more parameters for some, but I am pretty sure this was all.

Answer 3

• Depending on the distribution you boot from:

  • For Ubuntu/Debian:

    apt-get install --reinstall grub-efi-amd64
    
    or alternatively: 
    apt-get install --reinstall grub-efi
    update-grub
    
    should the above give you a grub, but not a bootable one
    

  • For Fedora (up to 16, may work for others):

    yum reinstall grub-efi
    

    In the following command, you have to replace sdX with the device which has the EFI partition you want to boot from. In --part Y you have to replace the Y with the number of the EFI partition (as in /dev/sdXY).

    efibootmgr -c --disk /dev/sdX --part Y
    efibootmgr -v # verify a new record called Linux is there
    

    • Now type Ctrl+D to exit chroot, unmount everything and reboot:

    for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done sudo umount /mnt/boot/efi #please do this. corrupted efi partitions are not nice sudo umount /mnt sudo reboot

You may need to adapt this to your needs

source: su

Answer 4

When unsure with things like partitioning, try to salvage what you can and wipe the disk (or at least LVM/GPT metadata, at least some of that isn't just in the beginning of the block device IIRC). This well could save you some hair down the road (been there last century with BIOS, PTBL and MBR having three distinct ideas of what the drive geometry is).

If you really could roll back the situation, you wouldn't be asking here (don't take as offence, I've shot myself in a foot too with that book on "Next").

If you want to mess with it anyways, start with a rescue image (shameless plug: I'd use this one) and have a look at

• efibootmgr
• blkid /dev/sdX

You might find Rod's books on EFI useful too.

Good luck.

Answer 5

This is high on Google, but all of the other answers seem only partially complete, at least for someone in my situation.

My computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This might somehow be caused by a bug in my UEFI firmware and/or my use of a SATA slot that doesn't officially exist... or maybe some program is interfering with the partition, or the SSD itself is suspect... I dunno.

Anyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

This time around, that isn't an option. I've invested too much time in my configuration!

Today, my more diagnostic approach indicated that (at least this time) the cause was not - or not only - the firmware 'forgetting' the EFI partition existed - but also said partition had somehow gotten corrupted. Again, I can't explain this: it may be a shoddy firmware, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

The symptoms were:

• My UEFI was suddenly totally unaware the debian EFI boot partition existed
• The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
• I couldn't just mount as /boot/efi since...
• ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
• Pretty much everything was stuffed, overall, is what I'm saying.

So, here's a full and reasoned list of what I did to fix it (for now?):

• downloaded the exciting rEFIt @ http://refit.sourceforge.net/
• used the quality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
• which brought the very welcome news that my / partition was still intact
• booted said partition
• reformatted the errant EFI partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
• reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
• rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
• rewrote /etc/fstab to refer to the /dev/disk/by-id/ata-EVILCORP-C3PO-partN type paths for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
• magically returned to the adequacy of a normally bootable Debian. for now.

As they say, "until next time" - perhaps literally. Maybe this will help some other lost soul, frantically searching Google on some failing borrowed PC.

Answer 6

This is a small but important note:

Most of the times when you get Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. is due that you didn't boot using UEFI. This variables only show when the running system was boot with UEFI, using the CSM they are not enabled... so this is a chicken/egg problem, for you to setup UEFI, you need to boot using UEFI! :)

So try to setup as much as you can then grab the rEFInd usb or CD image and use it to boot the system the first time. After this to finish the setup without any problem.