mmx64.efi not found

[TVB123]

Hi,

I created bootable usb pendrives using dd many times without any problems, also with SD-cards for the Raspeberry Pi.
But with the Linux Mint iso image something goes wrong and I don't know what.
Here's what I did:
1. I downloaded the iso image from a fast mirror using wget.
2. I downloaded the file sha256sum.txt from the downloadpage from the Linux Mint website.
3. I checked the integrity of the iso image using sha256sum, it's ok.
4. I copied the iso image to an usb pendrive using the command:

Code: Select all

   sudo dd if=linuxmint-21.3-cinnamon-64bit.iso of=/dev/sda bs=4M status=progress && sync

5. when I tried to boot two different pc's (a notebook and a workstation) with it, I see the same error:

mmx64.efi not found
mok manager not found

I can't copy and paste that message obviously, and the pc switches off after a couple of seconds.

When I mount the pendrive and check the contents, I see this: (see attachement)

There's no previous installation of Linux Mint on the two pc's I tried (I'm using OpenSuse Leap).
There's no windows installed on these pc's and secure boot is disabled.

When searching for clues I found that many people stumbled over this problem but none of the suggested solutions
worked for me or the solutions weren't applicable to my situation.

Any ideas?

[Reddog1]

My preferred solution would be #2

https://devicetests.com/fixing-efi-boot ... -on-xps-15

[TVB123]

My preferred solution would be #2

https://devicetests.com/fixing-efi-boot ... -on-xps-15

Instead of copying & renaming grubx64.efi to mmx64.efi, I entered the EFI BIOS setup of the laptop and created manually a new entry
that points to /EFI/boot/grubx64.efi on the pendrive.
When I reboot and select that new entry using the bootmenu, it boots another linux system installed on the first partition of the harddisk,
not the Linux Mint system on the pendrive.

I think that the solutions found when searching the net, only work when there's a problem with booting after the installation.
My problem is that I can't even get to start the live system on the pendrive before installing.

[Reddog1]

You appear to be experienced enough to know that you aren't attempting to boot efi on a computer set for Legacy. On your efi boot usb, EFI/boot/

should contain 3 files:


bootx64.efi

grubx64.efi

mmx64.efi

Anything else and your usb drive isn't the way it should be. Your screenshot shows a 32-bit efi boot, and that's NOT normal and not needed for any but a few, very old efi systems that had a 32-bit efi (and even some of those would boot 64-bit efi). I only know of 32-bit efi being necessary with apple hardware from around 2007 and before.

The easiest solution would probably be NOT to make a bootable drive from the .iso file at all, but to make a Ventoy drive (Ventoy can be made on either a linux system or a windows system). Ventoy itself is bootable and you only need to copy the .iso file to the drive. Once Ventoy is booted it is a matter of choosing the .iso which will boot to the live version of Mint (or any other .iso) from which you can run the installer. This avoids problems with the programs/methods used to make an .iso into a bootable drive, which is likely what has happened to you.

Ventoy is one of the best tools for making efi bootables that there is. Make a ventoy drive once, and copy as many .iso as it will hold to it, and forget rufus and dd.

https://www.ventoy.net/en/index.html

[JeremyB]

You appear to be experienced enough to know that you aren't attempting to boot efi on a computer set for Legacy. On your efi boot usb, EFI/boot/

should contain 3 files:


bootx64.efi

grubx64.efi

mmx64.efi

Anything else and your usb drive isn't the way it should be. Your screenshot shows a 32-bit efi boot, and that's NOT normal and not needed for any but a few, very old efi systems that had a 32-bit efi (and even some of those would boot 64-bit efi). I only know of 32-bit efi being necessary with apple hardware from around 2007 and before.

The easiest solution would probably be NOT to make a bootable drive from the .iso file at all, but to make a Ventoy drive (Ventoy can be made on either a linux system or a windows system). Ventoy itself is bootable and you only need to copy the .iso file to the drive. Once Ventoy is booted it is a matter of choosing the .iso which will boot to the live version of Mint (or any other .iso) from which you can run the installer. This avoids problems with the programs/methods used to make an .iso into a bootable drive, which is likely what has happened to you.

Ventoy is one of the best tools for making efi bootables that there is. Make a ventoy drive once, and copy as many .iso as it will hold to it, and forget rufus and dd.

https://www.ventoy.net/en/index.html

There is something going on with new ISO's and the mmx64.efi file doesn't exist but I think Ventoy may work

[TVB123]

Can it be related to this?

https://github.com/linuxmint/linuxmint/issues/622

Tomorrow I'll try the edge iso.

[Reddog1]

The invalid link is in the EDGE .iso (or was, don't know about now). Edge is for recent hardware.

I don't have a 21.3 boot usb, but the 21.2 contains mmx64.efi

Using Ventoy, you can try both -- or all 3 -- without making a boot usb for each one. I haven't seen any need to update 21.2 to 21.3 because all my hardware works and all the 21's go EOL at the same time. In other words, I cannot vouch for 21.3 or Edge

[TVB123]

I tried the edge iso and it gives the same error.
In order to check my own sanity, I downloaded Linux Mint 20.3 and followed the exact same procedure as I described in the OP.
Guess what? It worked like a charm. Imho this proves that there's a serious problem with the actual iso's and they should be retracted
(or there should be at least a big warning on the download page).
What impression does this make to new Linux users?
I'm very, very disappointed... (not in you, the people here who are trying to help me, I'm grateful for that).
What I would like to now is two things:
1. what is the exact cause of the problem
2. why the devs/maintainers don't take action (as in visible action e.g. some announcements or warnings to the public/users)

In the mean time I'll try some of the workarounds you suggested.

Sorry for the rant...

[Jo-con-Ël]

Tomorrow I'll try the edge iso.

If you try it do not make Live USB as you are doing, using dd. Notice you wont be able to try any solution on Reddog1' s link that involves making changes on Linux Live USB drive when creating USB with dd or dd based tools (balena-etcher, LM' s tool,...)

