[Solved] Help! “Failed to open \EFI\BOOT\mmx64.efi - Not Found”

[AtumRa]

I'm having a very serious problem with Linux, where when in UEFI mode with secure boot turned on, if I do a very simple thing, it will break my BIOS and lock me away from ever installing linux in my computer ever again.
Okay, so what is the problem, imagine this situation, I have secure boot on and UEFI mode for installing Linux mint, then I start the installation menu, I check the "install multimedia codecs" checkbox and I choose a password for when I reboot linux in order to enroll the MOK and have my very first boot in the newly formatted Linux PC. Okay, but now check this out: During installation I pass the "install multimedia codecs checkbox" and choose a password, then on the next step I give up on the installation and abort it. Then I turn off linux live USB the usual way, closing the installation and turning it off, then it asks me to remove the flash drive, I remove it and press enter, the computer turns off.
Okay, now I want to install Linux again, but now I'm really going to install it, when I boot linux live USB again, guess what? This message appears:
"Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image : Not Found
Failed to start MokManager: Not Found
Something has gone seriously wrong: import_mok_state() failed: Not Found."
I'll tell you what went seriously wrong, this broken installation! And no matter what I do on my BIOS, no matter if I disable secure boot or anything like that, no matter if I re-flash the BIOS, clear cmos, nothing fix it. Nothing! I'm stuck with this bug, and I can't find an answer on the internet neither on this forum! I don't know how come more people don't have this problem more often, maybe not many people give up on the installation middle process or something. Either way, this happened now with my new DELL laptop, and I'm unable to undo it. It also happened with my older desktop but I WAS able to fix it by doing a very low level bios update/recovery on it, and it stopped this error message. But doing a bios recovery on my DELL didn't fix this issue the same way it did to my desktop computer. Okay, so, it appears my BIOS is awaiting for some kind of linux MOK management tool and I'm unable to make it stop waiting for this thing. Do you guys have some kind of way for making it stop asking for it? Maybe a linux tool or something? Just to make my bios stop waiting for a MOK management? So I can restart the instalaltion process as usual?

[Reddog1]

Is this a dual boot with Windows? Windows Fast Boot must be turned off in Windows Settings or some necessary items won't be available at boot.

Did you try booting the installer in Legacy mode?

At boot, with the usb installer, press F12 and see if you have an option for "Legacy". Some Dells will boot into legacy mode this way, and allow you to install in legacy mode. You might have a Legacy (or CSM) setting in the uefi. If single-booting you won't notice a difference between uefi and mbr mode.

Mok is stored in NVRAM, not in the uefi, so a uefi/bios update wouldn't help. It appears from the 'path', that the installer never got the mok manager (mmx64.efi) put into the \EFI\BOOT\, but the signature may have been written to NVRAM. Dell support could possibly help you clear it.

mmx64.efi points to grubx64.efi, which probably isn't installed, either.

Did you try booting with a different usb? Maybe use LMDE6, which is Debian based Mint, and has a different mok and a different installer.

Never install linux with Secure Boot enabled (and most linux installers will choke on it, anyway). Install with it Disabled, and after install reboot to the uefi and then turn it back on. Better yet, never turn it back on. Secure Boot is for Windows, and there aren't any advantages for linux, even if ubuntu has been adjusted to use it.

[AtumRa]

Hi, and thanks for the reply and all the information you gave me.

For those having the same problem I manage to overcome it by doing this:
I putted the Linux Live USB on my other computer, went to the ¨\EFI\BOOT\¨ folder inside the flash drive and copied the ¨grubx64.efi¨ file to my desktop, renamed it to ¨mmx64.efi¨ and putted it back on ¨\EFI\BOOT\¨. After doing that I went back to my Dell notebook and booted it through UEFI USB, I now got the following error: ¨error: shim_lock protocol not found.¨. I then proceeded to my BIOS and disabled Secure Boot, and booted it through UEFI USB again. Now it worked, I proceeded to the normal Linux Mint installation and everything installed as usual. After turning on the notebook again, and seeing that Linux was correctly running at its internal drive, I turned off the notebook, went into its BIOS again and turned Secure Boot back on. After rebooting it, it finally prompt me the Enroll MOK blue screen, and I could properly enroll the MOK with the password I choose on the first installation (the one that started all this mess), and it finally resolved this problem definitely. The BIOS or NVRAM or whatever was no longer waiting for this MOK to be enrolled again. Now if I ever reinstall Linux Mint in UEFI mode with Secure Boot on, this error would not show up again, unless I did what I did the first time I caused this problem, which was to give up the installation after the screen that asks me if I want to install the multimedia codecs or not and to choose a password to enroll the MOK.

I think this is an issue with the Linux installation that should be reviewed, maybe the installer shouldn't ask for the NVRAM to enroll the MOK until after the installation process is complete, at the reboot part.

And Reddog1, not every newer notebook supports legacy mode anymore, each is the case of my brand new Dell notebook. Also I wasn't with dual boot with Windows, the notebook came with Ubuntu, I just formatted it and put Linux Mint on it. Funnily enough the notebook came with Secure Boot on, even if being a Linux laptop. The fault of the error was entirely on the installer side, but I will follow your advice and always turn off Secure Boot before installing Linux on any machine.

[Jo-con-Ël]

Thank you for sharing your experience.

