A fresh Fedora 45 Workstation boots into a clean GNOME 51 desktop that ships the cut-down ffmpeg, won’t let strace attach to a running process, and flags two popular Fedora-packaged extensions as out of date. None of that is broken. It is just the default, and most of the fixes take one command each. This list covers the things to do after installing Fedora 45, in the order we’d run them on a new laptop.
The post-install setup covers DNF5 tuning, RPM Fusion and multimedia codecs, full Flathub, NVIDIA and Intel/AMD video drivers, firmware, power modes, GNOME Tweaks and extensions, plus the Fedora 45 changes that trip people up on day one. If you still need the base system, start with the Fedora 45 Server and Workstation install guide, and read what is new in Fedora 45 for the full change list. I went through every step again on the final Fedora 45 Workstation release in November 2026 (GNOME 51.1, kernel 7.2.15), and the outputs below come from that machine, including two places where the answer changed since the first run.
1. Pull every update and reboot
The ISO is weeks old by the time you install it. Refresh the metadata and apply everything before adding third-party repos, so RPM Fusion packages resolve against current Fedora libraries:
Keep our DNF5 commands cheat sheet open while you work through this list; it has the one-page PDF and the fixes for the dnf5 errors you’re most likely to hit.
sudo dnf upgrade --refresh
sudo systemctl reboot
After the reboot, check which repositories are active. On Fedora 45 the Fedora repo files no longer sit in /etc/yum.repos.d/; they live in /usr/share/dnf5/repos.d/, and so do the Google Chrome, RPM Fusion NVIDIA and Steam definitions from fedora-workstation-repositories. On our machine /etc/yum.repos.d was completely empty until we added RPM Fusion, so don’t panic when ls shows nothing there:
dnf repolist
A fresh install shows three repositories. If you also see updates-testing, your system was installed from an early image that enabled it; turn it off with sudo dnf config-manager setopt updates-testing.enabled=0 unless you want test builds:
repo id repo name
fedora Fedora 45 - x86_64
fedora-cisco-openh264 Fedora 45 openh264 (From Cisco) - x86_64
updates Fedora 45 - x86_64 - Updates
If yours matches, you’re on stable repos only and ready for the tweaks below.
2. Make DNF5 faster
DNF5 downloads three packages at a time and defaults every prompt to “No”. Both are conservative for a desktop on a decent connection. Check the current values first:
dnf --dump-main-config | grep -E "^(max_parallel_downloads|defaultyes|fastestmirror) "
A fresh install reports these defaults:
defaultyes = 0
fastestmirror = 0
max_parallel_downloads = 3
Raise parallel downloads to 10 and make Enter mean “yes”. The config-manager setopt subcommand writes both keys into /etc/dnf/dnf.conf for you, so there is no file to hand-edit:
sudo dnf config-manager setopt max_parallel_downloads=10
sudo dnf config-manager setopt defaultyes=True
We leave fastestmirror off. Fedora’s metalink already sorts mirrors by location, and in our experience the latency probe adds little on a desktop. The DNF5 cheat sheet covers the rest of the new command syntax.
3. Turn on third-party repositories and full Flathub
GNOME Initial Setup asks whether to enable third-party repositories. Skip that screen and you get no Flathub remote at all, only the Fedora Flatpaks OCI registry. Check where you stand:
fedora-third-party query
If it says disabled (no selection has been made), enable it:
sudo fedora-third-party enable
The enable command prints nothing when it works, so run the query again to confirm the switch:
Third-party repositories are enabled.
This enables the Google Chrome, RPM Fusion NVIDIA driver and Steam repositories (those three only, not all of RPM Fusion) and adds the Flathub remote. Flatpak still labels Flathub as filtered, which scares people into thinking they have a cut-down catalogue:
flatpak remotes --columns=name,options,filter
The filter file it points at contains a single comment, # Unfiltered, so every app is visible. The remote listed 3,521 apps on our Fedora 45 install:
fedora system,oci -
flathub system,filtered /usr/share/flatpak/fedora-flathub.filter
From GNOME Software, Flathub apps now show up alongside Fedora packages. From a terminal over SSH, use sudo flatpak install for system-wide installs; without sudo, polkit refuses with Flatpak system operation Deploy not allowed for user because an SSH session isn’t the active local seat. The Flatpak and Flathub guide goes deeper on remotes and per-user installs. Apps that ship only as an AppImage need one extra FUSE package first, which our guide to running AppImages on Fedora explains.
4. Enable RPM Fusion with dnf, not rpm
This is the first Fedora 45 surprise. Older guides (including plenty of ranking ones) install the RPM Fusion release packages with rpm -ivh. Fedora 45 enforces package signatures in rpm itself, and the release package is signed with a key your system doesn’t trust yet, so the old one-liner fails outright:
warning: /var/tmp/rpm-tmp.IMJgmw: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY
Retrieving https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-45.noarch.rpm
Verifying... ########################################
Preparing... ########################################
package rpmfusion-free-release-45-0.2.noarch does not verify: Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY
Install both release packages through dnf instead, which is also what the official RPM Fusion configuration page uses. The $(rpm -E %fedora) part expands to your release number, so the same line works on the next Fedora too:
sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Confirm the repos are live:
dnf repolist | grep -i rpmfusion
You should see the base repos plus the two NVIDIA and Steam repos that item 3 switched on. Don’t be surprised by the testing repos in the list:
rpmfusion-free RPM Fusion for Fedora 45 - Free
rpmfusion-free-updates-testing RPM Fusion for Fedora 45 - Free - Test Updates
rpmfusion-nonfree RPM Fusion for Fedora 45 - Nonfree
rpmfusion-nonfree-nvidia-driver RPM Fusion for Fedora 45 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam RPM Fusion for Fedora 45 - Nonfree - Steam
rpmfusion-nonfree-updates-testing RPM Fusion for Fedora 45 - Nonfree - Test Updates
That list is what the release package gave us on the final Fedora 45 in early November 2026, and it’s the part that trips people up. The URL still serves rpmfusion-*-release-45-0.2, which leaves the stable -updates repos disabled and the -updates-testing ones enabled. Its free-fedora-45 metalink resolves fine, but all 64 mirrors it returned pointed at RPM Fusion’s development/45 tree, because releases/45 still answered 404. You don’t have to fix anything by hand. We tried switching to the stable repos and found them empty (zero packages), while ffmpeg, the freeworld Mesa drivers and akmod-nvidia all resolve from the repos shown above, so leave them as they are. The release packages update through these same repos (a 45-0.3 build was already waiting in updates-testing on our machine), so your regular sudo dnf upgrade picks up whatever RPM Fusion publishes next.
This works because DNF5 does not check signatures on local files or URLs by default (localpkg_gpgcheck = 0 in dnf --dump-main-config), while rpm now refuses them. The same applies to any vendor RPM you download (Chrome, Zoom, Slack): use sudo dnf install ./package.rpm, or import the vendor key with sudo rpm --import first if you want the signature checked.
5. Swap ffmpeg-free for full ffmpeg and add the multimedia group
Fedora ships ffmpeg-free, which has no libx264 or libx265 encoders. Replace it with RPM Fusion’s build. The --allowerasing flag lets dnf remove the free libraries that conflict:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
Then pull the GStreamer plugins that GNOME’s video player and other GStreamer apps use. The PackageKit GStreamer plugin is excluded, as in RPM Fusion’s own instructions. On our Workstation most of the group was already there, so it only added the freeworld GStreamer and libheif pieces. One side effect: libheif-freeworld pins libheif to its own version, so the install stepped libheif back from 1.23.7 to 1.23.5, and the next sudo dnf upgrade printed a libheif conflict and listed it under “Skipping packages with conflicts” while upgrading everything else. That’s harmless, and it clears once RPM Fusion rebuilds libheif-freeworld. Here’s the group install:
sudo dnf install @multimedia --setopt="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
The Cisco OpenH264 repo is already enabled on Workstation and mozilla-openh264 comes preinstalled, which covers H.264 in Firefox video calls. Check that the proprietary encoders are there:
ffmpeg -hide_banner -encoders 2>/dev/null | grep -E "libx264 |libx265 |libfdk"
All three show up after the swap:
V....D libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
V....D libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264)
V....D libx265 libx265 H.265 / HEVC (codec hevc)
A....D libfdk_aac Fraunhofer FDK AAC (codec aac)
Here is the whole sequence on one screen, from the rpm refusal to working encoders. The ffmpeg build came from rpmfusion-free-updates-testing, which is exactly why you want that repo left on for now:

