RI ran the uBlue iso install
AIs it the installer that gave you an error?
Rthe laptop previously had a vanilla F38 Workstation install, then I installed Silverblue with no problems and without nvidia drivers.
Rthen I ran uBlue install with the nvidia option selected
Rthat error for mokutil is after rebooting once the Anaconda run had completed
Rwhen it was trying to import the uBlue-os key I assume
RI am wondering why the mmx64 file was not under /boot
RWhere is the best repo to create an issue to note this error?
Rin case someone else hits it?
RGitHub
Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/nvidia development by creating an account on GitHub.
Jprobably
RFWIW the solutions appear to be renaming grubx64.efi to mmx64.efi to get it to work
Rbut I'll see if it boots off a different liveISO first
Jyeah we might need to add to the faq or something
Rfor reference these were ubuntu but similar might work (disclaimer: I have not tested any of these) https://nrecursions.blogspot.com/2019/08/solving-mokmanager-mmx64efi-not-found.html
RAsk Ubuntu
I'm facing a huge problem with MOK manager. After a install Ubuntu 19.10, with third party drivers install enabled, I rebooted the system. On boot, MOK manager was launched normally, but accidental...
Ralso good time to check if my laptop has a newer bios update to apply, it's an older Acer Nitro laptop 
Rmy next laptop will be a Framework one 
JI'm eyeing one myself
RI think the new AMD Framework laptop looks great
PYeah, I got a new laptop earlier this year, but next one I get would most likely be framework (though that might be a while)
Jyeah the bummer is the amd ones are all backordered
Jso if you need one sooner rather than later you gotta get the existing one
Jbut I priced one out with 32GB of ram and it all came in at under 1k so that was nice
Rwell depending on how soon I fix the mokutil error will depend when I want a new laptop 
Jheh, indeed
Rbut I am not really in a rush, the Framework don't ship directly to New Zealand yet, so I would need to get one via Australia anyway
AI haven't followed the discussion but thought I'd check Fedora Workstation 38 (regular, not immutable):
You can see that mmx64 and grubx64 are different files.
You can see that mmx64 and grubx64 are different files.
AHmm, I may know the issue... some motherboard BIOSes just don't work properly. I had a very similar issue until updating my BIOS to the latest version (2020 AMD AGESA BIOS -> 2022 version).
AMessing with those files won't be needed if the BIOS works properly.
Rit could just be my laptop not having the right keys stored. I'll have another look later
ABe sure to use the latest BIOS you can find and also enable the "custom secureboot keys" mode in your BIOS, otherwise it will not accept new keys.
RI did get it working for the Fedora 38 workstation, so maybe I missed something this time and it's purely user error
AYou can check the hashes above and see if that helps comparing the files, since they should be the same on Silverblue and Workstation.
AI remember that before I updated my BIOS, there were two issues: I could not get the MokUtil enrollment (blue screen) to come up on boot and had to switch out files to get it to show up exactly like you mention, AND even after switching files, the key would NEVER get saved to BIOS no matter how many times I tried to enroll via the blue MokUtil screen.
ANo matter what I did, it was impossible to find a /boot/efi/EFI component version that worked. Updating BIOS solved everything and it began working with vanilla Fedora EFI files.
RYeah the Dell work laptop bios stuff is super easy. My Acer laptop is years old and this stuff has improved a lot since I got it
AYeah, it's a pain when devices are discontinued. I have one with ancient BIOS that has a bunch of BIOS bugs for sleep/shutdown/reboot. But the good news is that with immutable distros there is less need for secureboot.
AYeah, We already use the new techniques mentioned in that article, so we're safe. There won't be any blackout on May 31st.
PHuh? How does an image based model reduce the need for secure boot?
ASecure boot makes the kernel unwilling to load an unsigned (or signed with untrusted certificates) kernel module.
Those modules can end up on your disk in two ways:
Those modules can end up on your disk in two ways:
- Via a root-privilege installer. This won't work on immutable distros, unless they use rpm-ostree to literally layer the kmod package, which will be easily noticeable.
- Via someone tampering on the physical disk, mounting it in another computer, and placing files on it. This can be prevented by encrypting the disk (Fedora's installer has a simple checkbox). I am also pretty sure that ostree would not allow this kind of direct tampering with files anyway.
PYes, I suppose it means malware has to more specifically be designed to work with rpm-ostree etc - but that seems more like a speed bump than anything to me. I'm not sure I would say that makes secure boot less necessary.
AI have yet to come across or hear about any malware that ever installed Linux kernel modules btw.
ALet alone targeting rpm-ostree distros specifically, an even smaller audience.
ASo far everything I ever see is user-level malware that exfiltrates user-owned files via scripting or basic stuff like that.
Rwell there are UEFI targeted malwares floating around
PI have seen Lennart Poettering's blog posts about secure boot and UKIs and everything, definitely pretty interesting stuff, will be interested to see how silverblue evolves in that direction.
ROK my solution to this was changing the order of the EFI files in my laptop BIOS, so the MMX file was listed first. This allowed the Mokutil screen to load to enroll the akmod key. I then had to change the order back to get the OS to load normally. This is an issue with my old bios
Rusing the mmx64.efi file from the /efi/fedora directory
RI just realised this laptop was manufactured in 2015.... so the EFI setup is ancient compared to modern machines