Results 1 to 2 of 2

Thread: Some Things I Found

  1. #1
    Join Date
    Dec 2008
    Location
    Montana, USA
    Posts
    550

    Default Some Things I Found

    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

    Code:
    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
    Code:
    Asus-990FX:~ # efibootmgr -c -l \\EFI\\opensuse\\grubx64.efi -LopenSUSE
    You can verify that the entry has been correctly made by running
    Code:
    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/...+specification
    Microsoft's site: http://technet.microsoft.com/en-us/l.../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. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,197
    Blog Entries
    3

    Default Re: Some Things I Found

    Quote Originally Posted by montana_suse_user View Post
    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.
    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:

    Code:
    # 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.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •