# Restore EFI boot partition

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
• Note that efibootmgr will only work if the system has been booted in EFI mode. Make sure your liveUSB supports EFI booting (it should have an EFI/boot/bootx64.efi file) and that you're actually booting it that way, not in legacy BIOS emulation mode. Nov 22, 2014 at 22:08
• @Wyzard Yeah I do not have an option to boot legacy, at this point I feel like this is fixed. I am just unsure as to how to answer my own question. I restored my EFI by doing a new one through a new Arch install. Nov 23, 2014 at 4:50

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.

• I ended up installing arch and using syslinux, so everything is pretty tidy on OS init. I just am not sure how to bring a step-by-step, how I did this except pointing to the Arch wiki. The main problem(s) seemed to be 1. I didn't know enough about the subject 2. My original EFI shell was/is gone 3. I had a complicated chainload all on grub, which was overwritten by Fedora LiveUSB (they don't like EFI I guess). I had just early that day said how I loved Debian because of how stable it was.. I guess I just had to break my system. Great links, I love your posts they always are informative. Nov 24, 2014 at 2:46
• @NoTime - the shell, at least, is easily fixed. You can just run it from your boot manager - or else you can create a separate boot-entry for it in the firmware bootloader proper. It's another UEFI-compatible kernel - and is freely downloadable. There is a link in the Arch wiki - but also, because the boot-loader is actually in the firmware, you can swap boot managers with ease once you get the hang of it. The shell is provided with the rEFInd cd image as well. Maybe give it a shot - also, install efibootmanager - I think its man page even covers a shell entry by example. Nov 24, 2014 at 4:11
• I haven't tried rEFInd yet. I might for my old iMac (1st intel, no longer supported). Right now I can't to mess too much with this one; I have to keep it up and running. When I was using efibootmanager(from my 3 OS's, and live) I kept getting problems loading my .efi files I don't know if they were corrupted or what. My actual EFI/"BIOS" screen is pretty basic, and I believe that whatever Fedora did messed with it, because I can't run the shell from in there (or add boot option where I would point to fsx:\foo\bar.efi)I used to be able to do tab autocompletes, but not sure now. I'm ok now tho Nov 24, 2014 at 5:46
• Grub is definitely a boot loader since it can load non EFI kernel images from filesystems the EFI firmware does not understand. It just also happens to provide much the same type of functionality as a boot manager in that it lets you choose different systems to boot and ways in which to boot them. A true EFI boot manager only allows you to choose which boot loader installed on your EFI system partition you want to load. Trying to bypass grub means you have to copy your kernel to the EFI system partition, and iirc, means you can't use an initrd. This will cause all sorts of pain. Nov 24, 2014 at 20:12
• @mikeserv It appears I should have asked about intraramfs, and EFI... possibly the boot process as well. There is a lot of going back and forth here. And it appears you 2 had this argument before unix.stackexchange.com/questions/122100/… :) Nov 26, 2014 at 7:16

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.

• 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

source: su

• The beginning of answer you did, did not include making the /mnt chroot. I am looking at the answer on su, I am having trouble chrooting from the commands in that answer. This may be dated.. or maybe I need to run everything from fedora, because some of these things are not on debian. Also nothing is showing up when I do modprobe efivars Nov 18, 2014 at 3:41
• why do you want to use chroot to solve this? Important is however that your boot from a uefi usb-drive. Nov 18, 2014 at 9:23
• Also if you can do it in fedora it should indeed work, you do not have to install your bootloader 3 times, just 1 time. Nov 18, 2014 at 9:41
• I am getting problems (running from an Ubuntu Live-USB) paste.ubuntu.com/9085912. In the answer you linked from, it required that you chroot (and mount to different area) prior to doing the commands you posted. Nov 19, 2014 at 3:59
• you chould just use your live-boot usb to boot into your fedora installation and install grub2, you do not have to chroot or boot into debian or ubuntu, you have to install grub just 1 time and do not do the things from the link if I did not copy it! mor information for configuring grub2 after reboot and debian or ubuntu would not be included in the boot-menu you can find here: fedoraproject.org/wiki/GRUB_2?rd=Grub2 Nov 19, 2014 at 22:44

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.

• What appears to be the problem for me is everything is failing now. I have done repair-boot, I have done fresh install (fails once it gets to grub install), did the other answer here (and the one from the su link). Just is odd, going to try your suggestions (see note above for efibootmgr -- gives error). I'm going to run through the EFI guide as well. Nov 19, 2014 at 4:15
• Yes, if you can not boot into 1 of your installed systems, but you can. You only have to install a (u)efi compatible grub, like I posted. Nov 19, 2014 at 12:53

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?):

• 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.

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.