How to Reinstall a Package on Fedora Using DNF
You upgraded from Fedora 40 to 41 and now your web server refuses to start. Or you accidentally deleted a binary in /usr/bin and the package manager reports the package is installed but the file is gone. You need to restore the original files without risking a dependency cascade that could remove half your system. The instinct is to uninstall the package and install it again. That approach is dangerous. Removing a package can trigger DNF to remove other packages that depend on it, leaving you with a broken system. The safe path is dnf reinstall.
What's actually happening
Fedora uses the RPM package manager under the hood, and DNF is the transactional frontend that talks to RPM. Every package installs a set of files with specific checksums, permissions, ownership, and SELinux contexts. The RPM database, stored in /var/lib/rpm, tracks every file on the system. When you run dnf reinstall, DNF downloads the package again and instructs RPM to overwrite the files on disk. The package remains marked as installed. The dependency graph is untouched. No other packages are removed.
Think of reinstalling like swapping a worn-out tire. You do not strip the car down to the chassis to put a new tire on. You just swap the tire. dnf reinstall refreshes the files while keeping the car driving. dnf remove followed by dnf install is like selling the car and buying a new one. You might get the same model, but you risk losing your license plates, your custom radio, and the keys to the garage.
Reinstalling also restores SELinux security contexts on the package files. If a file's context got corrupted, reinstalling the package fixes the label automatically. This is often faster than running restorecon manually.
Run rpm -V before you reinstall. If the package is fine, you are chasing ghosts.
The fix
Here's how to reinstall a single package safely. Replace firefox with the name of the package you need to fix.
sudo dnf reinstall firefox # Downloads the package and overwrites files without removing dependencies
If the command fails with a checksum error or cannot find the package, your local metadata might be stale. Force a metadata refresh to ensure DNF fetches the latest information from the repositories.
sudo dnf reinstall --refresh firefox # Forces metadata download to resolve checksum or version mismatches
If you are reinstalling multiple packages, list them all on one line. DNF processes them in a single transaction.
sudo dnf reinstall firefox chromium # Reinstalls both packages in one transaction to save time and bandwidth
If DNF reports that the package is already the newest version but you still suspect corruption, clean the local cache. The cache might hold a broken download or a corrupted metadata file.
sudo dnf clean all # Clears local metadata and package cache to resolve download or checksum errors
sudo dnf reinstall firefox # Retry the reinstall with a fresh cache
Reinstall preserves configs. If you need a clean config, remove and install instead.
Verify it worked
Reinstalling does not give you a success message that proves the files are correct. You need to verify the package integrity against the RPM database. Use rpm -V to check checksums, permissions, and ownership.
rpm -V firefox # Verifies file checksums, permissions, and ownership against the RPM database
The command produces no output if the package is pristine. If there are differences, rpm -V prints a line for each affected file. The output starts with a string of flags followed by the file path.
SM5....T. c /etc/firefox/sys-prefs.js
Each character in the flag string indicates a specific type of mismatch. A dot means the check passed. A letter means the check failed.
S: File size differs.M: Mode differs, including permissions and file type.5: MD5 sum differs.D: Device major/minor number mismatch.L: Symbolic link differs.U: User ownership differs.G: Group ownership differs.T: Modification time differs.
The character after the flags indicates the file type. c means a config file. %doc means documentation. If you see SM5....T. c /etc/firefox/sys-prefs.js, the size, mode, digest, and time differ on a config file. This is expected if you edited the config manually. Reinstalling does not overwrite modified config files in /etc. The package manager assumes you know what you are doing when you edit files in /etc.
If you see mismatches on files in /usr/lib or /usr/bin, the reinstall likely failed or was interrupted. Run the reinstall again. If the mismatches persist, the repository might be serving a corrupted package. Report the issue to the Fedora bug tracker.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
The most common mistake is using dnf remove followed by dnf install. This approach risks dependency removal. DNF will propose to remove packages that depend on the target package. If you confirm, you might lose critical system components.
Error: Transaction test error:
package system-config-printer-1.5.18-1.fc41.x86_64 requires cups, but none of the providers can be installed
This error appears when you try to remove a package that other packages need. DNF refuses to proceed because it would break the system. If you see this, stop. Use dnf reinstall instead.
Another pitfall is expecting reinstall to reset configuration files. It does not. If you broke a config file in /etc, reinstalling the package will not fix it. The package manager protects user modifications. You must manually restore the default config or remove and reinstall the package.
When you remove a package, DNF keeps modified config files as .rpmnew or .rpmsave files. If you reinstall after removing, DNF might create a .rpmnew file containing the new default config. You need to compare and merge these files manually.
diff /etc/ssh/sshd_config /etc/ssh/sshd_config.rpmnew # Compares your config against the new default to identify changes
If you see Permission denied errors when accessing files after a reinstall, check SELinux. The contexts might be wrong. Reinstalling usually fixes this, but if the issue persists, run restorecon on the affected directory.
sudo restorecon -Rv /etc/ssh # Restores default SELinux contexts recursively with verbose output
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
When to use this vs alternatives
Use dnf reinstall when you need to restore missing binary files or reset SELinux contexts without risking dependency removal. Use dnf remove followed by dnf install when you want to discard all modified configuration files in /etc and start fresh. Use dnf downgrade when the current version is broken and you need to revert to a previous release. Use rpm -V when you suspect file corruption and need to verify package integrity before taking action. Use dnf clean all when reinstall fails with checksum errors or metadata mismatches. Use restorecon when SELinux contexts are wrong but the package files are intact.
Snapshot the system before the upgrade. Future-you will thank you.