For VLC, HandBrake and DVD playback, the RPM Fusion and multimedia codecs guide covers the extra packages.
6. Add hardware video decoding for Intel and AMD
Older guides tell you to run sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld. That stopped working when Fedora 44 folded the VA-API drivers into mesa-dri-drivers: the mesa-va-drivers name is now provided by mesa-dri-drivers, so swapping it out means removing the package mesa-libGL depends on. dnf refuses, and this excerpt of its answer shows why:
Problem 2: problem with installed package
- installed package mesa-libGL-26.2.5-1.fc45.x86_64 requires libgallium-26.2.5.so()(64bit), but none of the providers can be installed
- installed package mesa-libGL-26.2.5-1.fc45.x86_64 requires mesa-dri-drivers(x86-64) = 26.2.5-1.fc45, but none of the providers can be installed
- conflicting requests
Install the RPM Fusion builds next to the Fedora ones instead of swapping. Nothing gets replaced: mesa-va-drivers-freeworld (AMD and Nouveau) lands in /usr/lib64/dri-freeworld/ and RPM Fusion’s intel-media-driver in /usr/lib64/dri-nonfree/, while Fedora’s copies stay in /usr/lib64/dri/. Fedora 45’s libva searches /usr/lib64/dri-nonfree:/usr/lib64/dri-freeworld:/usr/lib64/dri in that order, so the codec-complete build wins automatically:
sudo dnf install mesa-va-drivers-freeworld
sudo dnf install intel-media-driver
Run only the line that matches your GPU. The Intel line installed cleanly on our machine. The AMD and Nouveau line didn’t, and you may hit the same thing in the first weeks after a release: RPM Fusion had already built mesa-va-drivers-freeworld 26.2.6 against the Mesa update still sitting in Fedora’s updates-testing, while the stable updates repo carried 26.2.5. Each freeworld build pins the exact Fedora Mesa version, so dnf stops with “nothing provides mesa-filesystem”:

