How to diagnose and repair secure UEFI

English Install/Boot/Login
1

When I try to boot as usual, I see a red message that says that something about my bootloader or system has changed.
In other words, secure boot is doing its thing and catching some sort of unexpected change.

Before this happened: I installed something to a USB drive using UNetBootIn. When shutting down afterwards, I think that I might have observed my system powering off in an unusual manner. Either of these things may or may not have anything to do with the fact that my bootloader was modified.

Question 1: The message mentions a lot of possibilities - how can I diagnose exactly what is triggering it?

Question 2: How can I repair the bootloader?

Additional background:

The first thing that I did was to follow Repair MBR After Windows Install using recovery mode in the OpenSUSE installer, but it did not work because it assumes a standard bootloader, not UEFI (I discovered that this was the reason the instructions didn’t work from a Stack Overflow question about a similar problem in Ubuntu). That page should definitely include instructions for UEFI, or mention that it isn’t relevant for UEFI.

The second thing I did was to try booting my system using the non-secure boot entry. This worked. That said, I want to repair the bootloader so that I can use secure again and catch any future problems that may be more serious.

The third thing that I tried, after reading OpenSUSE cannot boot after BIOS update - solved, was to use the upgrade option from the installer. It mentioned that the medium was not compatible with the installed system (fine, I can just rollback with Snapper afterwards). I didn’t follow-through with the installation, however, because it indicated that the bootloader was to be installed “into / partition”, which seemed incorrect to me (shouldn’t it be installed into the FAT /boot/UEFI partition?)

Thanks in advance for any advice on what to do in this scenario.

2

Well sounds like you are trying to mix the old MBR boot with the new EFI boot. These thing do not mix well.

You must boot the installer in EFI mode to do a EFI install. If booted in legacy it defaults to MBR install. The boot loader should be grub2-efi not just grub2. The efi boot partition must be mounted at /boot/efi. If the above is not correct things will not workout. Note they should default correct if the installer is booted in EFI mode.

Your messing with MBR boot when you tried to repair it may have confused things.

3

I see, it’s useful to know that the bootloader chosen for the installer is the determining factor for which type of bootloader the installer will offer to install. I’m fairly confident that I booted it via MBR.

I’d be surprised if my earlier attempt to run grub2-install actually made any changes to the hard drive, given the error message, and the fact that there’s another good explanation as to why the installer offered to install the bootloader to / (though that still seems somewhat strange, since / is not the first partition on the hard drive).

At the very least for the sake of curiosity, I’d love to get a more detailed diagnostic from the secure loader.

Is there an EFI equivalent for grub2-install? It seems to me like it should be as simple as copying the EFI files from the installer onto the FAT partition, but I don’t know for sure which files are the right ones, or even if they are copied verbatim or are somewhat customized.

4

Still confused If you Want to boot EFI you install in EFI mode If you want MBR you boot in legacy. EFI is more then just a efi boot partition the entry in the UEFI flash must be correct also. Show efibootmgr

5

To clarify, on a UEFI OpenSUSE installation, I received a red message on boot that says “Secure Boot Violation: The system found unauthorized changes on the firmware, operating system, or UEFI drivers”. My two questions are:

  1. How can I discover exactly what condition triggered this message (Did a checksum fail? Which file?).
  2. How can I prevent the message from appearing? In other words, how can I make OpenSUSE overwrite the UEFI bootloader (or whatever other part is failing the integrity check) without reinstalling the entire system or breaking the system by performing an “upgrade” from the installer?

Any mention of MBR, to clear your confusion, was just context regarding the troubleshooting steps I attempted up until this point: for the sake of not omitting any potentially relevant information about my particular situation, and for the sake of preventing others who read this from (unnecessarily) attempting those same steps.

Surprising to me, it seems that booting and updating my system has fixed the problem. I can boot without receiving the message, and it appears to me that I’m still booting securely. Regardless, I think it would be good to have the answers for those two questions out on the internet for others to find when they run into a Secure Boot Violation on OpenSUSE.

The output of efibootmgr --verbose is as follows


BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0004,0005,0006,0007,0008,0009
Boot0000* opensuse-secureboot   HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)/File(\EFI\OPENSUSE\SHIM.EFI)
Boot0001* Hard Drive    BBS(HD,,0x0)..GO..NO.......O.M.4.-.C.T.2.5.6.M.4.S.S.D.2.................>..Gd-.;.A..MQ..L.0.0.0.0.0.0.0.0.1.1.8.1.3.0.6.0.5.D.3.3........BO..NO........O.S.A.M.S.U.N.G. .H.N.-.M.1.0.1.M.B.B.................>..Gd-.;.A..MQ..L.2.S.8.R.9.J.B.B.2.6.6.3.3.1. . . . . . ........BO..NO........O.C.r.u.c.i.a.l._.C.T.5.2.5.M.X.3.0.0.S.S.D.4.................>..Gd-.;.A..MQ..L. . . . . . . . .7.1.0.1.6.1.C.1.1.4.A.2........BO..NO........O.S.A.M.S.U.N.G. .H.D.5.0.2.H.J.................>..Gd-.;.A..MQ..L.2.S.B.0.9.J.S.0.0.8.6.7.8.7. . . . . . ........BO
Boot0004* opensuse      PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO
Boot0005* UEFI OS       PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO
Boot0006* opensuse      PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO
Boot0007* UEFI OS       PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO
Boot0008* opensuse      PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO
Boot0009* UEFI OS       PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)/HD(1,GPT,7b7e1dd3-866b-463e-90c0-2f09434d02da,0x800,0x4e000)..BO

running efibootmgr --remove-dups did not remove the entries which appear to be duplicates.

6

If you booted in EFI mode, then:

grub2-install --target=x86_64-efi

should work, though for secure-boot you need to follow that with

shim-install

Those commands need to be run by root (or via “sudo”).

7

If booted in EFI mode, no --target is needed, simple “grub2-install” is enough. It autodetects current platform.

though for secure-boot you need to follow that with

shim-install

No, it should not “be followed”, it should “be used instead”. “shim-install” does something different and does not use image created and installed by grub2-install.

For years I tell people to use “update-bootlloader” exactly to avoid all of “and if you are using this, you should do this, and if you using that, you should do that”. update-bootloader did not change when shim-install was introduced and it will continue to work even if something else will replace grub2. Assuming YaST configuration is correct of course … but we have to assume something​.