You upgraded Fedora and the network is dead
You ran dnf system-upgrade to move from Fedora 40 to 42. The progress bar finished. You rebooted. The desktop loads, but the Wi-Fi icon shows a red cross, or the Ethernet link light is dark. You are stuck. You cannot download drivers. You cannot check the wiki. The system is up, but it is isolated.
This is a common post-upgrade scenario. Fedora's six-month release cadence means kernel updates, udev rule changes, and package refreshes happen frequently. A major version jump amplifies the risk of configuration drift. The network stack is healthy. The mapping between hardware and software is broken.
What is actually happening
An upgrade changes more than package versions. It swaps the kernel, updates udev rules, and refreshes configuration files. NetworkManager stores connection profiles that often bind to specific interface names or MAC addresses. If the kernel renames your interface from eth0 to enp3s0, the profile points to a ghost. NetworkManager sees the profile, sees no matching device, and refuses to activate.
If you use a proprietary Wi-Fi driver, the kernel module must rebuild against the new kernel headers. The new kernel has a different ABI. The old module binary is incompatible. If the rebuild fails or hasn't run, the hardware is invisible to the OS. The interface does not appear in ip link show.
Firewalld assigns interfaces to zones based on name or MAC address. If the interface name changes, the zone assignment can reset. The new interface might fall into the block zone, dropping all traffic even if the link is up.
Read the log before guessing. The error message tells you exactly which profile or device is misbehaving.
Check the service and logs
Start by verifying NetworkManager is running and checking for errors. The journalctl command is your primary tool. Use the -xe flags to get explanatory text and jump to the end of the log. Add -u NetworkManager to filter for the service.
Here is how to check the daemon state and recent errors.
# Check the status of NetworkManager and recent log lines
sudo systemctl status NetworkManager
# Review detailed logs with explanatory context
journalctl -xeu NetworkManager
# Look for lines marked [FAILED] or "Error"
# If you see "Connection activation failed", the profile is likely stale
# If you see "Device not managed", the interface name might have changed
If the service is dead, restart it. If it crashes immediately, the logs will point to a bad configuration file. Config files in /etc/NetworkManager/ are user-modified. Files in /usr/lib/NetworkManager/ ship with the package. Edit /etc/. Never edit /usr/lib/. Manual edits in /usr/lib/ drift and get overwritten on upgrade.
Run journalctl -xe first. Read the actual error before guessing.
Verify interface visibility
You need to know if the kernel sees the hardware and if NetworkManager claims it. ip link show lists all interfaces known to the kernel. nmcli device status shows how NetworkManager views the hardware.
Here is how to compare kernel visibility with NetworkManager state.
# List all network interfaces and their current state
ip link show
# Check how NetworkManager views the hardware
nmcli device status
# If the device shows as "unmanaged", NetworkManager is ignoring it
# If the device is missing entirely, the kernel driver is not loaded
# If the device shows as "disconnected", the profile is inactive or broken
If the interface is missing from ip link show, the driver is not loaded. Proceed to the driver rebuild section. If the interface is present but nmcli shows unmanaged, NetworkManager is configured to ignore it. Check /etc/NetworkManager/NetworkManager.conf for unmanaged-devices entries.
nmcli device status is faster than GUI tools when you are troubleshooting. It shows the state NetworkManager cares about, not just the kernel state.
Fix profile and interface mismatch
The most common cause is a stale profile. Fedora uses predictable network interface names by default. This policy maps names to physical attributes like PCI slot location. Kernel updates can change enumeration order. A module update can shift naming logic. The result is a name change that breaks saved profiles.
Here is how to list profiles and update the interface binding.
# List all saved connection profiles
nmcli connection show
# Find the profile bound to the old interface name
# Update the profile to match the current interface name
nmcli connection modify "Wired connection 1" connection.interface-name enp3s0
# Activate the corrected profile
nmcli connection up "Wired connection 1"
The connection.interface-name property binds the profile to a specific hardware interface. If this property is set to a name that no longer exists, the profile becomes inert. You can also remove the binding entirely by setting the property to an empty value, which allows the profile to activate on any interface with the matching MAC address.
If you see Error: Connection activation failed: No suitable device found for this connection, the profile references an interface name that does not exist. Check ip link show and update the profile.
Update the profile name to match the hardware. NetworkManager will not guess your intent.
Rebuild Wi-Fi drivers
Wi-Fi cards from Broadcom or Realtek often rely on out-of-tree kernel modules provided by RPM Fusion. These modules compile against kernel headers. A new kernel requires a rebuild. akmods automates this process. dracut repackages the initramfs to include the new module.
Here is how to check for the module and force a rebuild.
# Check if the wireless module is loaded in the kernel
lsmod | grep -E "brcm|rtl|iwlwifi"
# If the module is missing and you use RPM Fusion, force a rebuild
sudo akmods --force
# Rebuild the initramfs to include the new module
sudo dracut --force
akmods reads the kernel version and compiles the source packages for matching modules. dracut --force ensures the initramfs contains the updated module so it loads early enough during boot. Skipping dracut can cause the module to load too late, leaving the interface unavailable until a manual reload.
Run akmods --force after every kernel update if you use proprietary drivers. This prevents the rebuild from accumulating until you notice the breakage.
Check firewall zones
Firewalld assigns interfaces to zones. A zone defines the trust level and allowed services. An upgrade can reset zone assignments if the interface name changes. If the new interface falls into the default zone, and the default zone is block, traffic is dropped.
Here is how to inspect zones and reassign the interface.
# Check which zone the interface is assigned to
sudo firewall-cmd --get-active-zones
# If the interface is in the "block" zone, move it to "public" or "home"
sudo firewall-cmd --permanent --zone=public --change-interface=enp3s0
# Apply the change to the running firewall immediately
sudo firewall-cmd --reload
Always run firewall-cmd --reload after changing persistent rules. The runtime configuration and the persistent configuration diverge until you reload. Without the reload, the firewall continues to use the old zone assignment.
Trust the firewall rules. Manual packet drops are harder to debug than zone misconfigurations.
Verify the fix
Confirm connectivity and profile state. ping tests the stack end-to-end. nmcli connection show --active confirms the profile is bound and active.
Here is how to validate the connection.
# Test connectivity to an external host
ping -c 4 fedoraproject.org
# Verify the active connection profile
nmcli connection show --active
# Check for DNS resolution
nslookup fedoraproject.org
If ping succeeds but browsers fail, check DNS settings in the profile. If ping fails but the link is up, check the firewall and routing table.
Reboot before you debug. Half the time the symptom is gone after a clean boot cycle.
Common pitfalls and errors
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name or contains a syntax error in /etc/NetworkManager/. Check the journal for the specific parse error.
SELinux denials can block NetworkManager from accessing interfaces. Denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The summary often points to a missing file context or a custom script interfering with the daemon.
The dnf system-upgrade command is for crossing major Fedora releases. dnf upgrade --refresh is for weekly maintenance. They are different commands. Running system-upgrade incorrectly can leave the system in a broken state. Always verify the target release before proceeding.
If the boot menu is gone, GRUB rescue is your friend, not your enemy. You can boot the previous kernel from the GRUB menu to regain access. Hold Shift or Esc at boot to interrupt the countdown.
When to use this vs alternatives
Use nmcli connection modify when the interface name changed but the hardware is the same. Use akmods --force when you use proprietary Wi-Fi drivers and the module is missing after a kernel update. Use firewall-cmd --change-interface when the connection works locally but external traffic is blocked by the zone policy. Use the GRUB menu to boot the previous kernel when the new kernel has a driver regression and you need immediate access to file a bug. Use systemctl restart NetworkManager only when the daemon is hung and logs show no configuration errors. Stay on the upstream Workstation defaults if you only deviate from the defaults occasionally.
Snapshot the system before the upgrade. Future-you will thank you.