3

I installed Ubuntu 16.04 by booting from a USB, choosing "Try Ubuntu without installing", and then inserting another USB and directing the installer to install there. I told the installer to instal the bootloader on /dev/sdc2 which is the ESP. I know the bootloader was indeed installed because I can see the shim and GRUB EFI files on that partition now.

However, when I tried to boot after installing, instead of giving me the boot menu it only booted to the rescue prompt:

grub rescue>

I then found that my ESP partition is hd0,gpt2 while I expected hd1,gpt2 (using grub's naming scheme here).

I looked through similar questions but unfortunately I only found information about BIOS systems and not EFI, where / also contains /boot(/efi). I am looking for a way how to proceed with / on hd0,gtp3 and the grub efi files on the other disk. The kernel and initrd are both located inside of the ESP, the problem must be at another point.

How can I fix this?

Output of ls:

(hd0) (hd0,gpt5) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,gpt8) (hd1,gpt7) (hd1,gpt6) (hd1,gpt5) (hd1,gpt4) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1)

output of ls (hd0,gpt2)/:

syslininux/ vmlinuz.efi inird.lz efi/

content of /media/ubuntu/ba6e9aff-b9b7-4c4f-8441-98db8ec7a08a/boot/grub/grub.cfg:

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-ba6e9aff-b9b7-4c4f-8441-98db8ec7a08a' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd2,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt3 --hint-efi=hd2,gpt3 --hint-baremetal=ahci2,gpt3  ba6e9aff-b9b7-4c4f-8441-98db8ec7a08a
else
  search --no-floppy --fs-uuid --set=root ba6e9aff-b9b7-4c4f-8441-98db8ec7a08a
fi
linux   /boot/vmlinuz-4.4.0-28-generic.efi.signed root=UUID=ba6e9aff-b9b7-4c4f-8441-98db8ec7a08a ro  quiet splash $vt_handoff
initrd  /boot/initrd.img-4.4.0-28-generic  }  

Update: i reinstalled with grub-install /dev/sdb2 grub into /dev/sdb2 but most grubfiles are still in /dev/sdb3 so grub can't access it because it don't know how to load the ext2.mod. Part of the output was using x86_64-efi arch.

I messed a bit with the rescue console and getting slowly better but I may have found the cause, why it can't access it. The grub rescue mode only acceptes only i386-pc modfiles, but all installed modfiles are x86_64-efi ones.

  • It was? I'm glad to hear it, but I suggested various things in chat. Could you please post an answer explaining what you did? – terdon Jul 2 '16 at 17:18
  • arrasndly not, I wrote this coment to soon, sure I will – Kupferdrache Jul 2 '16 at 17:24
  • it was a incomlete EFI implentation, that caused it. I could work around it see answer. – Kupferdrache Jul 3 '16 at 15:34
1

All this simply because somebody didn't fully implement the UEFI specification.

All you have to do is boot a live system and:

sudo mount -U <UUID of your ESP> /mnt
sudo mkdir /mnt/EFI/BOOT
sudo cp -v /mnt/boot/<your-vendor>/grubx64.efi /mnt/EFI/BOOT/

and then shutdown, remove the live system and reboot.

More info about the path used can be found here.

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.