Cannot boot from Linux Mint 21.3 live USB.

[377Ohms]

I downloaded the Linux Mint 21.3 live/install 64-bit ISO image (sha256sum.txt matches) and flashed it to a 16GB SanDisk USB drive with the latest Balena Etcher utility. The flashing session went error-free. I inserted the USB drive into a Dell Latitude 7480 laptop running a brand new Windows 11 Pro install on a brand new empty Crucial 1TB SSD. Now Windows 11 Pro is running fine. I tried to boot from the Mint live USB drive. It will not boot:

Boot > F12 (choose boot media) > UEFI BOOT: > UEFI: SanDisk, Partition 1 > Enter to select... result (there may be mis-spellings):

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()

The USB drive has this in D:\EFI\boot\

bootia32.efi 372 KB
bootx64.efi 938 KB
grubx64.efi 2,222 KB

There is this too D:\boot\grub\grub.cfg 1 KB

I also tried burning the Mint ISO to a freshly formatted USB drive with the latest RUFUS utility. That complained there were two missing files needed to boot. RUFUS offered to download the files from the Internet and install them for me. I let it do so (I know, dumb move, but I have nothing to lose at this point). Afterward, the burnt image from RUFUS would not boot either.

Note: I was able to create the Mint live USB drive once two days ago. That would boot to Mint live OK. But then when I tried to install Mint to the Windows machine's SSD it failed at the "detected BitLocker" stage. But when I checked the Windows installation, BitLocker was not (and never was) activated in Windows. Now I have a bigger problem: I cannot recreate the Mint boot/install USB drive any more, even from a separate machine running Windows 10.

What a mess... any suggestions?

Thank You, David

[mikaelrask]

Hey and welcome to the forum and linux mint, if you have not done it already, go into your bios and disable fast/secure boot.

[Jo-con-Ël]

Also disable Fast start-up on Windows 11.

[TVB123]

I had the exact same problem and here is my workaround that worked for me:

viewtopic.php?p=2446958#p2446958

[Jo-con-Ël]

Yes, but confirm you are pointing to /EFI/boot/grubx64 on USB' s second partition (the EFI one).

[Reddog1]

What a mess this is......

It appears that some uefi (not all) are looking for mmx64.efi in the EFI boot Path, and if it isn't there boot breaks. mmx64.efi is the MOK utility for managing the Machine Owner Key. If it fails to boot because of a 'bad' signature, it is supposed to offer to sign GRUB with your MOK, but some uefi implementations won't proceed, at all, without mmx64.efi being where it is expected to be (the efi boot Path).

You would think that turning off Secure Boot would be a viable solution, but it definitely is not in some cases, because the uefi programmer's implementation still requires the EFI path to be correct in order to proceed. And some implementations seem to allow the user to sign but then will still fail if the mmx64.efi isn't where the uefi wants it to be.

Furthermore, mmx64.efi points to grubx64.efi. The solution would be for ubuntu developer's to make a copy of grubx64.efi and name it mmx64.efi so that those (in my opinion--broken) uefi's would find it where they want it to be, and stop freezing the boot and printing 'mmx64.efi not found' errors.

[TVB123]

Yes, but confirm you are pointing to /EFI/boot/grubx64 on USB' s second partition (the EFI one).

Assuming you were asking me.

I'm not sure but I believe it was the first partition.
The setup of my notebook showed: PciRoot(0x0)/Pci(0x14,0x0)/USB(0xC,0x0)/USB(0x1,0x0)/HD(1,MBR, 0xD58B2EE)

p.s. the pictures of the setup are made after the successful installation of Linux Mint.
I put the pendrive again and went into the setup/bios and clicked on "Add Boot Option".

[TVB123]

What a mess this is......

Agreed.

It appears that some uefi (not all) are looking for mmx64.efi in the EFI boot Path, and if it isn't there boot breaks. mmx64.efi is the MOK utility for managing the Machine Owner Key. If it fails to boot because of a 'bad' signature, it is supposed to offer to sign GRUB with your MOK, but some uefi implementations won't proceed, at all, without mmx64.efi being where it is expected to be (the efi boot Path).

You would think that turning off Secure Boot would be a viable solution, but it definitely is not in some cases, because the uefi programmer's implementation still requires the EFI path to be correct in order to proceed. And some implementations seem to allow the user to sign but then will still fail if the mmx64.efi isn't where the uefi wants it to be.

I'm not sure if that is the case. The OpenSuse iso does not have mmx64.efi but MokManager.efi instead which means
the system does not look literally for a file with the name "mmx64.efi".

[Jo-con-Ël]

I agreed with Reddog1, computer's firmware (or its settings) is the end responsible on this problem and the reason why a workaround applied to one computer would not work on another.

Assuming you were asking me.

Yes. In case of most Dell computers you (and probably OP) can create a boot option on Boot Sequence pointing to .efi file. It is registered by firmware's boot manager so it's different than default UEFI: USB HD boot option (F12, boot menu).

Also post back sudo blkid and sudo efibootmgr -v result, please.

[TVB123]

Yes. Also post back sudo blkid and sudo efibootmgr -v result, please.

Code: Select all

