tl;dr:/boot/efi/EFI/ubuntu/grub.cfg references unknown partition, and this file is re-created in its faulty state if I delete it and run grub-install. How do I fix this?
Longer explanation:
I used my laptop to install a non-neon OS (Mint) on an external drive. During Mint’s installation I only selected the external drive for anything, including bootloader location.
Nevertheless, after removing the external drive, Neon doesn’t boot. Instead I’m dumped into a grub command line, from where I can boot Neon as below:
set root=(hd0,1)
set prefix=(hd0,1)/efi/neon
insmod linux
insmod normal
normal
I noticed that before the grub command line appears, an error flashes on the screen for a moment. That error is “no such device” and a UUID, which so far I’ve seen is only mentioned in /boot/efi/EFI/ubuntu/grub.cfg. /boot/efi/EFI/neon/grub.cfg references the correct one.
Still, if I delete everything from /boot/efi/EFI and run grub-install, the file is still re-created with the reference to the unknown partition.
I don’t know how or why the ubuntu directory is used, nor where grub-install finds any reference to that partition to recreate the file. Any idea how to fix this?
Firstly, just in case, you aren’t aware, the enumeration of devices (the 0, 1 and so on of hd0, hd1, and the a, b, … of /dev/sda, /dev/sdb) can vary from boot to boot, but usually changes only when things are plugged in or unplugged.
Secondly, using the utility efibootmgr is a good idea. It’s quite clunky but you can find out what the computer is doing.
Thirdly, you can tell grub-install what to do with the --boot-directory and --efi-directory options.
You don’t mention other installs. If you have other installs with grub, things get confused quickly.
The only other install is the one I did on the external drive, which isn’t even connected (and I did tell the installer not to touch my internal drive).
efibootmgr just points to the correct partition. All I know is that EFI/neon/grubx64.efi references EFI/ubuntu/grub.cfg which has invalid data, but grub-reinstall recreates that invalid data so it must be present somewhere else.
You should be able to boot into Neon faster by typing something like:
configfile (hd0,5)/@/boot/grub/grub.cfg
The “hd0,5” in the command is the location of your root partition (assuming you don’t use a standalone boot partition). I guessed, but partition 5 is pretty common in a dual boot system.
This problem seems very similar to the issue I had before with multiple operating systems in EFI, and the solution was to believe GRUB when it tells you that it only knows about the EFI/ubuntu directory. More details in this Unix & Linux stack exchange answer.
TL;DR solution: Do not use neon as the EFI entry - it will never work. Run:
to reinstall your EFI “ubuntu” entry and that would work. You may also want to use efibootmgr to remove the other entries.
What I believe Neon is doing, is to install two boot entries, one saying “ubuntu” - which is the one that actually work, and then another one saying “neon” which is what people see as the “default EFI boot option”, but now it is the default for grub-install and if you ever mess with the configuration, there’s no obvious way to fix it.
)