Not booting - missing mmx64.efi

[spirulin]

Prerequisites

• [x] I have searched open and closed issues for duplicates.

Describe the bug

I can't even boot because mmx64.efi is missing. This is the error I was getting right after my Acer logo and the laptop was shutting down:

Failed to open \EFI\BOOT\mmx64.efi - Not Found

Failed to load image \EFI\BOOT\mmx64.efi: Not Found

Failed to start MokManager: Not Found

Something has gone seriously wrong: import_mok_state() failed : Not Found

To Reproduce

Steps to reproduce the behavior: Burn the the latest elementary OS 5.1.2 to USB and try to boot. This maybe on Acer laptop with UEFI boot so not sure if it will happen to everyone.

Expected behavior

It should boot with no problems.

Platform Information

• [ ] I'm using the latest version from git that I've manually compiled
• [x] I'm using the latest released stable version

Additional context

I was able to fix it myself: In the USB: Copied the grubx64.efi from /boot/efi folder to another folder, renamed it to mmx64.efi and put it back in the folder. So now I have grubx64.efi and mmx64.efi in the EFI folder on my USB drive. And it boots with no problems.

It would be nice if you add it to the next iso so new people coming to your OS don't have to deal with this.

Had no problem Booting Ubuntu 19.10 because it has both grubx64.efi and mmx64.efi in the EFI folder when burned to USB.

[kgrubb]

Looks like this is probably related to the issues here: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1798171

From what I can tell, the mmx64.efi file is MOKManager, a utility for signing bootloaders with a Machine Owner Key.

It looks like copying the grubx64.efi, while effective, is more or less a "hacky" solution, because it circumvents the MOKManager, making the computer boot directly into GRUB.

I'll try and find out how this was resolved and how we can get this working in our build scripting!

[spirulin]

Thank you. I have no idea how it actually makes it work but it works. I hope you can fix it fast, maybe looking at how Ubuntu 19.10 did it? As I said I had no problem when I tried to boot it. They have both in the EFI folder.

[hanaral]

That's probably because elementary's boot mechanism doesn't support the non-secure grub, which would explain why Ubuntu has it

[spirulin]

Hey @kgrubb it was fixed on previous Iso and now I just downloaded it 2 hours ago the latest release and again the mmx64.efi is missing and can't install it. Can you report it so they can add the fix again? And if possible to update the iso?

[ReadChart]

I have the same problems, but I install the elementary os into my computer alongside the windows, after the update, I can't boot any longer..

[hanaral]

@BKDOnions Does the text on the screen say that it's missing mmx64.efi? Unless it's related, I assume windows messed with your elementary's bootloader, since it can do that sometimes when installed on the same drive.

[ReadChart]

@hanaral Maybe it wasn't windows? Cuz I ve tried to reinstall the elementary os, the problem still remains the same, I tried to install the ubuntu 20.04 pts, the problem fix, but I still wasn't able to boot the elementary os.

[ReadChart]

@hanaral my device is mibook air tm1613, BIOS version is a06, windows version is 2004 pro x64, with both secure boot and tpm enabled.

[ReadChart]

@hanaral Maybe it wasn't windows? Cuz I ve tried to reinstall the elementary os, the problem still remains the same, I tried to install the ubuntu 20.04 pts, the problem fix, but I still wasn't able to boot the elementary os.

20.04 *lts

[hanaral]

Are you able to boot in to elementary with secureboot and quickboot disabled?

[ReadChart]

Are you able to boot in to elementary with secureboot and quickboot disabled?

@hanaral Thats the problem, i cant disable secure boot without disabling uefi, idk if it's a bios problem or a windows 10 problem.

[ReadChart]

@hanaral but i did boot ubuntu 20.04 LTS on a same laptop with same bios conf and nothing terribly wrong happen

[hanaral]

On my ASRock motherboard I am able to do so, it's a little odd that you can't. Are you able to see if you can boot without UEFI?

[ReadChart]

it says "No bootable device found (or sth like that)", both win10 and elementary os can be found, it is so weird that i never met before, i wanna try another device to see if it is some device's problems

[o-alquimista]

I can reproduce this. I had to disable Secure Boot in order to boot the installation media via USB to install elementary 5.1.7. Does that mean I have to wait until elementary releases a new version with the post-BootHole signed bootloader? Perhaps only on elementary 6?

[ReadChart]

Disabling Secure Boot is always an option, but i need if for dual booting my windows 10

On Sun, Jan 10, 2021 at 12:44 PM Douglas Silva [email protected] wrote:

I can reproduce this. I had to disable Secure Boot in order to boot the installation media via USB to install elementary 5.1.7.

Things I've tried:

• Toggle Secure Boot in the BIOS to force the installation of the default keys, then try to boot with Secure Boot enabled.
• With elementary installed, I pulled all available updates and tried to boot again with Secure Boot enabled, but it failed with the same error.

I just came from Ubuntu 20.10 groovy, which can successfully boot with Secure Boot enabled.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elementary/os/issues/298#issuecomment-757414791, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFBQXKGKMTJ5K4JPQHAJYNDSZEWBNANCNFSM4KSHSPOQ .

