Skip to content

Fedora Networking & Kernel Troubleshooting

Two common issues on the MajorsHouse Fedora fleet (majorlab, majorhome): network connectivity dropping after updates or reboots, and kernel upgrades that break things. These are the quick fixes and the deeper recovery paths.

Networking Drops After Reboot or Update

Quick Fix

If a Fedora box loses network connectivity after a reboot or dnf upgrade, NetworkManager may not have brought the connection back up automatically:

nmcli connection up "Wired connection 1"

This re-activates the default wired connection. If the connection name differs on your system:

# List all known connections
nmcli connection show

# Bring up by name
nmcli connection up "your-connection-name"

Why This Happens

  • NetworkManager may not auto-activate a connection if it was configured as manual or if the profile was reset during an upgrade.
  • Kernel updates can temporarily break network drivers, especially on hardware with out-of-tree modules. The new kernel loads, the old driver doesn't match, and the NIC doesn't come up.
  • On headless servers (like majorlab and majorhome), there's no desktop network applet to reconnect — it stays down until you fix it via console or IPMI.

Make It Persistent

Ensure the connection auto-activates on boot:

# Check current autoconnect setting
nmcli connection show "Wired connection 1" | grep autoconnect

# Enable if not set
nmcli connection modify "Wired connection 1" connection.autoconnect yes

Kernel Issues — Booting an Older Kernel

When a new kernel causes problems (network, storage, GPU, or boot failures), boot into the previous working kernel via GRUB.

At the GRUB Menu

  1. Reboot the machine.
  2. Hold Shift (BIOS) or press Esc (UEFI) to show the GRUB menu.
  3. Select Advanced options or an older kernel entry.
  4. Boot into the working kernel.

From the Command Line (Headless)

If you have console access but no GRUB menu:

# List installed kernels
sudo grubby --info=ALL | grep -E "^(index|kernel|title)"

# Set the previous kernel as default (by index)
sudo grubby --set-default-index=1

# Or set by kernel path
sudo grubby --set-default=/boot/vmlinuz-6.19.9-200.fc43.x86_64

# Reboot into it
sudo reboot

Remove a Bad Kernel

Once you've confirmed the older kernel works:

Never remove the running kernel — confirm first

dnf remove kernel-core-<ver> will happily remove the kernel you are booted on, leaving an unbootable system. Always confirm the version you're removing is not uname -r:

uname -r                                  # the kernel you are ON — do NOT remove this
rpm -qa kernel-core | sort -V             # all installed; pick a DIFFERENT one to remove

(The 6.19.10-200.fc43 in the example below is illustrative — Fedora 44 fleet hosts run 7.1.x. Substitute the actual broken version you verified above.)

# Remove the broken kernel — NOT the one uname -r reports
sudo dnf remove kernel-core-6.19.10-200.fc43.x86_64

# Verify GRUB updated
sudo grubby --default-kernel

Prevent Auto-Updates From Reinstalling It

If the same kernel version keeps coming back and keeps breaking:

# Temporarily exclude it for a single upgrade run (preferred — scoped, self-clearing)
sudo dnf upgrade --exclude=kernel*

Do NOT blindly append excludepkgs=kernel* to dnf.conf — corrected 2026-07-20

A persistent excludepkgs=kernel* in /etc/dnf/dnf.conf freezes ALL kernel updates indefinitely, including security patches — and it's easy to forget it's there. On a SELinux-enforcing, internet-facing host that is a real exposure. The earlier echo ... | tee -a form was worse still: it blind-appends with no check that the line lands under the [main] section, so on some configs it silently does nothing while looking applied.

Pin a single specific version, not the whole kernel* glob, and set a reminder to remove it:

# Exclude ONE known-bad version, leaving future kernels (and security fixes) flowing:
sudo dnf versionlock add kernel-core-6.19.10-200.fc43   # needs python3-dnf-plugin-versionlock
# ...or if you must edit dnf.conf, target the exact version and confirm placement:
sudo dnf config-manager --save --setopt=excludepkgs=kernel-core-6.19.10-200.fc43
grep -A1 '^\[main\]' /etc/dnf/dnf.conf   # verify the exclude landed under [main]

Remove the pin once a working newer kernel ships — a permanent kernel freeze is not a fix, it's deferred risk.

Remove the exclusion once a fixed kernel version is released.

Quick Diagnostic Commands

# Check current kernel
uname -r

# Check network status
nmcli general status
nmcli device status
ip addr show

# Check if NetworkManager is running
systemctl status NetworkManager

# Check recent kernel/network errors
journalctl -b -p err | grep -iE "kernel|network|eth|ens|nm"

# Check which kernels are installed
rpm -qa kernel-core | sort -V

Gotchas & Notes

  • Always have console access (IPMI, physical KVM, or Proxmox console) for headless servers before doing kernel updates. If the new kernel breaks networking, SSH won't save you.
  • Fedora keeps 3 kernels by default (installonly_limit=3 in /etc/dnf/dnf.conf). If you need more fallback options, increase this number before upgrading.
  • Test kernel updates on one server first. Update majorlab, confirm it survives a reboot, then update majorhome.
  • grubby is Fedora's preferred tool for managing GRUB entries. Avoid editing grub.cfg directly.

Reference: Fedora — Working with the GRUB 2 Boot Loader

See Also