0

I tried disabling secure boot, and checked my partitions, they seem ok. The computer does not load ubuntu but just reboot and select proper boot device. I ran boot info and this is the result http://paste2.org/JF36VyGZ .

  • The boot entries shown by efibootmgr do not show ubuntu, and 0 and 7 are missing. Odd, rest of install looks OK. What machine are you trying to install on, and is BIOS/firmware at latest version? – ubfan1 Apr 19 '17 at 4:40
0

In the short term, try putting my rEFInd boot manager on a USB flash drive or CD-R and boot using it. rEFInd will probably be able to boot your Ubuntu installation without any special configuration or changes; however, you may not want to boot through rEFInd on a USB flash drive in the long term....

As ubfan1 says in a comment, your efibootmgr output shows no evidence of a boot entry for GRUB (EFI/ubuntu/grubx64.efi on your /dev/sda1). Such an entry should exist. The two most likely possibilities for why it doesn't exist are a failure when installing the boot loader or a buggy EFI that "forgets" its boot entries.

To fix the first problem, you must create a fresh boot entry. You can do this after booting your system via rEFInd with the following command:

sudo efibootmgr -c -l \\EFI\\ubuntu\\shimx64.efi -L "ubuntu"

Note the double backslashes (\\) rather than single forward slashes (/) as directory separators. (I'm pretty sure that recent versions of efibootmgr can use forward slashes, but as you don't say what version of Ubuntu you're using, it's best to stick to the lowest common denominator.) Also, if Secure Boot is truly disabled, you can specify grubx64.efi rather than shimx64.efi; but the latter should always work, so it's the safer choice.

Reboot, and if Ubuntu starts up, type sudo efibootmgr to see if there's an ubuntu entry. If there is, you should be able to reboot, or shut down and reboot, and the system will start up again.

If that fails, then your best bet, if your computer is new, is to replace it because it's defective. Be sure to tell the manufacturer why you're returning it for a refund. They've had literally years to fix these bugs, and most have; but a few manufacturers are still shipping broken EFIs, and they'll likely continue to do so until the Sun is a cold ember unless people refuse to buy broken products.

If the computer is not new enough to be returned for a refund, there is a workaround: Back up and rename GRUB to the fallback filename (EFI/BOOT/bootx64.efi on the ESP). You can do so like this:

sudo cp -r /boot/efi/EFI/ubuntu /boot/efi/EFI/BOOT
sudo mv /boot/efi/EFI/BOOT/shimx64.efi /boot/efi/EFI/BOOT/bootx64.efi

Again, you can specify grubx64.efi rather than shimx64.efi if you're certain Secure Boot is disabled; but shimx64.efi should work whether or not Secure Boot is enabled, and so is the safer choice.

This approach has several problems, although they're less significant for your single-boot system than for some. The biggest issue, if you must take this approach, is that updates to Shim and GRUB won't be automatically installed; you'll have to manually copy them from /boot/efi/EFI/ubuntu to /boot/efi/EFI/BOOT, much as in the preceding commands. Most such updates aren't really critical, but there's always a chance that an update will include an important security fix, so you should keep an eye on this.

|improve this answer|||||

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.