[hanaral]

I can reproduce this. I had to disable Secure Boot in order to boot the installation media via USB to install elementary 5.1.7.

I'm pretty sure this is normal behaviour for secure boot, since it requires the bootloader to be signed by Microsoft AFAIK. It might be because of the 18.04 base that it does not have the newest signature.

Does that mean I have to wait until elementary releases a new version with the post-BootHole signed bootloader? Perhaps only on elementary 6?

elementary OS 5 just got its last update yesterday I think, so it probably will be on elementary 6 (I don't use secureboot).

[dharders]

Got bitten by this too. Using elementaryos-5.1-stable.20200814.iso

Tried copying and renaming mmx64.efi file. It no longer complained about missing files, just with the 0x1a Security Violation message.

[ReadChart]

Got bitten by this too. Using elementaryos-5.1-stable.20200814.iso

Tried copying and renaming mmx64.efi file. It no longer complained about missing files, just with the 0x1a Security Violation message.

I've no idea how to fix that, I gave up and switched to ubuntu 20.04 already, but I still want to know what exact the problem is if someone else can figure it out.

[hanaral]

Chances are the motherboard has something weird with its implementation of UEFI and isn't accepting something that isn't the exact up-to-date Micro$oft signed secureboot. Have you tried with the Odin Beta ISO?

[ReadChart]

@hanaral nope I'm haven't donated yet, I cannot access the beta version, I agree with ur theory that the motherboard has something weird because I have never get this error before on any other device.

[hanaral]

You should be able to download and test the open beta, it's available for free right now.

[jedihe]

I'm seeing a very similar problem on a Lenovo ThinkCentre M70q. Booting from the USB pendrive (eOS 5.1 20200814, prepared with Rufus 3.14p) is showing this error:

(Blue screen, center-aligned lines)

ERROR

Verification failed: (0x1A) Security Violation


[OK]

Pressing enter then gets these lines super-imposed on the blue-screen (from top-left, left aligned lines of text):

Failed to load image: Security Policy Violation
Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
start_image() returned Not Found

After lots of web searches and some reading of the excellent Arch wiki page on Secure Boot, I tried booting the Ubuntu 18.04.5-desktop-amd64 installer (same USB pendrive, using Rufus again), which booted just fine into the "Try Ubuntu" session. After this find, I backed-up the EFI dir from Ubuntu 18.04.5, imaged eOS 5.1 back onto the USB pendrive, then replaced the entire EFI dir with that from Ubuntu 18.04.5: I'm now able to boot into the "Try Elementary" session. I'm still undecided if it's a good idea to install from that, so I'd appreciate any comments regarding potential risks.

Two side notes:

• I also learned that putting the Lenovo UEFI firmware into "Setup mode" (which clears all installed keys) allowed booting with the standard EFI dir from eOS 5.1; I don't think that's a good idea, though, as it looks like "Setup mode" is meant for deploying custom Secure Boot keys (which requires proper knowledge to do in a correct manner, and the associated maintenance burden?).
• Checking the file properties for the two versions of grubx64.efi in a Win10 system, I see this:
  • Ubuntu 18.04.5: the "Digital Signature Details" shows that it is signed by "Canonical Ltd. Secure Boot Signing (2017)"; a short message below the title reads "The certificate in the signature cannot be verified.", and the Certificate itself has this message: "Windows does not have enough information to verify this certificate.".
  • eOS 5.1: it's signed by "PPA elementary-os os-patches", with a below-title message reading "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.". As for the certificate, it shows this message: "This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store.".

[jedihe]

I decided to try installing from the eOS USB with grubx64.efi from Ubuntu 18.04.5; the installation ran correctly, the MOK screen (enrolling the key so the UEFI firmware would let elementary to boot) also proceeded as expected (using as reference a tutorial from YouTube), but I found that the UEFI was still showing error 0x1A after a reboot to try starting elementaryOS proper.

I then recalled seeing a Win10 procedure to make the EFI partition visible:

• In cmd.exe, run "diskpart", then:
  • list volume
  • (find the EFI volume)
  • select volume FOUND-VOLUME-NUMBER-HERE
  • assign letter=x

Then make system directories visible:

• Open Windows Explorer
• Go to "File", "Change folder and search options", this opens the "Folder Options" dialog.
• Go to "View" tab.
• Disable "Hide protected operating system files".

Start task manager (Ctrl+Shit+Esc or Ctrl+Alt+Del), go to File > Run new task, click on "Browse...". Browse to the EFI partition, go to EFI/ubuntu, rename grubx64.efi, then copy grubx64.efi from Ubuntu 18.04.5.

This way, I managed to get the eOS installation booting properly 😄; Win10 still boots correctly. So, I achieved my goal: dual-boot (eOS 5.1, Win10), with Secure Boot enabled (in deployed mode).

Testing so far has been the bare minimum, but it seems to be working fine. I suggest reverting the EFI drive visibility in Win10 (I don't know how yet) and re-enabling the option to "Hide protected operating system files".

[qrnik]

Still happening on latest release 😞 (7.0-stable.20230129rc)