4

I've an acer aspire e 14.

It has a single HDD with 7 partitions:

  • EFI system on /dev/sda1
  • Something described as "Microsoft Reserved" on /dev/sda2
  • Windows 10 FS on /dev/sda3
  • Linux FS on /dev/sda5
  • Swap on /dev/sda6
  • Microsoft Windows Recovery Manager on /dev/sda4
  • Free Space on /dev/sda

Now the thing is, I'm sure both windows 10 and linux (lubuntu) are installed on UEFI mode, however there's no entry in the boot order to let me select ubuntu or grub as the prefered boot option.

If I don't do anything at boot it will automatically boot to windows 10 without asking anything.

If I want to boot to ubuntu I have to do the following trick:

  1. Insert a bootable USB stick (with grub)
  2. Once the computer boots, the grub of usb stick lets me choose between trying the live version of the OS in the USB or installing it, I just press Escape.
  3. This brings up a console into which I just type 'exit'.
  4. The following screen seems to be the UEFI boot selection, and it lets me choose between booting the USB, an 'unknown device', or windows 10 boot manager. If I choose the USB it just goes back to the screen on step 2. If I choose the last it boots windows 10, and if I choose the 'unknown device' it finally shows the screen of grub that's installed in the computer which lets me choose to boot lubuntu or windows.

I really have no idea as to how to solve this issue, so any suggestion or advice is welcome.

(Edit) Among the things I tried are the following:

  • "efibootmgr -v" shows up two entries for the same file (an \EFI\ubuntu\shimx64.efi) one named ubuntu, and the other "unkwnown device" this last one also finish the description with an RC. I tried to change the --bootorder to match both of them before the windows boot manager, to no efect, at restarting I boot to windows, and when going back to linux the boot order is not the one I placed before.
  • I tried redbuilding the grub as suggested by SmallLoanOf1M, to the same result, but I noticed a weird thing, my linux has a /boot/efi folder. But when I mounted the EFI system (/dev/sda1) to rebuild grub, what I got was that there is an "EFI" folder (notice the caps), could that be the problem? and if so, how should I solve this without messing up anything?

migrated from serverfault.com Aug 26 '16 at 4:33

This question came from our site for system and network administrators.

  • @Ignasi how did you finally solved your problem?? cause I have the same one and my laptop model is acer aspire f 15. the only diffrence is that ubuntu is installed alone on my laptop – Fatemeh Karimi Jan 21 '18 at 17:06
4

You're looking for "efibootmgr". This program can be used on a GNU/Linux system that has booted into EFI mode (so use a live disk or something to get to it).

It has a few switches, and is generally pretty simple. You're looking to create an EFI boot entry, and also view existing entries.

You can view the existing boot entries with "efibootmgr -v". This will reveal either a lack of an EFI entry, or perhaps a malformed EFI entry.

If you have an entry already, or if there is nothing there at all, rebuilding the GRUB should invoke efibootmgr to create an entry for you. This is the easiest course of action. You should do this within a chroot of your already installed system (another reason why we're using a live system). If you don't know how to set up a chroot environemnt, please reference this guide: https://help.ubuntu.com/community/BasicChroot

After that is done, reinstall the GRUB package:

sudo apt-get install --reinstall grub-efi

Once that is complete, stick the GRUB on your disk again:

sudo grub-install /dev/sda

Re-create your GRUB config (this should invoke efibootmgr as well):

sudo update-grub

Check that you have EFI boot images in /boot/EFI for your linux install. You should have directories for both Windows and Linux side by side, with .efi files in each.

Finally, check that you have a proper boot entry in your EFI NVRAM using efibootmgr -v

If you still don't have one, can verify that you have the .efi files in a mounted FAT filesystem on /boot/EFI and then create the entry yourself. This is where things get a little odd for me to describe here, but the efibootmgr man page is very helpful: http://linux.die.net/man/8/efibootmgr

EDIT: More info on manually creating an EFI entry:

Since the automatic GRUB steps don't appear to have helped in your case, let's make an entirely new EFI entry that will point to your GRUB binary. We'll use efibootmgr for this.

Thanks to the information you provided, we can make a command that should work for you in a copy/paste capacity. Cool. Before you begin with this, get into a chroot env on your native system from an EFI booted live one just as suggested above. Also, mount your EFI filesystem to /boot/efi within the chroot.

This can be accomplished with one command (tailored for your situation):

efibootmgr -c -l \\EFI\\ubuntu\\shimx64.efi -L UbuntuBoot

This is a secureboot (that's what shimx64 is) EFI entry that points to the GRUB binary (rather than the default, which would be elilo.efi - which you don't have), has a cosmetic name of UbuntuBoot (to differentiate from the others), and will use /dev/sda and /dev/sda1 both as the disk and partition respectively. This is default for efibootmgr -c, so if you had the EFI filesystem on a different disk or partition, you'd have to specify explicitly via options. The backslashes have to be escaped with backslashes to be "literal".

Once you've created that entry, you should be able to see it via efibootmgr -v. If it's there, try booting into it. If you can boot into it, you should probably delete the old ones.

This kind of problem when installing Windows is common, but only if you choose to install the EFI binaries to the "removable disk EFI region" of your drive. Only one EFI entry may go there, and that is the region Windows uses no matter what to accomplish EFI booting. We typically only use that area on buggy EFI systems that won't boot any other way, but it is guaranteed to work on anything.

However, installing another EFI enabled OS on that same area will blow your previously installed EFI binary away. When installing most Linux distros, it will typically ask if you want to force GRUB installation to the "Removable media path" for EFI. Choose no, and this scenario shouldn't happen again. It isn't necessary to use the removable media path on just about any modern EFI.

  • Thanks for your help, I couldn't solve it yet but it seems we are getting close to it, can you please check the post for what I've tried. Thank you : ) – Ignasi Aug 25 '16 at 12:45
  • Ah, the EFI folder within "efi" is normal. What really matters is that the boot entry in your EFI NVRAM points to it, no matter the path. It should state the path to your firmware extension file (which happens to be a GRUB in your case) when you use efibootmgr -v, like so (from my system): #> efibootmgr -v ... Boot0004* debian HD(1,GPT,<GPTUUID>/File(\EFI\debian\grubx64.efi) This points to (from the root of the EFI filesystem), my grub EFI image on the disk and the partition that this EFI filesystem resides. I'll make an edit to my answer to provide more info. – SmallLoanOf1M Aug 26 '16 at 4:06
0

I had the same problem.

For me in the BIOS there were 2 Windows boot managers listed. When I moved the one without a number behind it up in priority and rebooted. I now got into GRUB for some reason. When I went back into the BIOS the highest priority windows boot manager no longer had a name.

This was all very strange and I dont understand what happened but it works for me now. The reply to the post is a bit late but perhaps it helps someone else.

  • 1
    (1) If you have two Windows boot managers, I believe that you don’t have the same problem.  (2) The OP says “If I don't do anything at boot, it will automatically boot to Windows 10 without asking anything.”  Can you explain how the OP (or somebody else with the same problem) can use your answer?  Please do not respond in comments; edit your answer to make it clearer and more complete. – Scott Aug 28 '18 at 20:59

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.