Ubuntu – Standalone Grub2 EFI installation – grub.cfg placement

bootgrub-efigrub2uefi

I'm trying to use Grub2 as the boot manager on an EFI system in standalone mode. (The only persistent harddisk has OS X on it; Linux and Windows drives may or may not be present at times, hence the standalone mode.)

I'm using SuperGrub2Disk, which is one EFI executable, and as I understand it Grub2's executable in this mode has an embedded disk image that it mounts for its root partition, with a copy of its own config file inside.

I'd like to override or amend this config file with an external grub.cfg. I've tried placing it next to the grub EFI executable or in the root of the ESP partition, but it's not being recognized. I've also tried to load it from a grub command line by the following command:

configfile (hd3,gpt1)/grub.cfg

This seems to have no effect other than clearing the screen – even though the config file is there as confirmed by ls.

Could anyone tell me if there's a way to use an external config file with an EFI standalone blob?

Best Answer

GRUB 2 binaries include hard-coded references to their configuration files. I haven't really been keeping track of all the gory details, but as I understand it, there are two EFI GRUB 2 binaries for Ubuntu on AMD64/x86-64 systems:

grub2-efi-amd64 -- This is the version of GRUB 2 that's used on computers that do not use Secure Boot. As I understand it, the binary itself is linked on your computer from pre-compiled components included in the package. The resulting binary refers to a grub.cfg file on your Linux installation's /boot/grub directory. Thus, you can't use the grubx64.efi binary installed from this package on one computer on another one, because the binary is customized for the computer on which it was created.
grub2-efi-amd64-signed -- This version of GRUB 2 is compiled and linked on a Canonical system so that it can be signed with a Secure Boot key. One side effect of the requirement that the binary be signed is that it cannot be customized for your system, and as a result, this version of grubx64.efi looks in the same directory as the binary for grub.cfg. On an Ubuntu system, this grub.cfg file searches for /boot/grub/grub.cfg, but in principle it could be customized to do something else.

Thus, in your case you can't use the unsigned GRUB 2 binary; if you want to use a stock Ubuntu GRUB 2 binary, you must use the signed one. Alternatively, you could build your own binary, as described here, among other places.

In your case, though, I don't think GRUB 2 is really optimal. Both rEFIt (which is now abandoned) and my fork of it, rEFInd, feature dynamic scanning for available boot loaders. Thus, if you install rEFIt or rEFInd to your internal disk's EFI System Partition (ESP) and put the boot loaders for your OSes on their respective removable media, rEFIt/rEFInd will provide you with options to boot those OSes if and only if the appropriate disk is plugged in. This behavior, however, will depend on proper management of your boot loaders, placing each one on the ESP of its respective disk; if your boot loaders are all stored on your internal disk's ESP, rEFIt/rEFInd will show non-functional OS options at all times, just like GRUB 2 would. In either case, using rEFIt or rEFInd will obviate the need to delve into the morass of manual GRUB 2 configuration.

Related Solutions

Ubuntu – Grub2 EFI: Where is the EFI partition

The hard disk is definitely set up for BIOS-style booting. Specific evidence of this includes:

The partition table is MBR. Although it's theoretically possible to boot in EFI mode from an MBR partition table, to the best of my knowledge Windows does not support this configuration. Certainly its installer doesn't; the Windows installer supports MBR-on-BIOS or GPT-on-EFI, but not MBR-on-EFI or GPT-on-BIOS.
There's no ESP on /dev/sda. (There are EFI boot files on /dev/sdb1, but that looks like a USB flash drive, not your regular boot disk.)
The Boot Info Script output identifies GRUB as being installed in the MBR of /dev/sda. This is consistent with a BIOS-mode GRUB installation.
The Boot Info Script output has identified /Windows/System32/winload.exe as a boot file on /dev/sda2. If this were an EFI installation of Windows, you'd see a reference to winload.efi somewhere.

Thus, whatever the source of the problem, it doesn't seem to have anything to do with EFI; it's a straight-up GRUB-on-BIOS problem.

The biggest clue I see is this, from the Boot Info Script output:

=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 1 of 
   the same hard drive for core.img. core.img is at this location and looks 
   for (,msdos6)/root/grub on this drive.

Note in particular the reference to (,msdos6)/root/grub. Later in the Boot Info Script output, there's a list of boot files on /dev/sda6 ((,msdos6) in GRUB-speak). This list includes /boot/grub/grub.cfg, but there's no mention of anything in the root directory. In fact, the root directory (not to be confused with the / directory, whose name is pronounced "root") is the superuser's home directory, and it doesn't ordinarily hold boot files. Thus, I suspect that GRUB was mis-installed. Perhaps you used options to grub-install that you didn't mention and that were inappropriate, or perhaps there's a bug in the installation script. In any event, I recommend re-installing GRUB using the usual procedures for doing this on a BIOS-based computer. Note, however, that if your emergency system boots in EFI mode, that could create complications, so you should be sure to boot your emergency system in BIOS mode.

You can check your boot mode in Linux by looking for the /sys/firmware/efi directory. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode (although there are conditions when that file will be absent even though you've booted in EFI mode).

Ubuntu – Invalid EFI file path

Your GRUB entry for Windows is appropriate for a BIOS-mode boot, but not for an EFI-mode boot. This is a GRUB bug. You can try replacing the entry with something like the following:

menuentry "Windows 7" {
    insmod part_gpt
    insmod chain
    set root='(hd0,gpt5)'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

I make no guarantees that this will work, but it might. If it does, add that entry to /etc/grub.d/40_custom so that it will be created again whenever Ubuntu updates its GRUB configuration.

Another option is to use a different boot manager in addition to or instead of GRUB. rEFInd, for instance, will auto-detect both Windows and GRUB; and if you're using 3.3.0 or later kernels (as shipped with Ubuntu 12.10, but not with Ubuntu 12.04), you can boot Linux directly with rEFInd, bypassing GRUB entirely. gummiboot is another option with similar boot capabilities, but it requires more manual maintenance if you wanted to boot Linux directly with gummiboot.

Best Answer

Related Solutions

Ubuntu – Grub2 EFI: Where is the EFI partition

Ubuntu – Invalid EFI file path

Related Question