The scenario
You just switched your daily driver to Fedora Workstation. You need a browser that handles modern web standards, syncs with your existing account, and runs without constant workarounds. The default Firefox setup is fine, but your workflow depends on Microsoft Edge. You open the terminal, search for the package, and find a dozen conflicting instructions. Some tell you to download a .deb file. Others point to third-party repositories that haven't been updated in years. You need a clean, repeatable method that plays nicely with dnf and survives system upgrades.
What is actually happening
Fedora uses the RPM Package Manager under the hood, with dnf as the frontend that handles dependencies, repositories, and transaction safety. When you install software from a third-party vendor like Microsoft, you have two choices. You can drop a single RPM file into dnf and let it resolve dependencies on the fly, or you can register the vendor's official repository so dnf pulls updates automatically alongside the rest of your system.
The direct RPM approach works for a quick test, but it leaves you stranded when a security patch drops. dnf will not know where to find the newer version. The repository approach is the standard practice. It registers a .repo file in /etc/yum.repos.d/, imports the vendor's GPG key, and ties the browser into your normal update cycle. Fedora's package manager expects this pattern. It keeps your system consistent and prevents manual file edits from drifting out of sync with package metadata.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. The repository configuration lives in /etc/yum.repos.d/ so you can edit it without breaking package ownership. Never place third-party repo files in /usr/lib/. The package manager will overwrite them during system updates.
Register the repository before you install the package. Future-you will thank you when security updates arrive silently.
The proper installation method
Start by fetching the official Microsoft Edge repository configuration. Microsoft provides a static .repo file that handles the correct base URL for your Fedora release. Writing the file manually ensures you know exactly what gets added to your system. Running the setup requires root privileges because it modifies system configuration directories.
Here is how to download and place the repository file correctly.
# Download the official repository configuration to a temporary location
curl -fsSL https://packages.microsoft.com/config/fedora/$(rpm -E %fedora)/packages-microsoft-prod.repo -o /tmp/microsoft-edge.repo
# Move the repo file to the system configuration directory
sudo mv /tmp/microsoft-edge.repo /etc/yum.repos.d/
# Import the Microsoft GPG signing key so dnf trusts the packages
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
The $(rpm -E %fedora) substitution expands to your current Fedora release number. This ensures the repository URL points to the correct versioned directory. The rpm --import command adds the public key to the system keyring. dnf will refuse to install packages from untrusted sources without this step.
Once the repository is registered, install the browser through the package manager. Do not download the RPM manually unless you are troubleshooting a broken network connection.
# Install the stable release of Microsoft Edge
sudo dnf install microsoft-edge-stable
# Accept the GPG key prompt if dnf asks for verification
# Type 'y' and press Enter to continue the transaction
The dnf install command reads the newly added repository, resolves all required libraries, and downloads the package. If you see a prompt asking to import the GPG key, confirm it. This is a one-time step. The package manager caches the key after verification.
Run the installation from a terminal you can keep open. Package managers sometimes ask for confirmation mid-transaction.
Repository metadata and update cycles
Third-party repositories follow their own update cadence. Microsoft pushes browser updates weekly. Fedora updates system libraries on a rolling basis. dnf caches repository metadata to speed up local queries. Stale metadata causes dependency resolution failures when a library bumps its version.
Here is how to refresh the metadata and apply pending updates safely.
# Force dnf to ignore cached metadata and pull fresh repository lists
sudo dnf upgrade --refresh
# Check which packages are pending from the Microsoft repository
sudo dnf repoquery --repo microsoft-edge --available
# Apply the updates after reviewing the package list
sudo dnf upgrade microsoft-edge-stable
The --refresh flag forces dnf to discard local cache files and contact the remote servers. This prevents stale dependency trees from blocking legitimate updates. The repoquery command shows available packages without installing them. Use it to verify the repository is actually returning packages before you run a full system upgrade.
Fedora's release cadence is six months. The N-2 release goes end-of-life when N+1 ships. Third-party vendors usually drop support for older Fedora releases within a few months of the new version landing. Plan your browser updates alongside your system upgrades.
Refresh the metadata before you debug missing packages. Half the time the symptom is a stale cache.
Verify the installation
Run the browser from the terminal once to check for missing dependencies or environment errors. Desktop environments usually create a launcher automatically, but a terminal run reveals startup issues immediately.
# Launch Edge in the background and capture initial output
microsoft-edge-stable --no-sandbox &
# Check the installed version against the repository metadata
microsoft-edge-stable --version
The version output should match the latest stable release listed on Microsoft's release notes. If the version is outdated, your repository configuration might be pointing to an archived directory. Check the contents of /etc/yum.repos.d/microsoft-edge.repo and verify the base URL matches your Fedora release.
If the browser fails to start, check the system journal for library loading errors. The journalctl command shows recent log lines and service state in one view. Always check status before restarting services.
# View recent journal entries filtered by the Edge process name
journalctl -xeu microsoft-edge-stable
# Check for missing shared libraries that prevented startup
ldd $(which microsoft-edge-stable) | grep "not found"
The -x flag adds explanatory text to journal entries. The -e flag jumps to the end of the log. The ldd command lists shared library dependencies and highlights missing ones. Missing libraries usually indicate a mismatch between the browser build and your system's glibc or GTK version.
Read the actual error before guessing. Journal output tells you exactly which symbol or library failed to load.
Common pitfalls and error messages
Third-party repositories occasionally change their directory structure or rotate signing keys. When this happens, dnf stops silently or throws a GPG verification failure. You will see output similar to this during an upgrade:
Error: GPG check FAILED
The GPG keys listed for the "microsoft-edge" repository are already installed but they are not correct here.
Check for incorrect/partial repository definition or corrupted package metadata.
This error means the key in your system keyring no longer matches the one signing the packages. Remove the old key and reimport the current one.
# Remove the outdated Microsoft GPG key from the system keyring
sudo rpm --erase --allmatches gpg-pubkey-78b94502
# Reimport the fresh key from the official source
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
Another common issue is dependency conflicts with system libraries. Fedora updates core libraries frequently. If a library version bumps and Edge expects an older symbol, dnf will refuse the transaction. You will see a message like Error: Transaction test error: package microsoft-edge-stable conflicts with glibc. This is rare for browsers, but when it happens, you need to wait for Microsoft to rebuild the package for the newer Fedora release. Do not force the installation with --skip-broken. Forcing bypasses dependency checks and leaves the system in an inconsistent state.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The browser usually runs fine under the default policy, but custom sandbox configurations can trigger denials.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this approach versus alternatives
Use the official Microsoft repository when you want automatic security updates and seamless integration with dnf. Use the direct RPM download when you are on an air-gapped machine or need to test a specific build without modifying system configuration. Use Flatpak from Flathub when you prefer sandboxed applications that update independently of the host system. Stay on the native RPM package if you need deep system integration, hardware acceleration, or seamless clipboard sharing with the desktop environment.