As per related threads, it is known this happens with certain firmware/settings (secure boot) when installing with Linux Mint Live installation media created with certain tools as Rufus if using default iso file writting method (not DD, iso disk image writting, or dd based tools as recommended by Mint). Maybe that is why it is not commented on Release Notes (whatever Linux Mint version you installed). Other issues with Rufus and LM 21.2 and 21.3 are commented on github and Mint blog and now they are solved on Rufus 4.4.

You didn't mentioned that tool and it is important also considering the workaround to solved that problem (i.e. renaming grubx64.efi file inside Linux Mint Live) couldn't be done if created LM live with other tools as Balena-Etcher(recommend by Mint on installation guide in case of Windows, Mac OS, or other Linux distributions).

[AtumRa]

Hello there!

Okay so, the Linux version that I installed was Linux Mint 21.3 Cinnamon Edition (non edge).
The software used to create the bootable media was balena Etcher Portable version 1.18.11.
I know I'm not writing the full specs here, but my Dell is a Inspiron 15 3520 with a 12th core Intel i5.
I think writing the full specs is irrelevant as I also had this same exact issue with my Gigabyte Z97X Gaming 7 motherboard from 2014.
And btw, in the case of my older PC, I used Rufus 4.4 portable (yes, the latest one by the time I'm writing this text), and it still gave me this problem when exiting Linux Mint mid installation with secure boot on and opting to install the multimedia codecs and setting a enroll mok password.

Idk if it's in there already, but maybe this issue, and solution, should be mentioned in the notes as for the case people stop installing linux mid installation when with secure boot on and opting to install multimedia codecs with enroll mok password. And I admit that I did try installing linux with secure boot on, something you guys recommend turning off before installation, and I can see why now, it really really can screw things up. But I think this is easily avoidable and should be reviewed as it can turn the life of more inexperienced users like me upside down and super frustrating when installing linux on "newer" hardware.

[grimer]

For those having the same problem I manage to overcome it by doing this:
I putted the Linux Live USB on my other computer, went to the ¨\EFI\BOOT\¨ folder inside the flash drive and copied the ¨grubx64.efi¨ file to my desktop, renamed it to ¨mmx64.efi¨ and putted it back on ¨\EFI\BOOT\¨. After doing that I went back to my Dell notebook and booted it through UEFI USB, I now got the following error: ¨error: shim_lock protocol not found.¨.

Thank you so much for sharing this solution. I honestly couldn't work out what was wrong.

prompt me the Enroll MOK blue screen, and I could properly enroll the MOK with the password I choose on the first installation (the one that started all this mess)

I installed Linux Mint with Secure Boot already enabled.

• I did your grubx64.efi fix.

• Rebooted and chose to boot from USB.

• I received the error: shim_lock protocol not found error.

• I can't remember exactly what happened next, but it took me into a blue screen and I had the option of selecting 'continue / enrol'.

• My password from the aborted install was accepted and I then booted into the Live USB.

• I installed Linux Mint with Secure Boot already enabled.

Everything is now working perfectly.

I think this is an issue with the Linux installation that should be reviewed, maybe the installer shouldn't ask for the NVRAM to enroll the MOK until after the installation process is complete, at the reboot part.

I had also backed out of the Live USB installation menu and it broke my ability to boot a Live USB. I completely agree that this needs to be fixed with the codec question placed after the successful installation of Linux Mint and not at the start.

[monkeypeach]

Hello, apologies for possibly a very basic question -- when you say

I putted the Linux Live USB on my other computer, went to the ¨\EFI\BOOT\¨ folder inside the flash drive and copied the ¨grubx64.efi¨ file to my desktop, renamed it to ¨mmx64.efi¨ and putted it back on ¨\EFI\BOOT\¨.

Is the other computer running Linux and you plugged in the USB without booting from it?

I'm having the same issue after quitting partway through an install. Hoping to fix this without installing Linux on another computer first.

Thanks in advance!

[Heat]

I just had this same problem from backing out of an install and was able to get around it by finding the grubx file on the drive on a different computer with windows (doesn't need linux). I simply changed the name of that file on the usb drive to mmx and that worked pretty much the same as above just didn't move anything to the desktop to make the change. I simply right clicked and changed the name to mmx. Also disabled secure boot before doing this.

[monkeypeach]

Thank you @Heat for the alternate solution, because I was getting out of space error messages trying to add a copy of the file to the folder. (Tried in both linux and windows.)

Edited to add: I created the USB key using Etcher in Windows.

[chris99899]

A solution which worked for me was to take the CMOS battery out of the Mainboard, waiting 10/15 Minutes and put it back on to boot afterwards. That fixed the problem for me though. Nvram was cleared by that way so I could just boot normally again on that pc an do the installation correctly.

Crazy about this error was that I wasn't able to install any kind of Linux Mint anymore. Even with UEFI off.

[monkeypeach]

Adding to this thread in case it helps future readers --

I ended up using this solution viewtopic.php?t=414479 which was for Dell but I found a similar option in my HP laptop BIOS to specify the .efi to boot from.

The reason for this was that my USB key did actually have a \EFI\BOOT\mmx64.efi file already, but it not possible to boot from it. It was also smaller in size than the grubx64.efi. So I decided not to modify the USB key in any way unless absolutely necessary.

Thanks again to all who pitched in with solutions!