silverblue-akmods-keys VS fwupd

I'm using Silverblue 39 for about 2 month coming from NixOS Unstable. It's working very well for me. I have some packages layered like Nvidia and fish shell and https://github.com/CheariX/silverblue-akmods-keys for AKMODS modules work with secure boot. Things like neovim, pyright, helix, starship, LSPs and CLI applications I install with brew (brew.sh). For desktop things I use Flatpak.

I had a problem with some Flatpak applications (like Steam and Discord) and brew because brew puts its folder in the $PATH before the default ones (/usr/bin ...) and those Flatpak applications tried to use SSL keys from brew instead of the system ones. I just changed the order of the $PATH to make brew bin path to be after ther system ones.

For VSCode I'm not using the Flatpak I'm using the tarball one I just extract in ~/applications and symlink the code binary in the ~/.local/bin. It's working well, I don't have problem with VSCode not executing LSPs and lint things. The only problem is VSCode from tarball cannot updates itself, so I need to download the newer version and extract to ~/applications. There is this VSCode CLI version (https://code.visualstudio.com/docs/?dv=linux64cli) but I was not able to make it use the wayland backend.

rpm-ostree install --apply-live rpmdevtools akmods sudo kmodgenca sudo mokutil --import /etc/pki/akmods/certs/public_key.der git clone https://github.com/CheariX/silverblue-akmods-keys cd silverblue-akmods-keys sudo bash setup.sh rpm-ostree install akmods-keys-0.0.2-8.fc$(rpm -E %fedora).noarch.rpm

On workstation, no. On Silverblue, yes. There is a package on Github that will help you if you are on Silverblue. Link here: silverblue-akmods-keys

It works, but only with a hack where you manually have to overlay a self build package that provides the akmod keys.

Unfortunately I can't test it, as this feature is currently still broken (workaround) on Kinoite/Silverblue and Silverblue is the only version of Fedora I use.

Kinoite and Silverblue have problems signing akmods, though https://github.com/CheariX/silverblue-akmods-keys is a completely functional workaround. Non-rpm-ostree variants of fedora should work according to what I have seen online.

UEFI firmware can not be updated in legacy BIOS modeSee https://github.com/fwupd/fwupd/wiki/PluginFlag:legacy-bios for more information.Use fwupdmgr --help for help

A similar bug, but featuring a different file and checksum, from today.

The more user-friendly distros have support for updating the UEFI secure boot dbx (forbidden binaries) database via fwupd, but due to the circumstances around this update, they currently don't/don't do it correctly. MS isn't doing it automatically themselves yet either so we're not any worse off. There's an open issue around handling this. I suspect it'll take a couple of months before this to-be-written support finds its way into distros. It's complex, annoying and the result of it going wrong is a system that can't boot Windows and can't boot from preexisting Windows recovery media. Distros will want to be very careful with it. I suspect they'll roll it out in stages with single-boot systems getting patched first and possibly interactive user confirmation.

Use fwupd

These updates are coming from fwupd and LVFS. The frontend is Gnome Software. Lenovo is pushing their firmware updates to LVFS, so you're updating with vendor code. Its a lot like getting device drivers and what-not through Windows Update.

More here u/CornFlakes1991 please report the issue

-> # fwupdmgr update WARNING: UEFI ESP partition not detected or configured See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for more information. Devices with no available firmware updates: • USB3.0 Hub • Samsung SSD 860 EVO 250GB • USB2.0 Hub • Unifying Receiver Devices with the latest available firmware version: • SKHynix • UEFI dbx

Related issue: https://github.com/fwupd/fwupd/issues/5477

Would be good to put some pressure on them to use this.