Faced A issue while installing linux

Help & Support
14

After looking into Ubuntu bug reports, Linux Mint issue reports, and multiple user cases with the exact same sequence of events, I believe the root cause is a pending MOK enrollment stored in UEFI/NVRAM rather than a partitioning issue or a damaged USB drive.

The timeline matches almost perfectly:

  • The USB booted successfully the first time.
  • The installer reached the partitioning screen.
  • A Secure Boot/MOK password was created.
  • The installation was cancelled before completion.
  • Every subsequent boot failed with:
Failed to open `\EFI\BOOT\mmx64.efi - Not Found
Failed to start MokManager
import_mok_state() failed

Linux Mint currently ships installation media that may not contain EFI\BOOT\mmx64.efi in the location shim expects when a pending MOK action exists. Once that MOK request is stored in firmware, shim attempts to launch MokManager on the next boot and fails because the required file is not available. This exact behavior has already been documented in Linux Mint issue reports and older Ubuntu bug reports.

I would recommend the following, in order:

  1. Enter firmware setup and reset Secure Boot keys to factory defaults, or clear any pending Secure Boot/MOK enrollment entries if the firmware provides that option.

  2. If available, boot an Ubuntu 24.04 Live USB. Ubuntu includes MokManager (mmx64.efi). Booting it once often allows the pending MOK request to be processed or cleared. After that, the Linux Mint USB usually boots normally again.

  3. If the firmware supports it, temporarily switch Secure Boot off and perform a complete power-off cycle before testing again.

  4. As a workaround, some users have copied or renamed EFI\BOOT\grubx64.efi to EFI\BOOT\mmx64.efi on the installation media. This has worked for many people, but it is only a workaround and not the proper fix because mmx64.efi is supposed to be MokManager, not GRUB. It can also create Secure Boot chain-loading problems later.

Given that the installer worked correctly on the first boot and the failure appeared only after the installation process was interrupted, I do not think disk space, Rufus, or the USB drive itself are the primary cause. The evidence points much more strongly toward a leftover MOK enrollment state in firmware.

4 Likes
Weekly Forum Summary