After successfully updating my bios, something went wrong and I ended up with a blinking cursor on the top left corner of a black screen. No errors, no nothing. The bios now only listed a SATA: <disc name> boot option in place of the usual UEFI ubuntu one. I'm using a GPT partitioning scheme.

I eventually found that the working solution was to properly reinstall grub-efi-amd64. So, how do I do this ?

PS: Actually, i succeeded to reinstall GRUB2 EFI on my own and will post my answer here as I was unable to find any complete how-to on this.

link|improve this question
feedback

2 Answers

up vote 4 down vote accepted
  • Boot your computer with a live-usb/CD in UEFI mode. I had two boot options <flash_drive> and UEFI: <flash_drive>, the second is needed to expose the efi variables in /sys/firmware/efi/ so that efibootmgr don't fail later on. Booting with the first option gives me the following error:

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

    modprobe efivars did'nt work for me.

  • chroot into the broken system (similar to the ubuntu grub2 help but with efi specificities):

    sudo mount /dev/sda2 /mnt #sda2 is my root partition
    sudo mount /dev/sda1 /mnt/boot/efi #sda1 is my efi partition
    for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
    sudo cp /etc/resolv.conf /mnt/etc/ #makes the network available after chrooting
    sudo chroot /mnt
    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
    
  • 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 (different partition table, separate /boot partition, etc.) and it may not be the only option but this worked just fine for me.

link|improve this answer
feedback

I would up-vote this, but apparently I don't have enough rep on SuperUser. I'm glad I finally found an answer to this after days of fighting clones that worked but wouldn't boot. I think it all relates to UEFI and some kind of "secure booting" mechanism or something.

I'm working off-line, so apt-get wasn't an option. What I did was put Ubuntu Desktop on a USB stick, add the grub-efi and grub-efi-amd64 packages to the root of the USB stick (grub-efi_1.99~rc1-13ubuntu3_amd64.deb and grub-efi-amd64_1.99~rc1-13ubuntu3_amd64.deb for Ubuntu 11.04 - change as appropriate for distro and architecture), and put the following in a script on the USB stick as well:

#! /bin/bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
dir=`dirname $0`
sudo cp $dir/grub-efi*.deb /mnt/tmp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb"
sudo shutdown -r now

Boot up the Live USB stick, open a terminal, run the command, and the job is a good 'un! The only occasional problem is that UEFI sometimes got moved down the boot priority order below the HDD, at which point you need to go into the BIOS and change the boot order to stop it trying (and failing) on SATA: drive.

You can also use dpkg-reconfigure instead of dpkg -i, but that asks a couple of boot loader questions.

[edit] I also don't have enough rep to comment, so what I thought was a comment on a reply turns out to be a reply.

link|improve this answer
Welcome on board! Actually you need 15 points to vote, 50 to comment (see superuser.com/privileges), just look around for easy questions you can answer and you're good to go, that's the stackexchange way to say thanks :) Beware your script doesn't unmount anything before shutting down. Glad it helped. – Maxime R. Mar 2 at 8:38
Confusion was more because I've got accts on other related sites. Forgot I was new to this side. Linux normally unmounts on shutdown, and chroot with a command returns after it finishes, so I don't think it should cause a problem. I did find that it won't abort if you didn't UEFI boot the live distro, but it wasn't a priority to test whether sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb" && sudo shutdown -r now gave the right behaviour. – IBBoard Mar 2 at 19:24
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.