grub rescue ls – no partitions shown?

Question

I’m trying to build a custom grub menu for an UEFI Windows/Linux multiboot setup. I’ve successfully tested the menu via a USB drive, containing:

/EFI/boot/BOOTX64.EFI
/grub/grub.cfg
/grub/x86_64-efi/*
…etc.

When booting from this drive, I can access the menu without issue. Next, I transfer grub to my PC's EFI system partition:

/boot/grub/bootx64.efi
/boot/grub/grub.cfg
/boot/grub/x86_64-efi/*
…etc.

Also on that partition is Windows’ bootloader, in /EFI/Microsoft/boot.

Finally, I use the Windows utility BOOTICE (or just the system BIOS) to add an entry for \boot\grub\bootx64.efi. I reboot, and up comes grub.

...Except rather than bringing up the menu, I end up at a rescue prompt. My assumption was that I'd simply put grub.cfg & the modules in the wrong place – however, what’s really strange is that ls shows no partitions – just (hd0) (hd1). My expectation was for something like (hd0) (hd0,msdos1), etc – but grub rescue can’t seem to ls any partitions at all. ls (hd0) and ls (hd1) both yield “Filesystem is unknown.”

My system contains a single physical disk, with partitions:

1 = EFI system partition (fat32)
2 = Veracrypted partition (with Windows installation)
3 = Veracrypted partition (data)
4 = Linux swap
5 = Linux root
6 = Linux home

Why would grub be able to startup from the EFI system partition - but then not be able to see that partition, or any other? And more importantly, how can I get its menu working from the internal drive like it did from USB?

Answer 1

ls (hd0) means you're trying to access the whole disk as a single filesystem; if the disk is partitioned in any way, the message (hd0): Filesystem is unknown. is normal and expected.

Instead, type just ls (hd0 without the closing parentheses, and press TAB. If GRUB can identify the partitioning type, it should list the partitions and their filesystem types if they're known to GRUB.

Your problem could be that GRUB is expecting its configuration file to be in <partition root>/grub/grub.cfg, not in <partition root>/boot/grub/grub.cfg, and likewise for the module directory.

The GRUB bootx64.efi file contains the GRUB core image, plus optionally some of the GRUB modules. If this set of embedded modules does not include part_gpt, GRUB won't be able to recognize a GPT partition table, which would make it impossible to access the filesystem that contains the rest of the GRUB modules. This would be another possible reason for dropping into GRUB rescue mode.

Answer 2

Thanks to telcoM's info about embedded modules in bootx64.efi, I was able to figure out the solution: basically, rather than copying all the grub files that had been grub-install'ed on the USB stick, I had to explicitly grub-install directly to the internal system partition.

Presumably when grub-install was run on the USB stick it saw that it was a MBR-partitioned device, and did not embed the part_gpt module in bootx64.efi, which is why it wasn't able to recognize any internal partitions - whereas when grub-install was run on the internal disk directly it saw GPT & embedded that module. In either case, the solution was not copying the grub files from the USB stick, but grub-installing directly to the internal partition.

Answer 3

I had a kernel error caused by an msdos partion and it caused my computer to say no disk found and only would boot into grub. In grub I ran the ls command and nothing was being listed. Here's what I did to get the ls to show listings ....

 Go to your grub command line type:

  set root=ls     ; Hit enter

Then run the ls command again and all your partions will be listed . This will help if you have a msdos kernel error where you will be able to find and fix the corrupted partion the msdos partition is causing grub to go haywire.