If not Ventoy, it is worth creating it with a tool (Rufus, Unetbootin,..) that makes possible modifying ISO partition so you can copy grubx64.efi on /EFI/boot/ and rename copied file as shimx64.efi and/or mmx64.efi inside USB to boot from USB.

PD:Too late (I was submitting when you posted your last).

[TVB123]

Copying & renaming grubx64.efi does not work because they have different purposes and contain different data & instructions.
If I manually create an EFI boot entry that points to the file /EFI/BOOT/grubx64.efi, the system boots the OS that was already installed on
the first partition of the internal harddrive.

Also, have a look at the content of the 20.3 iso file that installs correctly. That iso has in the /EFI/BOOT/ directory the following files:
BOOTx64.EFI, grubx64.efi and mmx64.efi. The last two files are different (not just the name but also the sized and content).
You cannot replace mmx64.efi with grubx64.efi and expect the same result.

[AndyMH]

If memory serves me correctly, the LM21.3 iso will not boot with secure boot enabled (a bug) and this has been fixed with the edge iso. I always disable secure boot. Until LM21 I always created isos using mint's usb imagewriter. I could not get an LM21 stick to boot UEFI in a lenovo M720Q. I used ventoy instead and no problems. Ventoy is now my "go to" solution for creating bootable sticks.

[TVB123]

