Confused on Steam Play and Proton? Be sure to check out our guide.
Strange UEFI Error When Installing Linux-Based Operating Systems
Cyba.Cowboy 12 Mar
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
Nanobang 13 Mar
I'm glad you shared your experience here. I had uefi/install problems a few months back trying to replace Linux Mint XFCE 20 with Solus KDE on my main machine. I don't remember what errors there may have been, but the upshot was the same, the install would fail, seemingly at random points in the process. After a frustrating day of tinkering and fishing through internet articles, I tried Kubuntu 21.10 instead and it installed successfully. I declared it good enough and stopped there.

But ---

After reading your post, I think I'll retry a Solus KDE install this summer, when it's time to upgrade. Maybe the Ubuntu install fixed something? Time will tell, but until then I have a bit of hope. Thanks for that! :)

Last edited by Nanobang on 13 March 2022 at 2:52 pm UTC
Cyba.Cowboy 13 Mar
Quoting: NanobangBut ---

After reading your post, I think I'll retry a Solus KDE install this summer, when it's time to upgrade. Maybe the Ubuntu install fixed something? Time will tell, but until then I have a bit of hope. Thanks for that! :)

Try it after Jammy Jellyfish drops... Just to further minimize the possibility of any old bugs lying around.
dvd 13 Mar
Looks like your device might have preloaded keys for UEFI Secure Boot (probably for M$ stuff). Ubuntu has a shim that is signed by M$ so it should work. (My guess you haven't cleared/uploaded any keys for Secureboot) Try turning it off, it should fix the issues with the keys.
Cyba.Cowboy 13 Mar
No, turning off Secure Boot didn't fix the issue... To me, it looks like it was missing some files and / or some files were corrupt in my UEFI; but when I tried to install a recent version of Ubuntu or Pop!_OS, it appears to have replaced those missing or corrupt files.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.