You upgraded Fedora and now the system feels sluggish
You ran sudo dnf upgrade last night. The transaction completed without errors. You rebooted. Now your desktop lags when you move windows, the terminal takes a moment to respond, and the fan is spinning up for no reason. The system isn't broken. It's just confused.
Fedora updates change the kernel, swap libraries, and trigger background tasks that can temporarily tax your hardware. The slowdown is usually a symptom of a pending state, not a permanent regression. The package manager installed the new files, but the system hasn't finished reconciling them. The kernel might be old. Background indexers might be scanning your home directory. The initramfs might be missing a module. Swappiness might be pushing RAM to disk too aggressively.
Think of an update like renovating a house while you're still living in it. The new walls are up, but the painters are still working in the hallway. The plumber is rerouting pipes. You can walk through, but you have to dodge buckets and wait for the ladder to move. In Fedora terms, the fix is to let the system finish its work, or nudge it in the right direction.
Reboot before you debug. Half the time the symptom is gone.
Verify the running kernel
DNF installs the new kernel package but does not reboot the system. You can be running an old kernel while the new one sits in the boot menu. The old kernel might lack performance fixes, driver updates, or security patches that the new kernel provides.
Here's how to check whether the running kernel matches the latest installed version.
uname -r
# Shows the version of the kernel currently executing.
# Copy this string to compare with the installed list.
rpm -q kernel --last | head -3
# Lists the most recently installed kernel packages.
# If the top line is newer than uname -r, you are running an old kernel.
If the installed version is newer, the new kernel is waiting for you. Load it immediately.
sudo reboot
# Restarts the system and loads the default kernel entry.
# GRUB usually selects the newest kernel automatically.
# Wait for the system to come back up before running further checks.
Reboot before you debug. Half the time the symptom is gone.
Synchronize the package database
Partial updates or interrupted transactions can leave orphaned files or mismatched libraries. The package database might be stale, causing DNF to make incorrect dependency decisions. Fedora's release cadence is six months, and the N-2 release goes EOL when N+1 ships. Keeping the database fresh ensures you are pulling from the correct repos.
dnf upgrade --refresh is the normal weekly maintenance command. It forces a metadata refresh and applies any remaining updates. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Here's how to ensure the package state is fully consistent.
sudo dnf upgrade --refresh
# Forces metadata refresh and applies any remaining updates.
# --refresh ignores cached metadata to ensure you see the latest repo state.
# This catches packages that were skipped due to lock files or network hiccups.
sudo dnf distro-sync
# Aligns installed packages with the current release version.
# Downgrades or upgrades packages if they drifted from the repo baseline.
# Use this after a major update or if you suspect library mismatches.
Run dnf upgrade --refresh weekly. It catches drift before it becomes a problem.
Check for background resource consumers
After an update, several background services wake up to adapt to the new system state. akmods recompiles kernel modules for hardware drivers. tracker-miner-fs reindexes your home directory for file search. dnf might be running an automatic background update check. These processes consume CPU and I/O while you try to work.
Killing these processes is counterproductive. akmods will restart and leave you with unsigned modules. tracker will restart and reindex from scratch. Let them finish, or verify they are the cause.
Here's how to identify which process is holding your resources hostage.
sudo dnf install htop
# Installs a colorized process viewer with tree view support.
# htop provides a much clearer view than the default top command.
htop
# Launches the interactive viewer. Press F5 to show process trees.
# Look for high CPU% or MEM% in the top rows.
# Sort by CPU by pressing F6 and selecting PERCENT_CPU.
If akmods is running, wait for it to finish. The compilation time depends on your CPU and the number of modules. If tracker-miner-fs is running, it will settle down once the index is complete. You can pause it temporarily if you need immediate responsiveness, but the index will rebuild later.
Wait for akmods to finish. Killing the build process leaves you with unsigned modules and a broken driver.
Inspect disk I/O pressure
High I/O wait can make a system feel frozen even if the CPU is idle. The disk is the bottleneck. Common culprits are filesystem checks, updatedb running, or a bloated journal consuming disk space and slowing log rotation.
iostat shows extended disk statistics. The %iowait column indicates how much time the CPU spends waiting for disk I/O. Values above 20% suggest disk pressure.
Here's how to check if the disk is causing the slowdown.
sudo dnf install sysstat
# Provides iostat and other performance monitoring tools.
# sysstat is not installed by default on minimal spins.
iostat -x 2 3
# Reports extended disk stats every 2 seconds for 3 iterations.
# Watch the %iowait column. Values above 20% indicate disk pressure.
# High await values point to slow disk response or heavy queue depth.
High I/O wait is normal for the first five minutes after a reboot. Let the indexers finish.
Vacuum the systemd journal
The systemd journal stores logs in binary files under /var/log/journal. After updates, the journal can grow rapidly as services restart and emit status messages. A bloated journal consumes disk space and can slow down boot and log rotation. If the disk fills up, performance degrades significantly.
Check the journal size and trim it if necessary.
journalctl --disk-usage
# Shows how much space the persistent journal occupies.
# A bloated journal can slow down boot and log rotation.
# Usage above 1 GB is uncommon on desktop systems.
sudo journalctl --vacuum-size=500M
# Truncates old logs to keep usage under 500 MB.
# This is safe. Old logs are rarely needed for debugging.
# The command removes the oldest entries first.
When debugging boot failures, journalctl -xe is your friend. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> to isolate a specific service.
Trust the package manager. Manual file edits drift, snapshots stay.
Rebuild the initramfs
The initramfs is a temporary filesystem loaded into memory during boot. It contains the drivers needed to mount the root filesystem. If the initramfs is missing modules or has broken symlinks, storage or network drivers might fail to load. This can cause slow boot times or fallback to generic drivers with poor performance.
dracut rebuilds the initramfs. Use this only if you suspect driver issues or if the system hangs at boot.
Here's how to regenerate the initramfs for all installed kernels.
sudo dracut -f --regenerate-all
# Forces regeneration of initramfs images for all installed kernels.
# Fixes missing modules or broken symlinks in the boot image.
# This can take a few minutes depending on kernel count.
# The -f flag overwrites existing images. Use with caution.
Rebuild initramfs only if drivers are missing. A healthy system doesn't need this.
Tune swappiness for high-RAM systems
Swappiness controls the kernel's willingness to move anonymous pages from RAM to swap. Fedora defaults to 60, which is a balanced setting for most workloads. On systems with 8 GB or more RAM, this default can cause the kernel to swap too aggressively, leading to latency when swapped pages need to be read back from disk.
Lowering swappiness tells the kernel to keep more data in RAM. This improves responsiveness on desktop systems with ample memory.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Here's how to check and adjust swappiness.
cat /proc/sys/vm/swappiness
# Reads the current kernel parameter for swap usage.
# Fedora defaults to 60, which can cause latency on systems with ample RAM.
# Values range from 0 to 100. Lower values prefer RAM.
sudo sysctl vm.swappiness=10
# Lowers swappiness temporarily to reduce swap pressure.
# The change lasts until the next reboot.
# This is useful for testing the effect of the change.
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
# Writes the setting to a persistent config file in /etc.
# Files in /etc survive updates. Never edit files in /usr/lib.
# The 99- prefix ensures this file is loaded after default configs.
Lower swappiness only if you see swap activity in htop. Swapping is healthy when RAM is full.
Check thermal throttling and power governors
A kernel update can change the default CPU governor or power management profile. If the governor is set to powersave, the CPU might stay at low frequencies, causing sluggishness. High temperatures can also trigger thermal throttling, reducing CPU speed to protect the hardware.
cpupower inspects and adjusts the governor. lm_sensors reports temperatures.
Here's how to verify power management settings.
sudo dnf install lm_sensors kernel-tools
# Installs hardware monitoring and CPU frequency management tools.
# kernel-tools provides cpupower for frequency control.
sensors
# Displays temperature readings from CPU and chipset sensors.
# Temperatures above 85°C under load suggest cooling issues.
# High temps can cause the kernel to throttle CPU frequency.
cpupower frequency-info
# Shows the current governor and available frequency ranges.
# The governor controls how the CPU scales speed based on load.
# Look for the "current CPU frequency" and "governor" lines.
sudo cpupower frequency-set -g performance
# Sets the governor to performance mode.
# This allows the CPU to run at maximum frequency.
# Use this for compilation or rendering. Revert to schedutil for battery life.
Check thermals before blaming the kernel. A dusty heatsink throttles every kernel equally.
Verify the fix
Run a workload and monitor resources. Open htop and watch the CPU and memory columns. Run iostat to check disk activity. The system should be responsive. No single process should hold 100% CPU. I/O wait should drop to idle levels.
Here's how to confirm the system is stable.
htop
# Reopen htop and monitor CPU and MEM columns for a minute.
# Values should settle. No single process should hold 100% CPU.
# Check the MEM bar. Swap usage should be low or zero.
iostat -x 2 2
# Run iostat again to verify %iowait has dropped.
# Disk activity should return to idle levels.
# Await values should be low. High await indicates disk issues.
Trust the metrics. If htop shows green and the desktop is snappy, the fix worked.
Common pitfalls
Forcing updates breaks things. If you see Error: Transaction test error: package kernel-core-6.x conflicts with kernel-core-6.y, stop. Do not force. This indicates a repo mismatch or a broken third-party repo. Check your enabled repos with dnf repolist. Disable conflicting repos and run dnf distro-sync.
Editing /usr/lib/sysctl.d/ gets overwritten on package updates. Edit /etc/sysctl.d/. The package manager manages /usr/lib/. Your changes in /etc/ persist.
SELinux denials can slow down services if the audit log fills up rapidly. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux is not a performance fix. It removes security.
Killing tracker-miner-fs just restarts it. Let it run. The indexer will finish and then go idle.
When to use each fix
Reboot immediately when the kernel version in rpm -q kernel is newer than uname -r.
Run dnf distro-sync when packages have drifted from the release baseline or you suspect library mismatches.
Lower swappiness when htop shows significant swap usage on a system with 8 GB or more RAM.
Rebuild initramfs with dracut when storage drivers fail to load or the system hangs at boot.
Adjust the CPU governor when cpupower frequency-info shows powersave and you need maximum throughput for compilation or rendering.
Wait five minutes when iostat shows high I/O wait right after a reboot. Background indexers are doing their job.