Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Repair a broken UEFI/GRUB2/openSUSE boot scenario

  1. #1
    Join Date
    Sep 2014
    Location
    Germany
    Posts
    284

    Default Repair a broken UEFI/GRUB2/openSUSE boot scenario

    I would like to share the line of action i use to investigate and (hopefully) repair broken UEFI boot scenarios (It may even serve to manually install GRUB2 for UEFI boot).

    Please be aware:

    • I use openSUSE 42.3 on UEFI-based machines with GRUB2 as bootloader.
    • "secureboot" is always disabled.
    • The UEFI is set to boot in UEFI-mode (no "Compatibility Support Mode (CSM)" aka "Legacy mode" or "MBR mode").
    • All disks have a GPT partition scheme and ext4 as file system.
    • RAID or LVM are not used.
    • There are no separat boot partition or any encrypted system/swap partition(s).


    If your setup is different the following might probably be of no use to you.

    The UEFI specification offers some freedom to vendors on how to implement an UEFI (and there even might be faulty UEFI implementations). So some UEFI specific stuff mentioned below may not work with your UEFI (it might be worth to check your motherboard vendors website for the latest UEFI version).

    Before you start:
    Your system may become completely unusable if you follow the guidelines below! Make sure you have a working and up to date backup of all your data.

    When your system does not boot any more the openSUSE-Installation-media (DVD/USB stick) can be used to repair the broken boot scenario:

    1. Make sure your UEFI is set up to boot in UEFI-mode.
    2. Make sure "secureboot" and "FastBoot" are disabled in your UEFI.
    3. Boot the openSUSE installation media [01] (DVD/USB stick).
      Make sure it really started in UEFI mode; i.e at the bottom of the very first screen there is NO options menu (F1, F2, ...) displayed. If there is an options menu the media booted in CSM (legacy mode / MBR mode).
    4. Select "More ..." and then "Rescue system". This will give you a working command-line-only system.
    5. Log in as "root" (no password needed).
    6. It's high time to make sure you have a backup of your data.

    7. Code:
      # od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data
      0
      #
      This will check the "secureboot"-status of your UEFI. If the result is not equal "0" then you still need to disable "secureboot" in your UEFI (or your UEFI returns invalid values). In case the command fails completely make sure you booted in UEFI-mode.
    8. The UEFI spec allows for more than one UEFI system partition. If you plan to (re)install GRUB2 you can use any EFI system partition available on your system (as long as it has enough free space to hold the openSUSE GRUB2 bootloader files) or - if you have some spare disk space available (min. 128 MB; better 500 MB) - you may even create a new EFI system partition (Type 0xEF00; file system FAT32).
    9. Code:
      # blkid | grep EFI
      Will help you to find the EFI system partition(s) available on your system. If you want to use a specific one (e.g. the one that was used in a once working boot scenario) and are not sure about which it is you can inspect each in order to determine which is the one you are looking for.
    10. Mount the EFI system partitions one by one. Use "blkid" to get the proper value(s) for "sdxz".
      Code:
      # mount /dev/sdxz /mnt
      If you already had a working boot scenario you can now look for a file "/mnt/efi/opensuse/grubx64.efi". If you can't find that file check the other EFI system partitions. If there aren't any other EFI system partitions you need to reinstall GRUB2 as described later on.
    11. "grubx64.efi" is the booatloader which needs to know where to find the system it is supposed to boot. This knowledge will either be build into "grubx64.efi" when it gets installed or there is a file "/mnt/efi/opensuse/grub.cfg".
      Code:
      # cat /mnt/efi/opensuse/grub.cfg
      search --fs-uuid --set=root a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6
      set prefix=(${root})/boot/grub2
      configfile $prefix/grub.cfg
      Make sure that "a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6" fits the UUID of the partition which hosts the root file system of the system you want to boot. Use "blkid" to get the UUID of your openSUSE root file system partition.

      If "grubx64.efi" was build to boot from a partition that no longer exists (or you just don't want to boot from any longer) then you need to reinstall GRUB2 as described later on.
    12. Code:
      # umount /mnt
      Finaly unmount the EFI system partition you inspected.
    13. Setup a changeroot environment.
      Code:
      # mount /dev/sdxy /mnt
      Mounts your openSUSE root file system partition. Use "blkid" to get the proper value for "sdxy".
      Code:
      # mount /dev/sdxz /mnt/boot/efi
      Mounts your EFI system partition. Use "blkid" to get the proper value for "sdxz".
      Code:
      # mount -o bind /dev /mnt/dev
      # mount -o bind /run /mnt/run
      # mount -o bind /sys /mnt/sys
      # mount -o bind /proc /mnt/proc
      # chroot /mnt
      Completes and starts the changeroot environment. From here on all actions take place in the already installed openSUSE system.
    14. Code:
      # zypper se -si grub2
      Check that GRUB2 is installed (that should be the case if there once was a working boot scenario). If no grub2-packages are listed GRUB2 needs to be installed (a working internet connection is needed for this!)
      Code:
      # zypper in grub2
    15. Code:
      # zypper up grub2
      If GRUB2 is already installed this makes sure you have the latest version of the grub2-packages (a working internet connection is needed for this!)
    16. Check the GRUB2 configuration file
      Code:
      # cat /etc/default/grub | grep "GRUB_USE_LINUXEFI"
      GRUB_USE_LINUXEFI="true"
      # cat /etc/default/grub | grep "GRUB_DISABLE_OS_PROBER"
      GRUB_DISABLE_OS_PROBER="false"
      If you do not see the results shown above use an editor (e.g. vi) to change the file "/etc/default/grub"

      You may also want to check the "GRUB_CMDLINE_LINUX_DEFAULT=" and "GRUB_CMDLINE_LINUX=" settings in that file. If there is something like "resume=/dev/disk/by-uuid/a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6" make sure that "/dev/disk/by-uuid/a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6" really exists and is the partition you want to use for resume.
    17. Code:
      # cat /etc/fstab | grep boot
      UUID=1234-ABCD   /boot/efi  vfat umask=0002,utf8=true  0  0
      Make sure that "1234-ABCD" fits the UUID of the EFI system partition you want to use. If there is no entry with "/boot/efi" the EFI system partition will not be mounted at system startup so you need to add an entry for the EFI system partition to "/etc/fstab".
    18. Code:
      # efibootmgr -v
      BootCurrent: 0003
      Timeout: 2 seconds
      BootOrder: 0003,0005,0001,0000
      Boot0000* Win...
      Boot0003* opensuse    HD(5,GPT,a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6,0xacbe800,0x200000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
      Boot0005* Ubu...
      This will check the UEFIs NVRAM. If there is no entry (Bootnnnn) for opensuse you need to create one (replace "sdx" with the device that carries the EFI system partition you want to use; in "--part n" replace "n" with the number of this EFI system partition)
      Code:
      # efibootmgr --create --disk /dev/sdx --part n --label "openSUSE" --loader \\EFI\\opensuse\\grubx64.efi
      Code:
      # blkid
      will help you to find the correct value for "/dev/sdx" and
      Code:
      # gdisk -l /dev/sdx
      will help you to determine "n"
    19. Code:
      # efibootmgr -b 0004 -B
      Changes the bootsequence stored in the UEFIs NVRAM (e.g. make entry "Boot0004" to be the first one in the "BootOrder")
    20. If you could not fix the problem so far you can reinstall GRUB2
      Code:
      # grub2-install --target=x86_64-efi
      and create a new GRUB2 boot menu
      Code:
      # grub2-mkconfig -o /boot/grub2/grub.cfg
    21. Leave the changeroot environment
      Code:
      # exit
    22. Reboot your system
      Code:
      # init 6


    Hopefully your system will boot again.

    Last but not least a few things worth knowing about UEFI:


    • EFI firmware contains knowledge about the partition structure of various devices and can understand legacy MBR, GPT, and “El Torito”. An EFI system partition supports backward compatibility with legacy systems.
    • The file system (for EFI system partitions) supported by EFI is based on the FAT file system and includes support for long file names. The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. EFI encompasses the use of FAT32 for a EFI system partition and FAT12 or FAT16 for removable media.
    • FAT defines that all files in a directory must have a unique name and unique is defined as a case insensitive match.
    • An EFI system partition that is present on a hard disk must contain in the root directory a directory named EFI. All OS loaders and applications will be stored in subdirectories below EFI. The choice of the subdirectory name is up to the vendor, but all vendors must pick names that do not collide with any other vendor’s subdirectory name. This applies to system manufacturers, operating system vendors, BIOS vendors, and third party tool vendors, or any other vendor that wishes to install files on an EFI system partition. There must also only be one executable EFI image for each supported processor architecture in each vendor subdirectory. If more than one executable EFI image is present, then the boot behavior for the system will not be deterministic. There may also be an optional vendor subdirectory called BOOT. This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost.
    • The UEFI boot sequence looks like this:


    1. The boot order list (shown as "BootOrder" by "efibootmgr -v") is read from the UEFI NVRAM. It holds a list of NVRAM variables (shown as "Boot0000" to "BootFFFF" by "efibootmgr -v") that contain information about what is to be booted. Modifications to this variable are only guaranteed to take effect after the next platform reset.
    2. Each NVRAM variable ("Boot0000" to "BootFFFF") contains a pointer to the hardware device and to a file on that hardware device that contains the UEFI image to be loaded. Also it defines a name for the boot option that can be displayed to a user. Furthermore the variable might contain paths to the OS partition and directory along with other configuration specific directories. The UEFI will try to boot the "Bootnnnn" entries in the order given by "BootOrder" until a "Bootnnnn" can be booted successfully. If no "Bootnnnn" could be booted successfully (or no "Bootnnnn" was defined) then the UEFI will try to boot /EFI/BOOT/BOOT.efi".


    Some helpful links:

    [01] openSUSE install media
    http://download.opensuse.org/distrib...E-current/iso/
    [02] GRUB2 Manual
    https://www.gnu.org/software/grub/manual/grub/
    [03] UEFI specification
    http://www.uefi.org/specifications

    Regards

    susejunky

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    10,842
    Blog Entries
    3

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Your advice is mostly good. But I'll add some comments.

    I have been leaving "secure-boot" enabled. OpenSUSE can handle that without a problem, though that was broken when first installing Leap 42.1. But it is back to working well. However, some other linux versions do not support secure-boot.

    As far as I know, openSUSE, Ubuntu and Fedora are the main distributions that do support secure-boot. Linux Mint mostly supports it, because it is based on Ubuntu.

    On one of my computers, there are two UEFI boot entries for "ubuntu". So it might be false that system names have to be unique.

    You mention "fastboot" (and suggest turning if off). I agree that it should be turned off. But "fastboot" usually refers to something in Windows, rather than something in the UEFI firmware.
    opensuse Leap 15.0; KDE Plasma 5;
    opensuse tumbleweed; KDE Plasma 5 (test system);

  3. #3
    Join Date
    Sep 2014
    Location
    Germany
    Posts
    284

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Quote Originally Posted by nrickert View Post
    ... I have been leaving "secure-boot" enabled. OpenSUSE can handle that without a problem, though that was broken when first installing Leap 42.1. But it is back to working well. However, some other linux versions do not support secure-boot.

    As far as I know, openSUSE, Ubuntu and Fedora are the main distributions that do support secure-boot. Linux Mint mostly supports it, because it is based on Ubuntu.
    Thank you very much for your feedback.

    I'm aware that openSUSE can handle secure boot but i never tried it. However at the moment i have no idea how to manually install (using the Rescue System and no yast) shim/MokManager.

    Please, could you provide a brief description? I'm very intrested to learn how to do it (and i would like to enhance my checklist).

    Quote Originally Posted by nrickert View Post
    ... On one of my computers, there are two UEFI boot entries for "ubuntu". So it might be false that system names have to be unique.
    The descriptions at the very bottom of my post are taken from the UEFI specification (Chapter 13.3.1.3). As far as i understood only the directories below "/EFI" must have unique names. The names in the NVRAM boot entries ("Boot0000"-"BootFFFF") have not to be unique. But i'm no native english speaker so i can be wrong.

    Quote Originally Posted by nrickert View Post
    ... You mention "fastboot" (and suggest turning if off). I agree that it should be turned off. But "fastboot" usually refers to something in Windows, rather than something in the UEFI firmware.
    The UEFI of my desktop motherboard (MSI Z97 Gaming 3) does have an option "FastBoot". Because i thought it to be "the" FastBoot option i have turned it of. But probably that was not necessary?

    Regards

    susejunky

  4. #4
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    10,842
    Blog Entries
    3

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Quote Originally Posted by susejunky View Post
    Please, could you provide a brief description?
    Okay. I'll do a separate reply about secure-boot (following this reply).

    As far as i understood only the directories below "/EFI" must have unique names. The names in the NVRAM boot entries ("Boot0000"-"BootFFFF") have not to be unique.
    That's probably correct. The file system (FAT) already requires unique directory names. And it appears to be allowable (but confusing) to have two UEFI boot entries with the same name.

    The UEFI of my desktop motherboard (MSI Z97 Gaming 3) does have an option "FastBoot".
    Fair enough. The term "fastboot" in ambiguous. I have seen a "fastboot" BIOS option going back many years. Windows introduced a "fastboot" option for Win 8 and later, and made that the default.

    It is the "fastboot" of Windows that is the main concern to linux users. It leaves the Windows file system in an unstable state. So that windows "fastboot" is best disabled.

    The "fastboot" in the BIOS or UEFI firmware is a different thing. Normally, when the computer boots, it goes through POST (Power On Self Test). The BIOS "fastboot" shortens this POST. It does a quick memory check and skips the more thorough memory check. It might skip initializing USB devices, unless you are booting from a USB. Unless you are having hardware issues, it is probably okay to leave the BIOS "fastboot" turned on.
    opensuse Leap 15.0; KDE Plasma 5;
    opensuse tumbleweed; KDE Plasma 5 (test system);

  5. #5
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    10,842
    Blog Entries
    3

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Notes on secure-boot in UEFI systems.

    Most UEFI computers come with secure-boot. You can enable or disable that in the BIOS.

    What is secure-boot?

    With secure-boot, your UEFI firmware comes with a certificate (public-key) for checking signatures. Usually, the public key is from Microsoft, though it could be from your computer vendor. The bare computer might come without a key, but that key is installed when the first software is installed.

    The idea is to check everything. So the boot files are supposed to all be digitally signed. And then the signature is checked. If the signature check fails, the system refused to boot.

    However, it is not that simple. Since the check is for a Microsoft signature, the files have to be digitally signed at the factory. However, some of the files needed for booting are specific to your computer, so cannot be signed. In Windows, the BCD database (boot configuration data) is not signed. With linux/grub, the grub menu is not signed, and the "initrd" file is not signed. So the security checks of secure-boot are not complete. Secure-boot gives some limited protection, but it is not complete protection.

    How does linux handle secure-boot?

    For most linux distros, linux needs you to disable secure-boot in the UEFI firmware (BIOS). Some distros do support secure-boot, and openSUSE is one of those.

    When you boot your computer, the UEFI firmware runs the system loader. For openSUSE with secure-boot support, that system loader is the file "shim.efi". This file is signed by Microsoft, so it passes the secure-boot test.

    The file "shim.efi" contains a public key for verifying signatures made by openSUSE (instead of by Microsoft). So "shim.efi" check other boot files with that opensuse signature. The first such file is "grub.efi", which contains the grub boot code. This file is signed by openSUSE. The grub boot code next loads the kernel at what is called the "EFI stub". And it asks "shim.efi" to verify the signature on the kernel. Thereafter, booting proceeds as it would without secure-boot.

    Installing secure-boot support

    On a UEFI box, the default for openSUSE is to install secure-boot support. During install, if you go to the booting section of the installer, there is a check box for "secure-boot". And that is checked by default, though you can turn it off.

    It should be harmless to install secure-boot support. If you disable secure-boot in your BIOS, it should still work. The effect of disable secure-boot in the BIOS is that the digital signatures are not checked. But everything else should still work the same.

    If you did not originally install secure-boot support (you unchecked that box during install), then it is fairly easy to install later. If the system is already up and running, just use Yast bootloader, and check that box. If you are running the rescue-system, then you must mount disks as needed for going into a "chroot" session. Then, in that "chroot" session, you will need to run
    Code:
    shim-install
    Note that you must boot into UEFI mode to do this. You can successfully run "shim-install" even if secure-boot is disabled. But you cannot run it if you booted into MBR mode instead of UEFI mode. (Well, you can run it, but it will give an error).

    Whether running the rescue system, or using Yast, I suggest that you check "/etc/default/grub" to make sure that it contains the line:
    Code:
    GRUB_USE_LINUXEFI="true"
    Otherwise secure-boot won't work.

    And if you had to change that, then run
    Code:
    grub2-mkconfig -o /boot/grub2/grub.cfg
    If you are using the rescue system, then run that from the "chroot" session.

    I should note that if you are trying to boot a 32-bit kernel, that won't work. So don't even try using secure-boot if you need to be able to boot a 32-bit kernel.

    Is secure-boot worth the trouble?

    That's for you to decide. I normally leave it turned on. But, in all honesty, I don't think it adds any useful security. I leave it turned on as a way of testing whether it works (and reporting bugs when it doesn't work).
    opensuse Leap 15.0; KDE Plasma 5;
    opensuse tumbleweed; KDE Plasma 5 (test system);

  6. #6
    Join Date
    Sep 2014
    Location
    Germany
    Posts
    284

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Quote Originally Posted by nrickert View Post
    Okay. I'll do a separate reply about secure-boot (following this reply). ...
    Thank you very much for your description on "secureboot"! I will definitely give it a try.

    All i had found on "secureboot" so far looked very complicated to me (generating keys and installing them in the UEFI and the like). Because i was afraid to mess up my system i never tried that.

    Regards

    susejunky

  7. #7
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,246

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    IMHO Secure boot is security theater. If a bad actor can modify the boot stack then they already own the machine. At best it is marginal protection but the protection is to brick the machine if things do not add up. At least you have to clean and reinstall the complete boot stack and all certificates.

  8. #8
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    10,842
    Blog Entries
    3

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Quote Originally Posted by susejunky View Post
    All i had found on "secureboot" so far looked very complicated to me (generating keys and installing them in the UEFI and the like).
    That's only needed if you want to sign a kernel yourself -- only needed if you are compiling kernels yourself.
    opensuse Leap 15.0; KDE Plasma 5;
    opensuse tumbleweed; KDE Plasma 5 (test system);

  9. #9
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    10,842
    Blog Entries
    3

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    Quote Originally Posted by gogalthorp View Post
    IMHO Secure boot is security theater.
    For an inexperience linux user, whose new computer has secure-boot enabled, the openSUSE support means that he can install openSUSE without having to mess with UEFI settings.
    opensuse Leap 15.0; KDE Plasma 5;
    opensuse tumbleweed; KDE Plasma 5 (test system);

  10. #10
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,246

    Default Re: Repair a broken UEFI/GRUB2/openSUSE boot scenario

    MY point is the whole concept is smoke an mirrors and saves you from very very few things. Just something forced on us by Microsoft of dubious value

Page 1 of 2 12 LastLast

Posting Permissions

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