When I try to install a Linux-based operating system on my Sony VAIO SVJ20215CG Tap 20, I see the following error message immediately after the 'VAIO' logo, and before I am given the option to boot into a "live" Linux-based operating system or install a Linux-based operating system:
Failed to open \EFI\BOOT\mmx64.efi - Not found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
Failed to start MokManager: Not Found
Something has gone seriously wrong: import_mok_state() failed
: Not Found

The interesting thing is, Microsoft Windows-based operating systems install and run on this computer just fine... I installed an old copy of 'Windows XP: Home' that I had lying around and it worked perfectly; and I downloaded a copy of 'Windows 10' from Microsoft's website, which also installed without issue (that's what's on there now).

I have tried multiple distros - thinking it was some sort of bug in the distro (the last time I tried this was the moment Ubuntu 20.04 LTS dropped) - but it's always the same error... Most recently, I am trying Pop!_OS 21.10 and because Pop!_OS doesn't support Secure Boot, I tried turning this off - but I get the same error, regardless of whether Secure Boot is on or not.

Obviously the issue is something to do with the UEFI, but Windows 10 doesn't experience any errors and I couldn't see anything out of place in the BIOS / UEFI settings... Though it's pretty hard to "break" something in there, outside of a failed firmware upgrade.

Resetting the BIOS / UEFI to its default values also does not work.

Any ideas?

---

I managed to get everything working, though I'm not exactly sure how.

First, I downloaded the latest version of Ubuntu (21.10), in hope that if it was a bug (the first time I had this problem was way back when 20.04 LTS first dropped), it would have been fixed by now... When booting with the "live" USB, I still saw the error message, but then Ubuntu appeared to ignore it and moved on to the usual "live" USB menu (Boot Ubuntu, Install Ubuntu, Drop to Terminal, etc...).

So I went into a "live" session of Ubuntu, with the intention to install a "clean" version Ubuntu in a single-boot setup - in hopes that such a course of action would fix whatever the issue was during the process - and then re-install a "clean" version of Pop!_OS in in a single-boot setup "over the top" of Ubuntu (my reasoning for this process was because Ubuntu is upstream of Pop!_OS and it's generally a little more robust than most other distros).

But Ubiquity kept freezing at various points (it wasn't consistently the same screen) and when it did eventually get far enough along into the installation for something worthwhile to happen, Ubiquity started whinging that it couldn't continue because sda1 was "read only" (according to GNOME Disks, it was not).

This was after Ubiquity had supposedly written the partition changes to disk, but before the "Select your location" screen.

Since Ubiquity had frozen, I would force it to quit using GNOME System Monitor and re-start the installation, at which point Ubiquity would claim that nothing had changed since the last time I ran it (i.e. that the partition changes were not made), and the whole process would start again.

Now I can't remember what my thought process was at the time, but eventually I got the s#*ts and decided to try my "live" Pop!_OS USB again... Much to my surprise, my Microsoft Windows 10 installation was now gone and the Pop!_OS installation went ahead without so much as a "bump in the road"; its installer also never froze, not even once.

I'm not sure why Ubiquity was having so many problems - in my experience, it's always been good (albeit visually displeasing) - and I'm not exactly sure how this was fixed... But, when I installed Pop!_OS, I was watching the Terminal commands and I did notice that Pop!_OS' installer appeared to write various files (including the ones mention in my original post) to the UEFI.

This was what I was hoping Ubuntu would do, but since the installation failed and I moved onto Pop!_OS, it looks like the latter did it for me anyway.

On a side note, I think this might have something to do with certain distros, Linux Mint in particular... I've been working on this for the last three hours and the only consistency I could see between myself and others that have had this problem was that some of them have used Linux Mint with the affected computer prior to the issue (the computer I was having problems with had Linux Mint on it for a little while); I am not the only person who has made this possible connection. It has been suggested that there may be some sort of bug in Linux Mint when writing keys to the UEFI (such as when installing certain drivers).

Anyway, my issue is now fixed and hopefully this post will help somebody else experiencing the same problem...

Last edited by Cyba.Cowboy on 13 March 2022 at 3:48 am UTC