You just wiped Windows and installed Fedora
You just wiped your old OS, booted from a USB drive, and watched the GNOME desktop load for the first time. The terminal is open, the package manager is waiting, and you want to know what you actually installed. You are not looking for a marketing brochure. You want to know how the system works, why it behaves the way it does, and what to do next.
What Fedora actually is
Fedora is a community-driven Linux distribution sponsored by Red Hat. It functions as the upstream testing ground for Red Hat Enterprise Linux. New kernel features, desktop environment updates, and system library improvements land in Fedora first. They get stress-tested by thousands of developers and desktop users. Once they prove stable, they graduate into RHEL. You are running the bleeding edge, but the edge is carefully sanded down before it ships.
The system prioritizes strong defaults over endless configuration menus. SELinux runs in enforcing mode from day one. Wayland handles your display server. systemd manages your services. You do not need to patch these components manually. They work together out of the box. The philosophy is simple: ship modern software, enforce security boundaries, and let the package manager handle dependencies.
Think of Fedora like a well-maintained public transit system. The routes are fixed, the schedules are published, and the vehicles are updated on a strict timetable. You do not build the tracks. You just show up, tap your card, and move forward.
Trust the defaults. Manual tweaks drift over time, but the package manager keeps the base intact.
The first commands you should run
A fresh install needs two things: a full update to catch post-build patches, and a third-party repository for proprietary codecs and hardware drivers. Fedora ships with a clean base. It does not include patented media formats or closed-source GPU drivers by default. You add those yourself.
Here is how to apply the latest security patches and kernel updates.
sudo dnf upgrade --refresh -y
# --refresh forces dnf to ignore cached metadata and fetch fresh repo data
# -y skips the interactive confirmation prompt for automation
# Run this weekly. It keeps your system aligned with the current release.
Next, you need RPM Fusion. This is the community-maintained repository that fills the gaps Fedora intentionally leaves open. It provides multimedia codecs, NVIDIA drivers, and games that require non-free dependencies.
Here is the command to enable both the free and non-free RPM Fusion repositories.
sudo dnf install -y \
https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
# rpm -E %fedora resolves to your current release number automatically
# The free repo contains open-source drivers and codecs
# The nonfree repo contains proprietary blobs like NVIDIA and Steam
After enabling RPM Fusion, refresh the package cache so dnf knows what is available.
sudo dnf makecache
# Rebuilds the local database of available packages
# Required after adding or removing repositories
Verify your installation by checking the release file. The file lives in /etc/, which is the standard location for user-modified configuration. Files in /usr/lib/ ship with packages and should never be edited directly.
cat /etc/fedora-release
# Prints the exact version string, e.g., Fedora release 41 (Forty One)
# Use this output when searching for version-specific bugs
Run dnf upgrade --refresh before you install anything else. A fresh base catches post-release patches that fix early boot glitches.
How the release cycle works
Fedora ships a new major release every six months. Each release receives updates for approximately thirteen months. When the next major version lands, the current one enters its final update phase. Two versions later, the old release reaches end of life. The N-2 rule applies strictly. You cannot keep running Fedora 39 while Fedora 41 is current.
This cadence means you will perform a major upgrade roughly once a year. The process uses dnf system-upgrade, not dnf upgrade. The two commands do different things. dnf upgrade updates packages within the current release. dnf system-upgrade downloads a full transaction, reboots into a special upgrade environment, and replaces the base system. Mixing them up breaks the transaction.
Here is how to check whether an upgrade path exists for your current release.
dnf system-upgrade download --releasever=$(rpm -E %fedora + 2)
# Calculates the next supported major release number
# Downloads all required packages without applying them yet
# Verify the output before running the reboot step
The six-month cycle keeps your kernel modern. Hardware support improves with every release. Wi-Fi chips, NVMe controllers, and display drivers that failed on Fedora 40 often work perfectly on Fedora 42. You do not need to compile custom kernels or manage DKMS trees manually. The upstream packages handle it.
Plan your major upgrades around the release calendar. Snapshot the system before the upgrade. Future-you will thank you.
Common pitfalls and what the error looks like
New users often run into three specific issues during the first week. Knowing the exact error message saves hours of forum digging.
The first issue is SELinux blocking a custom service or application. You will see a denial in the journal that looks like this:
type=AVC msg=audit(1715432100.123:456): avc: denied { read } for pid=1234 comm="myapp" name="config.json" dev="sda1" ino=789012 scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file permissive=0
Do not disable SELinux. The denial tells you exactly which process tried to access which file and why the policy blocked it. Run journalctl -t setroubleshoot to get a human-readable summary. The x and e flags in journalctl -xe add explanatory context and jump to the end of the log. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Fix the file context with restorecon or write a custom policy. Never drop to permissive mode on a desktop.
The second issue is a missing dependency after enabling RPM Fusion. The package manager will refuse to proceed and print Error: Transaction test error: package nvidia-driver conflicts with kernel-modules-extra. The conflict is intentional. Fedora separates kernel modules from the base kernel package. You need to install the matching development headers before compiling or installing proprietary drivers.
The third issue is confusing dnf flags. Users often type sudo dnf update instead of sudo dnf upgrade. In modern Fedora, update is an alias, but upgrade is the canonical command. Stick to upgrade to avoid confusion with older documentation. Always check systemctl status <unit> before restarting a service. The status output shows recent log lines and the current state in one view. Guessing breaks recovery.
Run journalctl -xe first. Read the actual error before guessing. SELinux denials and dependency conflicts are features, not bugs.
Which Fedora edition fits your workflow
Fedora ships in several flavors. Each one targets a different use case. Pick the one that matches your daily driver.
Use Fedora Workstation when you need a traditional desktop with a mutable filesystem and full access to dnf for installing kernel modules or development tools. Use Fedora Server when you are running headless services, databases, or containers and do not want the overhead of a desktop environment. Use Fedora Silverblue when you want a known-good base image you can always roll back to, and you are comfortable with rpm-ostree for layering packages. Use Fedora Kinoite when you prefer the KDE Plasma desktop but still want the immutable, atomic update model. Stay on the upstream Workstation if you only deviate from the defaults occasionally and want the broadest community support.
The immutable editions use a read-only root filesystem. You install software via rpm-ostree install or containers. The system reboots into a new transactional state. If an update breaks something, you roll back to the previous boot entry in GRUB. The mutable editions use traditional dnf transactions. You can edit files in /etc/ and install packages directly. Both models are production-ready. They just manage state differently.
Match the edition to your tolerance for system state changes. Immutable for stability, mutable for flexibility.