If you see that error, the easy fix is patience: run sudo dnf upgrade --refresh again in a few days, and once Fedora pushes the matching Mesa to stable, the plain install works. If you need decoding today, enable Fedora’s testing repo for that one install:
sudo dnf install mesa-va-drivers-freeworld --enablerepo=updates-testing
It pulled the six matching Mesa packages from updates-testing for that transaction only, and the testing repo stays off afterwards.
AMD owners who also want the Vulkan video extensions can run sudo dnf swap mesa-vulkan-drivers mesa-vulkan-drivers-freeworld, which RPM Fusion also packages for Fedora 45. On real hardware, vainfo (from libva-utils) lists the VAProfileH264 and VAProfileHEVC entries once the right driver is loaded. Our lab uses a paravirtual GPU with no VA-API, so we confirmed the packages install cleanly but could not show decode profiles.
7. Install the NVIDIA driver from RPM Fusion
Nouveau is fine for a desktop session, but CUDA and serious gaming need the proprietary driver. RPM Fusion nonfree already has a Fedora 45 build (the 615 series at the time of testing, plus 580xx, 470xx and 390xx legacy branches for older cards). With Secure Boot on, create and enroll a signing key first, otherwise the kernel refuses to load the module:
sudo dnf install akmods mokutil openssl
sudo kmodgenca -a
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
mokutil asks for a one-time password. Reboot, pick “Enroll MOK” in the blue MOK manager screen and type that password. Then install the driver and the CUDA userspace:
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda
Expect a big download. On our Fedora 45 install the akmods line pulled 71 packages (kernel-devel, gcc and the RPM build tools), and the driver line added 18 more: a 424 MiB download that takes about 1 GiB on disk. The akmod builds the kernel module in the background after install, so wait a few minutes before rebooting and confirm the module exists:
modinfo -F version nvidia
It should print the driver version. If modinfo reports that the module is not found, the build has not finished; sudo akmods --force runs it in the foreground and shows compiler errors. Our lab has no NVIDIA card, so the driver load itself was not tested here; the package set and signing tools were verified on Fedora 45. The driver itself is covered on real GPUs, with Secure Boot key enrollment and the 580xx branch for older cards, in our guide to installing NVIDIA drivers on Fedora. With the driver loaded, the gaming on Fedora guide sets up Steam, Proton and MangoHud on top of it.
8. Apply firmware updates with fwupdmgr
GNOME Software applies firmware quietly, but the CLI shows you what is pending. Refresh the LVFS metadata and list updates:
sudo fwupdmgr refresh --force
fwupdmgr get-updates
Even our virtual machine got an offer: the Microsoft Secure Boot signature database update, which adds the 2023 certificates that replace the 2011 ones. On a real laptop you’ll usually also see BIOS, SSD, dock or fingerprint-reader firmware:
└─Secure Boot Signature Database Configuration Update:
New version: 2023
Summary: UEFI Secure Boot Signature Database
This updates the 3rd Party UEFI Signature Database (the "db") to the latest release from Microsoft.It also adds the latest OptionROM UEFI Signature Database update.
Apply them with sudo fwupdmgr update, with a laptop on AC power, since fwupd holds back many system firmware updates on battery.
9. Pick a power mode (and forget powerprofilesctl)
Fedora Workstation uses tuned-ppd rather than power-profiles-daemon. It answers the same D-Bus API, so the Quick Settings menu works as before. Click the System menu in the top-right corner, then the arrow on the Power Mode tile to pick Power Saver, Balanced or Performance:

