I was trying to dual boot elementary os with windows on my laptop (Asus Zenbook UX305). To do that I shrank the windows partition using the windows disk manager, and then used the Elementary installer's "install alongside windows" option to set up the linux partitions automatically. When I rebooted after installing I was put into the grub console. I was able to boot linux manually with the commands

grub> set root=(hd0,gpt4)
grub> linux /boot/vmlinuz-3.19.0-26-generic root=/dev/sda4
grub> initrd /boot/initrd.img-3.19.0-26-generic
grub> boot  

and I found that running the command

grub> configfile (hd0,gpt4)/boot/grub/grub.cfg

would load the normal grub menu as is supposed to happen - so there don't seem to be any problems with the config file itself. I also found that the root and prefix are on (hd0,gpt1), so running

grub> set root=(hd0,gpt4)
grub> set prefix=(hd0,gpt4)/boot/grub
grub> insmod normal
grub> normal

also loaded the normal grub menu. So possibly the problem is that grub is looking on the wrong partition?

In my BIOS, I have a choice between using grub and the windows bootloader to boot. Selecting the windows bootloader boots me directly into windows without any problems.

However, I can't find any way to get any fixes to stick after a reboot. I've tried rerunning grub-install /dev/sda, recreating the config file with grub-mkconfig, and using the Ubuntu boot repair gui tool - none of these have worked. Is there any way to fix this short of reinstalling either or both OSs? I'd rather not have to reinstall windows if possible.

3 Answers 3


I had the same problem found the solution :
1) in the grub rescue mode, run “set”

2) It show me prefix=(hd1,gp1)/boot/efi/EFI/ubuntu/
3) In my case, as I have KDE NEON the folder /boot/efi/EFI/ubuntu/ doesnt exist, but the folder //boot/efi/EFI/neon/ It does exist. SO the problem is that is pointing to an non exsiting folder
4)So I copied all the folder /boot/efi/EFI/neon/ to /boot/efi/EFI/ubuntu/ . That did the trick
IN my case also is wrong (hd1,gp1) because it shoudl point to hd1,gpt5. But I DINDT changed that and it worked.
What I changed is the file /boot/efi/EFI/ubuntu/grub.cfg, for use msdos format:

search.fs_uuid xkjdiw-18e9-4d0a-ac55-2skjdh8425f root hd1,gpt5 
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

It seems that the GRUB menu is failing to load because it is reading an incorrect efi file in /boot/efi/EFI/grub/.

Once you have booted into elementaryOS, run the following commands to replace the grubx64.efi file within that folder.

cd /boot/efi/EFI/grub
sudo cp grubx64.efi grubx64.efi.backup (just in case)
sudo rm grubx64.efi
sudo cp /boot/grub/x86_64-efi/grub.efi /boot/efi/EFI/grub/grubx64.efi

This solution comes from users discussing a reported bug in elementaryOS. See details at: https://bugs.launchpad.net/elementaryos/+bug/1492801

I faced the exact same issue as you (I have installed elementaryOS Freya 0.3.1 alongside Windows 10) and followed the steps you described before finding this solution.

It is worth noting that before applying the fix, I had disabled fast startup in Windows 10 which may or may not had an effect. See http://www.tenforums.com/tutorials/4189-fast-startup-turn-off-windows-10-a.html

In addition, I had to disable secure boot in order for this to work. With secure boot enabled, my UX305 failed to load grub completely. Press the Esc key on the first screen at startup, then enter setup and turn secure boot off from there. Alternatively, there may be a way to get secure boot to work but I am happy with this solution for now - my UX305 now loads the GRUB menu complete with a Windows option!


Yes we can

I found a solution how we can change the prefix permanently. However, it has the following caveats: We have to change it directly inside the grubx64.efi binary file, and we have to keep the file the same length. And how much space you are given may depend on your distribution. Read along for further explanation. Disk and Partition are set depending on which partition is loaded by the UEFI boot option you chose at startup.


  • If you want to do this you will have to turn off secure boot as the hash will have changed and the binary will be rejected. Not sure if this can be fixed by installing your own hashes (search for MOK).
  • Always make backups of the files you are changing. If you do as I did, you will be able to reverse your changes with a bootable USB stick. If you do not have another system at hand, then please create a bootable USB now and test if you can boot into it.

First the Problem:

Basically, this whole issue is a limitation of Secure Boot. For Secure Boot to accept the grubx64.efi file, it must be signed by an accepted authority. Therefore, this grub executable is signed and prebaked. The current standard to set this prefix seems to be /EFI/$(lsb_release -i -s). This of course also means that - no matter which loader path (for example efibootmgr--loader \\EFI\\other\\SSHIMX64.efi) - you specify when creating a new boot option, it will have no effect on the prefix variable in the grub bootloader.

The solution:

Let's assume our distro is ubuntu and we would like to rename that to longubuntu for some reason, we can do so following these steps:

# List contents of EFI directory
find /boot/efi/EFI;
# Rename the directory
mv /boot/efi/EFI/ubuntu /boot/efi/EFI/longubuntu;
# List contents of EFI/longubuntu for easy access
find /boot/efi/EFI/longubuntu;
# Always make a copy of the original
cp /boot/efi/EFI/longubuntu/BOOTX64.CSV /boot/efi/EFI/longubuntu/BOOTX64.CSV.bak
# Inside the .csv-file change 'ubuntu' to 'longubuntu'
nano /boot/efi/EFI/longubuntu/BOOTX64.CSV

Before proceeding:

Check that there are enough nul-characters available in the binary file. It is important to keep the overall length the same. If you don't do that, it will throw an error - if this happens to you, then copy back the original grubx64.efi and try again. When inspecting my grubx64.efi-binary with VS Code I do have enough available to change the prefix to my hearts content:
Many nul-characters directly behind /EFI/ubuntu

Now to the fun and critical part:

As I already said, we need to make sure that we keep the binary file the same length. We can so by either padding the new prefix with nul-chars (\0) or by padding the text to replace with nul-chars.

So if you want to specify a longer prefix (as in my case), you can do so with:

# Parameter -pi.bak will create a backup for you
perl -pi.perlbak -e 's/EFI\/ubuntu\0\0\0\0/EFI\/longubuntu/g' /boot/efi/EFI/longubuntu/grubx64.efi

If you choose a shorter prefix (for example bent), then pad the new value with \0:

# Parameter -pi.bak will create a backup for you
perl -pi.perlbak -e 's/EFI\/ubuntu/EFI\/bent\0\0/g' /boot/efi/EFI/longubuntu/grubx64.efi

You can check the results of your operation with, which will print the line containing the prefix.

$~: grep -a 'EFI\/longubuntu' /boot/efi/EFI/longubuntu/grubx64.efi

Which prints:
Grep will print the new prefix.

Do not forget to add a new boot option!

I will use efibootmgr. With efibootmgr we can delete the old boot option and add a new one.

# Print current boot options
:~# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* ubuntu        HD(1,GPT,28bd5547-5802-4f9c-97da-22ddd968dea6,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
# Delete current
:~# efibootmgr -b 0 -B
# List disks
:~# lsblk
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0   238G  0 part /
# Create new boot option
:~# efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Long Ubuntu Name" --loader \\EFI\\longubuntu\\shimx64.efi


When you reboot now. You should still boot into your distribution as before.
If not, then boot into the USB stick and mount the EFI-partition. Then undo the changes or copy back the original file. On my device, I mount the EFI-partition like so:

:~# lsblk
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0   238G  0 part /
:~# mkdir -p /media/efi; mount /dev/nvme0n1p1 /media/efi

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .