7

I have been trying to install grub in efi partition for the past week and I have been getting:

Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.

But I found that by using --no-vram I get no error installing grub. I'm a Linux noob and want to know what was causing the error.

WinEunuuchs2Unix
  • 102,282

2 Answers2

7

With BIOS, the motherboard stores the order of physical devices to boot from in non-volatile memory (NVRAM) so it survives a reboot. This ensures when you turn the machine on the motherboard still boots devices in the order you (or the factory) configured it to. The BIOS will then try executing the MBR in the first logical block address (LBA) of each device until one of them works. If you manually select a device to boot during startup it will do as you ask and attempt booting from the first LBA of that device instead.

Assuming a disk is formatted with GPT, when the motherboard uses UEFI booting the MBR doesn't need to contain a bootloader (or anything for that matter). Instead, the disk contains an EFI System Partition (ESP) which is essentially a FAT-formatted partition containing bootloader code stored in files. The FAT filesystem may also contain other files needed by the bootloader (e.g. logos and backgrounds used by a splash screen during the boot process).

For UEFI booting on a UEFI motherboard it is assumed the disk is part of the system so when you grub-install, part of that installation process should be placing an entry into the motherboard's NVRAM containing the path of the bootloader within the ESP (see section 3.5.1 Boot via the Simple File Protocol of the UEFI spec). This entry can then be set to the default, or just presented as an option. For more information on EFI Boot Loaders I strongly advise reading Rod Smith's Managing EFI Boot Loaders for Linux.

For a device which is not normally attached to a motherboard (i.e. USB hard disk) it does not make sense to store this entry in the motherboard's NVRAM as the device might not be there during most boots. I believe the --no-nvram option tells the grub-installer not to modify the motherboard's NVRAM for this purpose.

Furthermore, if a motherboard is instructed to boot from a removable device for which it has no boot entry in its NVRAM, UEFI defines a default path for it to try booting from (see section 3.5.1.1 Removable Media Boot Behavior of the UEFI spec). The path, relative to the root of the ESP is \EFI\BOOT\BOOT{architecture}.EFI with the following {architecture}s.

  • 32-bit → IA32
  • x64 → x64
  • Itanium architecture → IA64
  • AArch32 architecture → ARM
  • AArch64 architecture → AA64

I believe the --removable option tells the grub-installer to use this path, rather than its preferred path is probably necessary if not modifying the motherboard's NVRAM otherwise one would need to manually specify the bootloader after manually selecting the removable device.

Note: I say "believe" above because I haven't tested this.

Edit:

I realise none of this explains why your motherboard won't allow GRUB to modify its entries. But hopefully that explains why that switch helps. The error message you provided suggests all of the motherboard's boot entries have been populated and, quite reasonably, it isn't appropriate for grub-install to decide which of your boot entries to overwrite. You could try using efibootmgr to display your boot entries and delete some that you don't need. Rod Smith's answer to this question should show you how.

Community
  • 1
Samuel Harmer
  • 412
0

I searched high and low for a really good explanation. The best I can come up with so far is the man grub-install explanation:

   --no-nvram
          don't update the `boot-device'/`Boot*' NVRAM variables. This option is only
          available on EFI and IEEE1275 targets.

The "NVRAM variable" definition first google search hit is strangely Wikileaks because the CIA uses for spying:

NVRAM Variables Explained

NVRAM is non-volatile RAM that is used in EFI to store variables that need to persist between boots. Many of these NVRAM variables are architecturally defined, and setting invalid options to NVRAM could cause a machine to not be able to boot.

During the startup process, multiple drivers and applications can rely on NVRAM values to help them do their jobs. Below is a diagram from the UEFI 2.56 specification that shows this happening.

Thomas Ward
  • 74,764
WinEunuuchs2Unix
  • 102,282