the efi file selection in the bios shows mmx64 under /efi/fedora instead of /efi/boot
the efi file selection in the bios shows mmx64 under /efi/fedora instead of /efi/boot
R
RI had mokutil working fine with a normal Fedora 38 Workstation install, so I don't know why the file/symlinking is missing
Rthe laptop powers itself off doesn't get beyond Bios
RHow do I get rid of this mokutil error?
JI'm not sure on this one
Rthis has killed my laptop 
Rthe only way the laptop will boot now is falling back to bios mode. I need to reset mokutil state or otherwise I will need to flash the bios
RI should at least be able to boot into a live image in bios mode
Athough it does require changes for the nvidia.just and custom.just to be made in config ... but i think that's probably not a concern.
I commented on the PR regarding that. The inclusion of the NVIDIA config in the "main justfile config RPM" kinda makes sense in a lot of ways.
The issue is the , it's currently holding anything added by startingpoint + anything the person making a downstream image wants to add to it (they fork startingpoint and add their own stuff to ), so we can't include that one in the main config repo.
I'm also unsure about how all of this will work long-term, after just's
includeBut yeah, is in an awkward spot atm.
AHow did you get here?
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?