To be clear, I always disable secure boot and the TPM in the bios/setup of the pc.
(I don't use windows, only very occasionally in virtualbox.)
Edge iso gives the same error.

[TVB123]

There's some progress.
My notebook (a Dell XPS 13) which I used for most of the experiments, has a small hidden partition that contains
Ubuntu 18.xx. The notebook came preinstalled with it. During my attempts to let the EFI setup point to grubx64.efi (which is effectively the same
as copying & renaming it to mmx64.efi) the notebook booted and I got the Grub menu which had the first entry set as Linx Mint.
But when I selected that, it did not start the live system on the pendrive but that old and unused partition with Ubuntu on the harddrive.
Next attempt was to unpack the Linux Mint iso, copy the mmx64.efi file from an older version of Linux Mint and put that manually on the
pendrive and I manually set the bootflag of that partition. That gave the same result: the notebook booted, a grub menu appeared with Linux Mint
but when selected it booted Ubuntu.
Then I got an idea. I deleted (formatted) that partition that contained Ubuntu, and then, after a restart, I was able to boot the live system from
the pendrive!
Now I'm puzzled as of why it started Ubuntu instead of the system on the pendrive.
Also why did it start Ubuntu but not one of the several other partitions that contain different installations of OpenSuse?
Very weird...

Resuming: I was catched by two problems, the missing mmx64.efi file and (after resolving that) a mysterious loading of a wrong partition...

To be continued.

[TVB123]

Ok, finally I managed to install successfully Linux Mint 21.3 on my notebook.
In the end, I used this procedure:

Copy the downloaded iso to a pendrive using the command:

Code: Select all

sudo dd if=linuxmint-21.3-cinnamon-64bit.iso of=/dev/sda bs=4M status=progress && sync

Insert the pendrive into the computer and restart and go immediately into the setup (bios) of the pc (usually pressing F2).

Go to the part where they list the different EFI boot entries. There is (should be) a way to manually create and add a new entry.
Create the new entry (it's only temporary), I called it Linux Mint pendrive and let it point to the file /EFI/boot/grubx64.efi on the pendrive.
Save the new entry and reboot and press F12 (can be different on your pc) to select the bootmenu.
In the bootmenu select and start the new entry. Now it should boot the live system from the pendrive.

After the installation, enter the setup of the computer again in order to remove the boot entry we created before.
Do not remove the new entry created by the installation! (which was named Ubuntu in my case, go figure...)

Pay attention though, at least on my notebook, this does not work when there's already an existing Ubuntu (or Linux Mint) installation.
Why this is, I don't know. For me the solution was to format (and leave empty) the Ubuntu partition.

I hope this can be of help for other people who are strugling with this.

Again, the fact that the iso still hasn't been retracted and fixed, makes for a very bad impression to new users...

[ozalba]

The easiest solution would probably be NOT to make a bootable drive from the .iso file at all, but to make a Ventoy drive
...
Ventoy is one of the best tools for making efi bootables that there is. Make a ventoy drive once, and copy as many .iso as it will hold to it, and forget rufus and dd.

Just nosing around the forum while I'm at a loose end, and spotted this. Doesn't necessarily solve any particular problem I have (but I'll try it when having another go at live booting my old Win7 PC), but I like the sound of it. Hadn't heard of Ventoy before.

Cheers!

[AndyMH]

Hadn't heard of Ventoy before.

Here is an excellent tutorial:
viewtopic.php?t=406806&hilit=ventoy

[ozalba]

Here is an excellent tutorial:
viewtopic.php?t=406806&hilit=ventoy

I think I just followed the Ventoy instructions, and put a couple of distros on it. Still wouldn't boot in the old PC though. I did some nosing around and went in to the BIOS and disabled quick boot, but still no luck. Now, I can't get into Setup to enable quick boot, so a perfectly good Win7 machine now takes about 45 minutes to boot

Today hasn't been good, on various fronts. I'm off to get a book.

[billyswong]

Pay attention though, at least on my notebook, this does not work when there's already an existing Ubuntu (or Linux Mint) installation.
Why this is, I don't know. For me the solution was to format (and leave empty) the Ubuntu partition.

This resonates with what I discussed in another topic viewtopic.php?p=2447790#p2447790
In "modern" UEFI era, one has to unplug any existing OS drives or wipe them clean before installing, else the OS install process is going to be buggy. In theory, this shouldn't be necessary but in reality...
https://github.com/linuxmint/ubiquity/issues/63
https://github.com/linuxmint/ubiquity/issues/61
Two similar bug reports on this same issue last year.

[TVB123]

Pay attention though, at least on my notebook, this does not work when there's already an existing Ubuntu (or Linux Mint) installation.
Why this is, I don't know. For me the solution was to format (and leave empty) the Ubuntu partition.

This resonates with what I discussed in another topic viewtopic.php?p=2447790#p2447790
In "modern" UEFI era, one has to unplug any existing OS drives or wipe them clean before installing, else the OS install process is going to be buggy. In theory, this shouldn't be necessary but in reality...
https://github.com/linuxmint/ubiquity/issues/63
https://github.com/linuxmint/ubiquity/issues/61
Two similar bug reports on this same issue last year.

I only experienced this with Linux Mint.
Never had any problems (regarding booting / UEFI) with OpenSuse, also not that strange "twice booting"...
Why not have a look there to see how the "competion" manage to do it.