sudo blkid
/dev/nvme0n1p5: UUID="ec637d8e-86dd-4293-878b-f273b3f488d0" TYPE="swap" PARTUUID="b6fc2a18-5577-4719-8bd9-040698dce219"
/dev/nvme0n1p3: UUID="ca5726f6-8a2f-4325-9c91-63c2273123d6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b0e1d80c-f5ba-4e8f-b928-87b17c5520e4"
/dev/nvme0n1p1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="AAA0-044F" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="098b31fb-fd26-4490-b04a-1cdaf370e79d"
/dev/nvme0n1p6: UUID="f0101620-e434-48b8-878b-feb861e7e877" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8e7f5443-b437-460e-900a-035c8967b76b"
/dev/nvme0n1p4: UUID="5686eb57-8888-4400-9989-1cf005e653d6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6bd9ce12-7833-4154-83fa-d32500b4e556"
/dev/nvme0n1p2: LABEL="OS" UUID="8362ec03-e862-4053-8c66-5fe573ed6366" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Basic data partition" PARTUUID="76171670-92b0-4b4a-baa6-aba19e065c27"
/dev/sda2: SEC_TYPE="msdos" UUID="659D-4321" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d548b2ee-02"
/dev/sda3: LABEL="writable" UUID="61e42f21-fdd6-4f74-90b2-c531f15d8e1a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d548b2ee-03"
/dev/sda1: BLOCK_SIZE="2048" UUID="2024-01-09-12-59-13-00" LABEL="Linux Mint 21.3 Cinnamon 64-bit" TYPE="iso9660" PARTUUID="d548b2ee-01"

Code: Select all

sudo efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000,0005
Boot0000* opensuse  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(\EFI\opensuse\grubx64.efi)
Boot0002* ubuntu  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* UEFI: SSDPEKKF256G8 NVMe INTEL 256GB, Partition 1  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(EFI\boot\bootx64.efi)..BO

[Jo-con-Ël]

I'm sorry. Would you, please, post back sudo efibootmgr -v result when booting Linux Mint Live USB?

[TVB123]

I'm sorry. Would you, please, post back sudo efibootmgr -v result when booting Linux Mint Live USB?

Code: Select all

sudo efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0002,0000,0005,0006,0001
Boot0000* opensuse  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(\EFI\opensuse\grubx64.efi)
Boot0001* Linux Mint USB pendrive  PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/USB(2,0)/HD(1,MBR,0xd548b2ee,0x20ac,0x2780)/File(\EFI\boot\grubx64.efi)
Boot0002* ubuntu  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* UEFI: SSDPEKKF256G8 NVMe INTEL 256GB, Partition 1  HD(1,GPT,098b31fb-fd26-4490-b04a-1cdaf370e79d,0x800,0x177000)/File(EFI\boot\bootx64.efi)..BO
Boot0006* UEFI: Corsair Voyager GT 3.0 1.00, Partition 1  PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/USB(2,0)/HD(1,MBR,0xd548b2ee,0x20ac,0x2780)..BO

[Jo-con-Ël]

Thank you very much, Now it is clear the boot option you have created (Boot0001) and the default one created by firmware's boot manager on detecting Live USB (Boot0006).

[Reddog1]

The OpenSuse iso does not have mmx64.efi but MokManager.efi instead

I have no iron installs of OpenSuse (only VM), and I was not aware of this. What that leads me to believe, is that the uefi is looking not just at the name of the .efi, but at the CONTENTS of an .efi mok manager file, and if that doesn't exist it aborts the boot.

I suspect that renaming the Suse MokManager.efi to mmx64.efi would still result in a booting system.

[377Ohms]

Hey and welcome to the forum and linux mint, if you have not done it already, go into your bios and disable fast/secure boot.

Thank you. I did disable fast boot in Windows. Did not help.

[377Ohms]

What a mess this is......

It appears that some uefi (not all) are looking for mmx64.efi in the EFI boot Path, and if it isn't there boot breaks. mmx64.efi is the MOK utility for managing the Machine Owner Key. If it fails to boot because of a 'bad' signature, it is supposed to offer to sign GRUB with your MOK, but some uefi implementations won't proceed, at all, without mmx64.efi being where it is expected to be (the efi boot Path).

You would think that turning off Secure Boot would be a viable solution, but it definitely is not in some cases, because the uefi programmer's implementation still requires the EFI path to be correct in order to proceed. And some implementations seem to allow the user to sign but then will still fail if the mmx64.efi isn't where the uefi wants it to be.

Furthermore, mmx64.efi points to grubx64.efi. The solution would be for ubuntu developer's to make a copy of grubx64.efi and name it mmx64.efi so that those (in my opinion--broken) uefi's would find it where they want it to be, and stop freezing the boot and printing 'mmx64.efi not found' errors.

Ooof - this IS a mess. Thanks for the heads-up.

[bendipa]

You should not have any problem with a Dell machine. My Dell is older than yours, but I just tried flashing a Mint 21 ISO onto a clean 16MB USB drive with Balena Ethcher and had no trouble booting to Live LM. The 'mok' issue you had, should only arise if Secure Boot is enabled in UEFI. Plug in your USB drive and boot to Windows. Click Start button & type msinfo (System information). On display, make sure that BIOS mode is shown as UEFI, and Secure Boot State is shown as 'off'.

Clean your Sandisk.

Click Start button and type cmd from Start menu and r. click on Command Prompt --> Select Run as administrator. At cmd prompt, type diskpart, and at prompt type lis dis. You should now see a list of disks, including your USB drive. You should easily identify your Crucial SSD and your Sandisk USB (from size alone). Each disk has a number shown on the left (probably 0 for the SSD and 1 for the USB) Run command sel dis no., substituting the correct no. for the USB drive. If you run lis dis again you'll now see an asterisk shown by the USB drive. If you are sure that is the case, type clean, which will wipe the USB drive. When done, type exit at the prompt and close cmd.

Now have a 2nd attempt at flashing the ISO onto the USB drive with Balena Etcher. When done, start booting and tap F12 key several times, when Dell logo appears. Select your Sandisk in the UEFI boot menu. Does grub menu come up okay?