Diagnose and maintain Fedora systems with release-aware DNF5, Atomic deployment, SELinux, networking, and rootless container guidance.

Apache-2.0 Requires access to the target Fedora system or its configuration and logs; administrative changes require appropriate privileges.

Instructions

Overview

Research baseline: 2026-10-12, Fedora Linux 44 stable; Fedora 45 is in final freeze for an October 2026 release (secondary reports give a 2026-10-20 target). A release stays supported until about four weeks after the release two versions newer, so Fedora 43 ends shortly after Fedora 45 ships. Recheck release status before upgrades. Apply the Linux baseline for shared host/container, systemd, and resource diagnostics.

Mental model

Fedora is a short-lifecycle distribution with multiple deployment models. Identify the installed edition, release, repository/image origin, and booted deployment before choosing commands. Traditional RPM hosts, Atomic desktops, CoreOS, and bootc-derived images do not share one universal update procedure.

Releases and DNF5

Fedora releases receive approximately thirteen months of updates. Check the target's support status rather than assuming an installed release remains maintained. Rawhide, Branched, beta, and updates-testing are separate development/testing choices, not repair repositories.
Traditional Fedora uses DNF5 by default since Fedora 41. Check dnf --version and installed command help; DNF4 Python APIs, plugins, options, and history behavior are not interchangeable with DNF5.
Query installed packages and enabled repository configuration before a transaction. Preserve signatures, release matching, and intentional third-party sources. A missing dependency is a reason to inspect provenance and availability, not mix Fedora versions or RHEL/EPEL packages.
DNF5 check-upgrade returns 100 when upgrades are available and 0 when none are found. Treat real errors separately; || true hides failed checks. Repository queries may refresh metadata, so prefer installed-package queries for strictly local inventory.
Fedora 45 enforces RPM signature verification by default (%_pkgverify_level all): unsigned or unknown-key packages fail with direct rpm -i/-U. Import the publisher's key or sign local builds; don't lower the verification level globally to make an install pass.
Major release upgrades use the documented upgrade workflow, not a routine package refresh. Review proposed removals and third-party compatibility; flags such as --allowerasing can change the outcome substantially.
Keep a known bootable kernel/deployment and account for out-of-tree module compatibility when planning updates. Do not remove older kernels or disable Secure Boot simply because a driver failed to load.

Atomic and image deployments

Fedora Atomic Desktop 44 still documents rpm-ostree layering; bootable-container work does not mean every installation has switched to bootc. Inspect rpm-ostree status and, where available, bootc status --format=json before choosing a mutation tool.
An installed bootc binary alone is not deployment evidence. Inspect the booted image and any incompatibility flag; layered packages can require rpm-ostree for mutations even when bootc is present.
For an rpm-ostree deployment, distinguish booted, pending, and rollback deployments. Package layering creates a new deployment; do not repeatedly reinstall into the running root because the pending change is not yet active.
For an image-managed deployment, update the intended image source/digest through its existing pipeline. Do not convert the machine's update model or switch its image origin as incidental troubleshooting.
Use Flatpak for suitable desktop applications and Toolbx/containers for development dependencies where that matches the deployment. Reserve host layering for software that needs host integration. Toolbx is an integrated environment, not a strong sandbox for untrusted code.
Rollback restores OS deployment content, not arbitrary user/database data. Persistent /var state is shared across deployments; schema migrations and application downgrades need their own compatibility plan.
A read-only system path may be intentional. Modify image/build configuration or supported persistent configuration rather than remounting the system writable to bypass its model.

Diagnose the failing layer

Query NetworkManager's active profile, routes, and DNS ownership before changing settings. A profile edit does not necessarily alter the currently active connection; protect remote management access when applying changes.
Correlate application logs with SELinux AVC records, ownership, mount flags, and file labels. Fix a documented label/boolean/port mismatch when justified; do not disable SELinux, firewalling, or signature verification as a default remedy.
For rootless Podman, inspect the user's storage, UID mapping, volume labels, and cgroup delegation. Sudo selects a different container context, not a transparent permission fix.
Check the installed runtime and network backend rather than importing older Docker/CNI recipes. Confirm service restart behavior and persistent volumes independently of a successful container start.

Diagnostic example

Read-only local inventory on a Fedora host with these utilities installed:

cat /etc/os-release
uname -r
rpm -q fedora-release dnf5 rpm-ostree bootc
findmnt /
nmcli connection show --active
getenforce

An absent package is evidence, not an instruction to install it. Inspect deployment status next only with the relevant installed tool; retain failures rather than silently selecting another updater.

Checklist

Confirm supported release and stable versus development content.
Identify traditional or image deployment and the actual booted/pending state.
Preserve package/image provenance and review transaction removals.
Diagnose security, network, and rootless permissions without blanket bypasses.
State what was observed, what changed, and whether reboot, rollback, and application behavior were verified.

References

View on GitHub