Os Fedora

Overview

Research baseline: 2026-09-05, Fedora Linux 44 stable; Fedora 45 remains prerelease. 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.
• 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

• Fedora 44 release and release support duration
• Fedora 45 scheduled milestones
• Fedora's DNF5 transition
• DNF5 reference and check-upgrade exit status
• Atomic Desktop 44 deployment status
• bootc deployment detection and persistent filesystem semantics
• NetworkManager and rootless Podman
• Toolbx host integration