- 1System menu
- 2Power Mode
This has been the Workstation default since Fedora 41, but it still catches people in the terminal. powerprofilesctl is not installed, and the power-profiles-daemon package conflicts with tuned-ppd (dnf only installs it with --allowerasing, which removes tuned-ppd). Use tuned-adm instead. The mapping between the GNOME names and TuneD profiles sits in /etc/tuned/ppd.conf, shown here in full:
[main]
# The default PPD profile
default=balanced
battery_detection=true
sysfs_acpi_monitor=true
[profiles]
# PPD = TuneD
power-saver=powersave
balanced=balanced
performance=throughput-performance
[battery]
# PPD = TuneD
balanced=balanced-battery
So picking Power Saver in the menu switches TuneD to powersave, and “Balanced” on battery quietly becomes balanced-battery. Check what is active at any time:
tuned-adm active
We switched the menu to Power Saver and TuneD followed immediately:
Current active profile: powersave
On our November test machine, where nobody had touched the menu yet, the same command reported balanced, the default from ppd.conf.
10. Install GNOME Tweaks for the missing window buttons
GNOME still ships windows with only a close button. Tweaks isn’t preinstalled on Workstation:
sudo dnf install gnome-tweaks
On first launch Tweaks shows an “Extensions Has Moved” dialog pointing you to a separate app (item 11 covers it); click Continue. Then:
- Open the Windows panel in the sidebar.
- Switch on Maximize under Titlebar Buttons.
- Switch on Minimize right below it.

- 1Windows
- 2Maximize
- 3Minimize
The buttons appear on the Tweaks window itself right away, so you’ll know at once that it worked. The toggles only write one gsetting, so you can script it on the next machine without the app:
gsettings set org.gnome.desktop.wm.preferences button-layout 'appmenu:minimize,maximize,close'
Fonts, the middle-click paste toggle and startup applications live in the same app. The GNOME Tweaks and extensions walkthrough goes panel by panel.
11. Install GNOME 51 extensions after the first update
Fedora packages several popular extensions, and on the final Fedora 45 the dnf route works again, with one condition: run item 1 first. The base fedora repo still carries Dash to Dock 105 and AppIndicator 64, whose metadata stops at GNOME 50, so GNOME marks them OUT OF DATE and won’t load them. The updates repo already has Dash to Dock 110 and AppIndicator 66 with GNOME 51 in their metadata, and an updated system picks those automatically:
sudo dnf install gnome-shell-extension-dash-to-dock gnome-shell-extension-appindicator
Check that both versions in the transaction come from updates, as they did on our machine:
gnome-shell-extension-appindicator noarch 0:66-1.fc45 updates 270.4 KiB
gnome-shell-extension-dash-to-dock noarch 0:110-1.fc45 updates 1.2 MiB
Wayland sessions can’t reload the shell, so a freshly installed extension doesn’t exist yet as far as GNOME is concerned (gnome-extensions enable answers “does not exist”). Log out, log back in, then enable it and check its state:
gnome-extensions enable [email protected]
gnome-extensions info [email protected]
The Fedora build runs cleanly on GNOME 51. If you see OUT OF DATE here instead, your system skipped the update and installed version 105:
Path: /usr/share/gnome-shell/extensions/[email protected]
URL: https://micheleg.github.io/dash-to-dock/
Original author: [email protected]
Version: 110
Enabled: Yes
State: ACTIVE
The dock now sits at the bottom of the desktop instead of hiding inside the overview:

For anything Fedora doesn’t package, go to extensions.gnome.org. The easiest route is Extension Manager from Flathub, which searches the site and installs the build that matches your shell:
flatpak install flathub com.mattjakeman.ExtensionManager
Its Installed tab is also a handy check on the step above. The Fedora-packaged Dash to Dock and AppIndicator show up under System Extensions with their switches on:

To add something new, such as Caffeine to stop the screen from sleeping during a long download:
- Switch to the Browse tab at the top of the window.
- Type the name into the Search box and press Enter.
- Click Install on the result you want; Extension Manager fetches the build marked for GNOME 51.

- 1Browse
- 2Search box
- 3Install
If you prefer the CLI (handy for dotfiles), download the zip for your shell version and install it with gnome-extensions. Don’t do this for an extension you already installed with dnf, or you end up with two copies. If the site has no build for your shell, curl -f stops with an error instead of saving an HTML page. We used Caffeine to test it:
SHELL_VER=$(gnome-shell --version | grep -oP "\d+" | head -1)
EXT=[email protected]
curl -fsSL -o /tmp/$EXT.zip "https://extensions.gnome.org/download-extension/$EXT.shell-extension.zip?shell_version=$SHELL_VER"
gnome-extensions install --force /tmp/$EXT.zip
The zip installed without complaint, and its metadata lists GNOME 51. Just like the dnf route, gnome-extensions enable [email protected] answered “does not exist” until we logged out and back in. The extensions site has mostly caught up: in November 2026 Dash to Dock, AppIndicator, Vitals, Blur my Shell and Caffeine all listed GNOME 51, while Clipboard Indicator still stopped at GNOME 50. Check the version list on an extension’s page before counting on it.
12. Check which daemon holds your secrets
Fedora 45 moves the Secret Service (the API browsers, VS Code and Git credential helpers use to store passwords) from gnome-keyring to oo7-daemon. If your machine was installed from an older image, oo7 may only arrive with the item 1 update, so log out and back in after updating, then confirm which one answers:
busctl --user status org.freedesktop.secrets | grep -E "^(Comm|Exe)="
On our lab machine, oo7 owns the name:
Comm=oo7-daemon
Exe=/usr/libexec/oo7-daemon
On the final Fedora 45 Workstation package set, gnome-keyring isn’t installed at all, so oo7 is the only store. An earlier machine of ours that started from an older ISO kept gnome-keyring after updating, with gnome-keyring-daemon --components=secrets still running next to oo7, so two secret stores existed on disk. If an app that stores tokens misbehaves after the update, run rpm -q gnome-keyring and check which daemon answers first.
13. Let debuggers attach to running processes
Fedora 45 boots with the Yama ptrace_scope set to 1, which means a process can only trace its own children. Attaching strace or gdb to an already-running program fails like this:
strace: attach: ptrace(PTRACE_SEIZE, 5448): Operation not permitted
strace: sysctl kernel.yama.ptrace_scope = 1 may be restricting this attach
gdb fails the same way with ptrace: Operation not permitted. The fix is a tiny package called yama-ptrace-enable, which drops /usr/lib/sysctl.d/10-default-yama-scope.conf and relaxes the scope to 0. The package now comes from the elfutils build, so strace and elfutils both recommend it and pull it in as a weak dependency (on our machine the akmods install in item 7 brought elfutils along and quietly flipped the scope to 0). gdb alone doesn’t: it still recommends default-yama-scope, a name the new package no longer provides, so gdb users should ask for it explicitly:
sudo dnf install yama-ptrace-enable
cat /proc/sys/kernel/yama/ptrace_scope
The value flips to 0 straight after the install, with no reboot, and both strace -p and gdb -p attach normally. Because it is only a weak dependency of strace, systems with install_weak_deps=False stay at scope 1 even with strace installed. If you would rather keep the stricter default on a laptop you carry around, remove yama-ptrace-enable and use sudo strace -p when you need it.
14. Add OpenSSL 3 libraries before installing VS Code extensions
Fedora 45 moves the system OpenSSL to the 4.x series, and only the 4.x libraries are installed by default:
rpm -q openssl-libs openssl3-libs
On our install the compat package was missing:
openssl-libs-4.0.3-1.fc45.x86_64
package openssl3-libs is not installed
Tools built against libssl 3 break in odd ways without it. The one most developers hit first is VS Code from the Microsoft repo: every extension install fails with Signature verification failed with 'UnknownError', because the bundled vsce-sign helper links against libssl 3. Fedora ships the old library as a separate package, so install it before you set up your editor:
sudo dnf install openssl3-libs
The VS Code on Fedora guide covers the Microsoft repo setup and the extension CLI.
15. Enable SSH only if you need it
Workstation installs OpenSSH server but leaves sshd disabled (checked with systemctl is-enabled sshd on our ISO install before we turned it on). Turn it on if you want to reach the machine from another box:
sudo systemctl enable --now sshd
No firewall change is needed, and that is worth knowing for a laptop that joins coffee-shop Wi-Fi. The default FedoraWorkstation zone already allows SSH and every port from 1025 to 65535:
sudo firewall-cmd --zone=FedoraWorkstation --list-all
This excerpt from our ISO-installed Workstation shows the services and ports lines:
FedoraWorkstation (default, active)
target: default
services: dhcpv6-client samba-client ssh
ports: 1025-65535/udp 1025-65535/tcp
For anything beyond a home network, set key-only authentication and tighten that zone; the firewalld guide for Fedora and the Fedora hardening checklist cover both. The full walkthrough, including the Settings toggle and key setup, is in enabling the SSH server on Fedora Workstation.
16. Set up Btrfs snapshots before you need them
Workstation lays out a single Btrfs partition with root and home subvolumes, compressed with zstd level 1, and a separate ext4 /boot:
findmnt -t btrfs -o TARGET,SOURCE,OPTIONS
Both subvolumes mount from the same partition:
TARGET SOURCE OPTIONS
/ /dev/sda3[/root] rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/root
└─/home /dev/sda3[/home] rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/home
That layout is ready for snapshots, but nothing takes them by default and snapper is not installed. With the NVIDIA akmod, freeworld Mesa and third-party repos now in place, a pre-update snapshot is cheap insurance. The Snapper and grub-btrfs setup adds automatic snapshots on every dnf transaction and a boot menu entry to roll back into.
What changed from the Fedora 44 checklist
If you are working from the Fedora 44 post-install list or muscle memory, these are the steps that behave differently on Fedora 45:
| Task | Fedora 44 habit | Fedora 45 result | Do this instead |
|---|---|---|---|
| Install RPM Fusion | sudo rpm -ivh the release RPMs | Fails with NOKEY | sudo dnf install the same URLs |
| Find repo files | ls /etc/yum.repos.d | Fedora repos missing there | Look in /usr/share/dnf5/repos.d |
| Popular extensions | Fedora gnome-shell-extension-* packages | “OUT OF DATE” from the base repo | Update first so dnf picks the GNOME 51 builds |
| Attach strace/gdb | Worked after install | EPERM until yama-ptrace-enable lands | sudo dnf install yama-ptrace-enable |
| VS Code extensions | Installed from the marketplace | Signature verification failed with 'UnknownError' | sudo dnf install openssl3-libs |
| Password storage | gnome-keyring | oo7-daemon | Nothing, verify with busctl |
The rest of what we tested here (Flathub, fwupdmgr, TuneD power modes) behaves as it did on Fedora 44, and the freeworld VA-API drivers only need the Mesa versions to line up, as item 6 shows. If you only fix one habit, make it the rpm one: reach for dnf install ./file.rpm, or import the vendor key before using rpm -i.
So many great tips and information – thank you guys so much!!
Glad it helped. Section 16 covers the same setup on Fedora 45 with Snapper and grub-btrfs, so you can roll back from the GRUB menu: https://computingforgeeks.com/btrfs-snapper-grub-btrfs-fedora/