I've been attempting to install Pop-OS 20.10 but am not able to boot from the usb image here: https://pop.system76.com/. The error message I get from UEFI is:

Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
Failed to start MokManager: Not Fond
Something has gone seriously wrong: import_mok_state() failed

There's a previous thread in askubuntu.com that attempts to resolve this issue, https://askubuntu.com/questions/1085550/cant-install-ubuntu-18-10-on-xps-15-efi-boot-mmx64-efi-not-found. However, the solutions there are unsatisfactory. They all suggest re-naming or copying the grubx64.efi to a mmx64.efi file in the efi/boot directory of the .iso; which I'm not able to do since .iso files are read-only.

The machine is a Thinkpad T570, on which I've got Windows 10 on the main NVMe drive and Arch on the WiFi-slot SSD.

1 Answer 1


An ISO9660 filesystem is certainly read-only, yes.

But a UEFI bootable ISO image that has been hybridized for USB use is not just an ISO9660 filesystem: it should also contain a secondary boot image embedded in it, and an embedded partition table that makes it look like a HDD image with multiple partitions, instead of just a single ISO9660 filesystem.

A regular non-bootable ISO image can be readily identified as such by the file command:

# file virtio-win-0.1.102.iso 
virtio-win-0.1.102.iso: ISO 9660 CD-ROM filesystem data 'virtio-win-0.1.102'

But do that to the Pop_OS ISO image, and you'll get something completely different:

# file pop-os_20.10_amd64_intel_18.iso 
pop-os_20.10_amd64_intel_18.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 484, 8192 sectors

It seems to contain a partition table. To make use of that partition table, you can use losetup -P:

# losetup -P /dev/loop0 pop-os_20.10_amd64_intel_18.iso
# ls -l /dev/loop0*
brw-rw---- 1 root disk   7, 0 Jun 27 23:10 /dev/loop0
brw-rw---- 1 root disk 259, 6 Jun 27 23:10 /dev/loop0p1
brw-rw---- 1 root disk 259, 7 Jun 27 23:10 /dev/loop0p2

# fdisk -l /dev/loop0
Disk /dev/loop0: 2.4 GiB, 2516582400 bytes, 4915200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3c3f6082

Device       Boot Start     End Sectors  Size Id Type
/dev/loop0p1 *        0 4915199 4915200  2.4G  0 Empty
/dev/loop0p2        484    8675    8192    4M ef EFI (FAT-12/16/32)

The type ID of the first partition is registered as 0 because there is no standard MBR partition type value for a ISO9660 filesystem. The first partition contains the main ISO9660 contents of this ISO hybrid image. But embedded inside it is another, small partition.

Note that the first partition is bootable according to the MBR, so it most likely contains a BIOS-compatible boot sector:

# file -s /dev/loop0p1
/dev/loop0p1: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 484, 8192 sectors

On the other hand, UEFI does not care about MBR-style boot flags. If a disk is MBR-partitioned, UEFI wants to see a FAT partition with a special type ID 0xef to indicate a EFI System Partition. That's exactly what the second partition is.

# file -s /dev/loop0p2
/dev/loop0p2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 8192 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 6, sectors/track 32, heads 64, serial number 0x80bb708e, unlabeled, FAT (12 bit)

You can even mount it and see that Linux will identify it as a vfat filesystem type (which includes all the FAT variants other than ExFAT). And it can be mounted as writeable:

# mount /dev/loop0p2 /mnt
# grep /mnt /proc/mounts
/dev/loop0p2 /mnt vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0

# tree /mnt
└── efi
    └── boot
        ├── bootx64.efi
        └── grubx64.efi

# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0p2    4.0M  2.7M  1.4M  67% /mnt

Here, bootx64.efi is actually the Secure Boot shimx64.efi, renamed to match the special UEFI removable media/fallback bootloader filename. And grubx64.efi is the UEFI version of GRUB, with all the modules built in and signed with a certificate whose public part is embedded in the shim to satisfy Secure Boot requirements.

The mmx64.efi should fit nicely into the 1.4M of free space in that FAT filesystem. Or if you have disabled Secure Boot, you could do a mv grubx64.efi bootx64.efi to eliminate the Secure Boot shim (which is the one calling for mmx64.efi) and boot directly to a UEFI version of GRUB.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .