Ubuntu – Error: could not set EFI variable ‘OsIndications’

17.10partitioninguefi

After completing a command-line Ubuntu 17.04 to 17.10 upgrade from this link, I tried booting Ubuntu 17.04 from a live USB drive. Anticlimactically, I couldn't. I can still boot into the new Ubuntu 17.10 and Windows 8, both of which are installed on the hard drive. When I tried going into the UEFI configuration menu, I get that disconcerting message seen in the title: Error: could not set EFI variable 'OsIndications'

Using the application gnome-disks on Ubuntu 17.10, I can mount the partitions Recovery, Push Button Reset, and ESP, though ESP does not show up in nautilus.

I use live Ubuntu and live Kali Linux among other OS's frequently, and having no access to the UEFI menu cuts me off from using them anymore. Are there some commands or startup key sequences I can use to rescue the EFI partition, whatever it may be? I'm not eager to try to troubleshoot it myself as I'm aware how delicate the EFI is. Any help is greatly appreciated!

Best Answer

The EFI partition is fine, the problem is in firmware; however, there is a fix.

edit /etc/grub.d/30_uefi-firmware and remove the if/then/fi statement. I changed mine to read:

gettext_printf "Adding boot menu entry for EFI firmware configuration\n" >&2

cat << EOF
menuentry 'uefi-firmware' {
fwsetup
}
EOF

Then sudo update-grub, you should now have a UEFI firmware option in grub.

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 – How to boot load the kernel using EFI stub (efistub) loader

The commands below are more generic then for kernel version 3.13.0-35 only.

1. Mount the efi partition and copy the kernel files there

$ mount /dev/sda3 /boot/efi

$ mkdir -pv /boot/efi/EFI/ubuntu/

$ cp -uv /boot/vmlinuz-* /boot/initrd.img-* /boot/efi/EFI/ubuntu/
'/boot/vmlinuz-3.13.0-35-generic' -> '/boot/efi/EFI/ubuntu/vmlinuz-3.13.0-35-generic'
'/boot/initrd.img-3.13.0-35-generic' -> '/boot/efi/EFI/ubuntu/initrd.img-3.13.0-35-generic'

2. Change the kernel file name

Shorten the kernel file name by removing -generic because there seems to be a 39 character length path limit and Rename kernel file(s) to end in .efi, this ensures compatibility with most systems

$ for f in /boot/efi/EFI/ubuntu/vmlinuz-*-generic; do mv -uv -- "$f" "${f//-generic/}.efi"; done
'/boot/efi/EFI/ubuntu/vmlinuz-3.13.0-35-generic' -> '/boot/efi/EFI/ubuntu/vmlinuz-3.13.0-35-generic.efi'`

^{The above name kernel file name shortening is not enough for a dpkg installed mainline kernel, because for example /EFI/ubuntu/vmlinuz-3.16.0-031600rc6.efi without -generic is still 40 characters long.}

3. Add new entry to EFI boot menu

Replace 3.13.0-35 in this example with your specific kernel version

$ kv=3.13.0-35;efibootmgr -c -p 3 -L $kv -l \EFI\ubuntu\vmlinuz-$kv.efi -u root=/dev/sda1 initrd=\\EFI\\ubuntu\\initrd.img-$kv-generic ro rootfstype=ext4 debug ignore_loglevel libata.force=dump_id crashkernel=384M-:128M

This new boot menu entry will become your default new boot choice.

^{You might not need the extra debugging parameters debug, ignore_loglevel, libata.force=dump_id and crashkernel=384M-:128M. Initrd must be present, otherwise boot hangs at "Switched to clocksource tsc." because the root device sda1 cannot be opened.}