You rebooted and the network is gone
You rebooted after a dnf upgrade and the desktop loads, but the network icon shows a red X. Or your laptop wakes from sleep and the WiFi list is empty. You try to run dnf update and get Could not resolve host. The panic sets in. You need the network back to fix the system, but the system needs the network to fix itself. This is the classic catch-22 of Linux networking. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
What's actually happening
Network connectivity is a stack of dependencies. The kernel needs a driver to talk to the hardware. The hardware needs a link to the switch or router. The stack needs an IP address to talk to other machines. The stack needs a route to know where to send packets. The stack needs DNS to turn names into addresses. If any layer fails, the whole thing stops.
Think of it like a postal service. The driver is the post office building. The link is the road. The IP is the address on the envelope. The route is the sorting algorithm. DNS is the phone book. If the road is blocked, the address doesn't matter. If the phone book is missing, you can't find the address. You have to check each layer from the bottom up. Fedora uses NetworkManager to manage this stack. NetworkManager talks to the kernel, handles DHCP, and configures systemd-resolved for DNS. When things break, NetworkManager usually logs the exact reason. Read the logs before guessing.
Check the physical link and interface state
Start with the hardware. The kernel must see the interface, and the interface must have a carrier signal.
Here's how to check whether the kernel detects the interface and if the link is active.
ip link show
# List all network interfaces. Look for your device name like enp3s0 or wlp2s0.
# The state line tells you the health. UP means the kernel is ready.
# DOWN means the interface is administratively off. NO-CARRIER means the cable is unplugged or WiFi is off.
# If you see NO-CARRIER, check the physical connection or the hardware switch before typing more commands.
If the interface is DOWN, bring it up. This is a temporary change. It vanishes on reboot.
sudo ip link set <interface> up
# Activate the interface immediately. This tells the kernel to start the driver.
# This does not configure an IP address. It only powers the link layer.
# Run ip link show again to confirm the state changed to UP.
Convention aside: ip commands are transient. They modify the kernel state in memory. NetworkManager writes persistent configuration to /etc/NetworkManager/system-connections/. Files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. If you need a permanent fix, use NetworkManager.
Check the link before the config. Physical layer failures masquerade as driver bugs.
Verify IP configuration and routing
Once the link is up, the interface needs an IP address and a route to the world.
Here's how to verify the interface has an address and a default gateway.
ip addr show <interface>
# Display the address assigned to the interface. Look for an inet line with an IPv4 address.
# If you see fe80::... but no 192.168... or 10.x.x.x, DHCP might be failing.
# The scope global line confirms the address is usable for routing outside the local subnet.
If the address is missing, reactivate the NetworkManager connection profile. This triggers DHCP and applies the route.
nmcli connection show
# List all saved connection profiles. Find the one matching your interface name.
# The NAME column is what you use in the next command. The DEVICE column shows the current binding.
# If the DEVICE column is --, the profile is not active.
nmcli connection up <connection-name>
# Activate the profile. This requests an IP via DHCP and sets up the route.
# NetworkManager writes the config to /etc/NetworkManager/system-connections/.
# If this fails, check the logs. The error usually points to a DHCP timeout or a mismatched interface name.
Check the routing table. Without a default route, you can only talk to devices on the same local subnet.
ip route show
# List all routes. Look for a line starting with default via. This is your gateway.
# If the default route is missing, traffic to the internet has nowhere to go.
# If you see a route but no default, the DHCP server might not be providing a gateway.
If the route is missing and you need immediate access for debugging, add a temporary route.
sudo ip route add default via <gateway-ip>
# Add a default route pointing to your router. Replace <gateway-ip> with your router address.
# This is temporary. It disappears on reboot or when NetworkManager reactivates the connection.
# Use this only to test connectivity. Fix the profile configuration for a permanent solution.
Restart NetworkManager before you restart the machine. The daemon often fixes itself.
Test DNS resolution
If you have an IP and a route, test if names resolve to addresses. Fedora uses systemd-resolved for DNS.
Here's how to isolate DNS failures from routing failures.
ping -c 3 8.8.8.8
# Ping an IP address directly. This bypasses DNS entirely.
# If this works, your routing and IP config are correct. The problem is DNS.
# If this fails, the issue is lower in the stack. Go back to routing.
If the IP ping works, test name resolution.
resolvectl query fedoraproject.org
# systemd-resolved handles DNS on Fedora. This command tests resolution.
# If you get an IP address back, DNS is working. The network is healthy.
# If you get Server returned error NXDOMAIN, the DNS server is rejecting the query.
# If the command hangs, the DNS server is unreachable or the firewall is blocking port 53.
Convention aside: resolvectl is the modern tool. nslookup is legacy. Use resolvectl. Also, /etc/resolv.conf is a symlink managed by systemd-resolved. Editing /etc/resolv.conf directly is a trap. Your changes get overwritten when systemd-resolved restarts. Use resolvectl or NetworkManager settings to change DNS servers.
Run resolvectl status to see which DNS servers are active. If the list is empty, NetworkManager didn't pass DNS info to systemd-resolved. Check the connection profile.
Check the phone book before you blame the road. DNS failures look like network failures until you ping an IP.
Inspect firewall rules
Firewalld can block traffic if the interface is assigned to the wrong zone.
Here's how to check if firewalld is interfering with your connection.
sudo firewall-cmd --get-active-zones
# See which zones are active and which interfaces belong to them.
# The public zone drops incoming traffic by default but allows outbound.
# If your interface is in the drop zone, outbound traffic might also be blocked.
# If the interface is not listed, it might be in the default zone. Check the default zone config.
sudo firewall-cmd --list-all
# Show all rules for the active zone. Look at the target line.
# If the target is DROP, all traffic is dropped unless explicitly allowed.
# The services list shows what is allowed. dhcpv6-client and dns should be present.
# If you added custom rules, verify they match the interface and port.
Convention aside: Run firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge. You might think a rule is applied, but it only exists in memory until the next reboot.
Trust the package manager. Manual file edits drift, snapshots stay.
Read the logs when commands fail
When the commands don't give a clear answer, the logs hold the truth.
Here's how to find the root cause in the journal and kernel messages.
journalctl -xeu NetworkManager
# Show recent logs for NetworkManager with explanatory text.
# The -x flag adds help links. The -e flag jumps to the end.
# Look for errors about DHCP timeouts, driver failures, or profile mismatches.
# Most sysadmins type journalctl -xeu <unit> muscle-memory style.
dmesg | grep -i 'firmware\|link\|eth\|wlan'
# Check kernel messages for hardware issues.
# Firmware errors often appear here when the driver loads but the hardware won't initialize.
# Missing firmware usually requires installing a package like linux-firmware.
# Link errors indicate physical layer problems. Check the cable or antenna.
Convention aside: SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A denial might mean NetworkManager is blocked from accessing a config file. Fix the context, don't disable the policy.
Run journalctl first. Read the actual error before guessing.
Verify the fix
Confirm the network is fully operational.
ping -c 3 fedoraproject.org
# Ping a domain name. This tests the entire stack: link, IP, route, and DNS.
# If you get replies, the network is back.
# If you get 100% packet loss, check the previous steps again.
dnf check-update
# Verify the package manager can reach the repositories.
# This confirms DNS and routing work for Fedora's infrastructure.
# If this fails, check for proxy settings or mirror issues.
Snapshot the system before the upgrade. Future-you will thank you.
Common pitfalls and error patterns
The ping command will refuse to proceed and print ping: connect: Network is unreachable. This error means the interface has no route or the interface is down. Check ip route and ip link. The error is not about the destination. It is about your local stack.
If you see NetworkManager: <error> Connection activation failed: No suitable device found for this connection, your interface name changed. Fedora uses predictable network interface names. An upgrade or hardware change can turn eth0 into enp3s0. The old profile references the old name. Use nmcli connection show to find the mismatch. Edit the profile to match the new interface name.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Boot to a rescue shell and fix the connection profile in /etc/NetworkManager/system-connections/.
If resolvectl query hangs indefinitely, the DNS server is unreachable. Check the firewall. Check the route. Check the DNS server IP in the connection profile.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use ip link set when you need a temporary fix to test a hypothesis before committing to a config change.
Use nmcli connection up when you need to apply a saved profile and trigger DHCP negotiation.
Use nmtui when you are on a headless server and prefer a menu-driven interface over command-line flags.
Use resolvectl when you need to debug DNS resolution and check the status of systemd-resolved.
Use journalctl -xeu NetworkManager when the interface is up but no IP address appears after reactivation.
Use dmesg when the interface is missing entirely and you suspect a driver or firmware failure.
Stay on NetworkManager for desktop and server networking. Avoid ifupdown or manual ip scripts unless you are maintaining legacy infrastructure.