I've gotten a surface pro 3 and installed Ubuntu xenial nightly on it. I've disabled secure boot and when I reboot the system after install it goes straight to the bios screen without any boot loader (grub).

If I reboot the USB disk and use grub from the install menu I can get the system to boot with the follow grub command sequence.

> c
> ls (hd2,gpt2)
> set root=(hd2,gpt2)
> linux /boot/vmlinuz-4.4.0-2-generic root=/dev/sda2
> initrd /boot/initrd.img-4.4.0-2-generic
> boot

I've tried running efibootmgr and it lists Ubuntu as the first boot. I've also tried installing refind through the PPA and it seems like it should work.

I tried using boot-repair and have the following pastebin of the output from that.


Same issue if I set the "Alternate System Boot Order" to SSD only or "Network->USB->SSD".

Any assistance in trying to figure out why I can't get it to load a boot loader would be appreciated.

  • I'm confused. The BIOS screen (POST) should come up before you see anything else. After all, the BIOS has to start before anything else can. – TheWanderer Feb 1 '16 at 22:55
  • sorry, by bios I mean the bios config screen. It comes up with a list of options such as "turn off secure boot, boot order..." I guess it's more a uefi boot config menu? I'm not sure what the right name for it is. – Rick Feb 1 '16 at 23:14
  • Ah. That's clearer. Have you tried boot-repair? – TheWanderer Feb 1 '16 at 23:19
  • 2
    That paste says you're trying to install 16.04, which would make this issue off-topic. – TheWanderer Feb 1 '16 at 23:39
  • 1
    I've tried this with 15.10 and when that failed attempted to use xenial hoping it'd support the hardware/etc better. I had the exact same issue with the 15.10 install. I can go back if that'll work better for assistance. – Rick Feb 1 '16 at 23:42

It looks like you've got a flaky EFI that's forgetting its settings. I recommend you look through the firmware's options to see if there's one to reset its options to the factory defaults. (Such an option usually exists.) If so, use it, then try either running Boot Repair again or re-install rEFInd (boot to Ubuntu in any way you can and run sudo refind-install). The idea here is that EFIs sometimes go "out to lunch" when cruft builds up in their NVRAM settings, and resetting them to the defaults sometimes revives them.

If that fails, look at the EFI/Boot directory on the ESP (that is, /boot/efi/EFI/Boot in Ubuntu) in more detail. Your Boot Repair output shows that this directory exists and holds a bootx64.efi file. This program should be launched as a fallback when everything else fails, but clearly you're not getting to GRUB. Other files in the directory might provide a hint about what the bootx64.efi file is -- there may be a configuration file or well-known filename. It could be that EFI/Boot/bootx64.efi a leftover Microsoft program, which could help explain things; deleting it might be in order in that case. You could also try putting either GRUB or rEFInd there -- copy the EFI/ubuntu or EFI/refind directory to EFI/Boot and then rename the boot loader (grubx64.efi or refind_x64.efi) to bootx64.efi. The result should be a system that boots.

  • 1
    Thanks, I had a /EFI/Boot that had left over files. When I moved that Boot to a Boot.bak and then copied refind into /Boot along with copying refind_x64.efi to bootx64.efi it worked out. – Rick Feb 2 '16 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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