Some Things I Found

English Install/Boot/Login
1

I recently had some problems with the UEFI bios on my system and in the process, learned some things I thought I could share here. My system is an Asus system board with an AMI bios. I’m running openSUSE 13.1 (only), and had been since it came out. I had previously had some problems with dual boot (12.3/13.1) and had gotten some knowledge about UEFI here, especially from gogalthorp, but apparently I didn’t know as much as I thought.

The latest problem started when I did an update to the BIOS. When that process was complete, I was left with a non-bootable system. It seems during the process, that the update process overwrote the non-volatile portion of the bios where the location of the boot files are located. Asus tech support was absolutely no help as they were adamant that end users (including os manufacturers) were not allowed to write to the bios. So…

Here is what I learned:

In a UEFI system, the boot file is located in a fat formated partition, in a directory named EFI. Within that directory is another directory, and within that directory is the start up file. That second directory, and it’s file can be named anything. It is usually named so as to reference the start up system

The default file system is \EFI\BOOT\bootx64.efi where the x64 part of the name represents a 64 bit pc type of computer.
For an openSUSE system, the file system is \EFI\opensuse\grubx64.efi.

There is a location in the BIOS that holds that information. It is in the non-volatile ram portion of the BIOS and can (will) be written to by the installation program or, in my case, by the BIOS update system. The UEFI system will not go looking for boot files, it looks only for those files listed in non-volatile ram.

Here is what happened:

During the BIOS update, the boot location in non-volatile ram was overwritten with the default information. Thus, after the update, the computer could not find the file \EFI\BOOT\bootx64.efi as it did not exist, and therefore would not boot.

Here is what I did to fix it:

I booted a live DVD, opened Konsole, changed to the fat partition of the drive that contained the \EFI directory. I created a directory named BOOT. I copied \EFI\opensuse\grubx64.efi to \EFI\BOOT\bootx64.efi. Shut down, removed the DVD and brought the system up without problems. That got me up and running with my regular system, and would continue to work until I made a change to my installation.

To complete the fix, I opened Konsole (any terminal would work), became root, and ran

Asus-990FX:~ # efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0005,0003,0004
Boot0000* openSUSE
Boot0003* CD/DVD Drive 
Boot0004* Hard Drive 
Boot0005* UEFI OS

This lists, as you can see on my system, all the boot devices. They are numbered, but the numbers don’t seem to mean anything other than to the computer itself. The entry for Boot5 was the BootCurrent entry. I created and entry, Boot0000 openSUSE as number 0000 by running

Asus-990FX:~ # efibootmgr -c -l \\EFI\\opensuse\\grubx64.efi -LopenSUSE

You can verify that the entry has been correctly made by running

Asus-990FX:~ # hexdump -C /sys/firmware/efi/vars/Boot0000-*/data

You’ll see the entry with each letter separated with a “.”.
Use efibootmgr, or the BIOS itself, to change the sequence so that the system you wish to boot will be listed first in the order.

In conclusion:

I’m actually simply repeating things I found in many places. I do have some of the locations here, but not all. I found the specs for UEFI on
Intel’s site http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-boot-script-specification-v091.html?wapkw=efi+specification
Microsoft’s site: http://technet.microsoft.com/en-us/library/dn387088.aspx
Fedora’s site: http://fedoraproject.org/wiki/GRUB_2
and, as usual very helpful: openSUSE’s site: http://en.opensuse.org/openSUSE:UEFI#Secure_Boot. The person, or persons who created this document are to be commended!
And of course, the single most helpful and accurate place in the entire Linux community: This very forum.

I only hope that this page will help someone as I have been helped many times on this site.

Bart

2

It sounds as if you worked that out pretty well.

The non-volatile space is usually referred to as NVRAM. Apparently, your BIOS update erased NVRAM.

If that happens, the system should still be able to boot the hard drive using “\EFI\Boot\bootx64.efi” (as you mentioned). So the recovery step would be to get a suitable boot file there. That will get something booted, from which you can proceed.

It should also have been possible to boot the live Rescue CD into EFI mode, and repair from there.

The man pages for “efibootmgr” are reasonable, though a bit confusing.

If you have a system that came with Windows, then the default bootup in “\EFI\Boot\bootx64.efi” will be to Windows. If you do not have Windows, then I recommend copying the opensuse boot files there.

When booted to opensuse:


# cd /boot/efi/EFI/Boot
# cp -p ../opensuse/*  .
# if  -f shim.efi ] ; then mv shim.efi bootx64.efi ; else mv grubx64.efi bootx64.efi ; fi

I have not tested that “if” statement. I would suggest just moving (renaming) either “shim.efi” or “grubx64.efi” depending on what you have. The “shim.efi” is for secure-boot. The “grubx64.efi” will only work with secure-boot disabled.