FWIW the solutions appear to be renaming grubx64.efi to mmx64.efi to get it to work
FWIW 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
ANice job. Glad your motherboard accepted the key that way. Mine didn't when I switched to that file. I did practically the same thing, but the MokUtil enrollment GUI was basically pretending to enroll the key but didn't write anything to BIOS memory. I just assumed that there was an untrusted code path/write lock involved, and stopped trying. This definitely varies between different BIOSes though.
So your machine is secureboot enrolled now?
So your machine is secureboot enrolled now?
ABtw there's a new exploit out that may make your BIOS unable to use secure boot again, if it only trusts the old Microsoft key. I remember hearing that Microsoft will change the signing key used for both Windows and the Linux SB shim because of some huge exploit.
Edit:
https://arstechnica.com/information-technology/2023/05/microsoft-patches-secure-boot-flaw-but-wont-enable-fix-by-default-until-early-2024/
Edit:
https://arstechnica.com/information-technology/2023/05/microsoft-patches-secure-boot-flaw-but-wont-enable-fix-by-default-until-early-2024/
AOkay a comment on the article clarified it better: Microsoft will revoke their old SecureBoot master key to prevent booting from old, vulnerable bootloaders signed with the old key.
AThe bug was in their Windows bootloader itself, but to protect people they need to block the old key itself with a BIOS update to revoke the key's trust. Linux will be getting the same patch because the SB shim will be signed with the new key instead. I remember seeing that MS is already in contact with the Fedora team about this.
ALet's hope they use some kind of derived key system so that your current Microsoft root certificate in the BIOS can still authenticate their upcoming, new key
RYeah the secure boot is enabled and nvidia modules are loaded. I can see in rpm-ostree that it's on the ublue silverblue nvidia image
AThat's really nice news. Sounds like you remembered to run the command to set the kernel boot args too?
ROne question though, my silverblue-nvidia install hasn't prompted me to run any tools like Yafti and the Firefox isn't via Flatpak. Is that something not included in the ISO?
AYeah yafti is a tool for your own downstream images created from the template in the repo. It isn't even installed in the main or nvidia images.
Main and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
Main and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
RI haven't run any specific commands for kernel arguements, no
AOh okay you need to do that, ostree has a special security model where kernel boot args can only be set by you, the admin. It's listed here: https://ublue.it/images/nvidia/
R