MajorLinux
6592eb4fea
- Fixed 4 broken markdown links (bad relative paths in See Also sections) - Corrected n8n port binding to 127.0.0.1:5678 (matches actual deployment) - Updated SnapRAID article with actual majorhome paths (/majorRAID, disk1-3) - Converted 67 Obsidian wikilinks to relative markdown links or plain text - Added YAML frontmatter to 35 articles missing it entirely - Completed frontmatter on 8 articles with missing fields Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
142 lines
4.4 KiB
Markdown
142 lines
4.4 KiB
Markdown
---
|
|
title: "Fedora Networking & Kernel Troubleshooting"
|
|
domain: troubleshooting
|
|
category: networking
|
|
tags: [fedora, networking, kernel, grub, nmcli, troubleshooting]
|
|
status: published
|
|
created: 2026-04-02
|
|
updated: 2026-04-02
|
|
---
|
|
|
|
# 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:
|
|
|
|
```bash
|
|
nmcli connection up "Wired connection 1"
|
|
```
|
|
|
|
This re-activates the default wired connection. If the connection name differs on your system:
|
|
|
|
```bash
|
|
# 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:
|
|
|
|
```bash
|
|
# 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:
|
|
|
|
```bash
|
|
# 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:
|
|
|
|
```bash
|
|
# Remove the broken kernel
|
|
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:
|
|
|
|
```bash
|
|
# Temporarily exclude it from updates
|
|
sudo dnf upgrade --exclude=kernel*
|
|
|
|
# Or pin in dnf.conf
|
|
echo "excludepkgs=kernel*" | sudo tee -a /etc/dnf/dnf.conf
|
|
```
|
|
|
|
Remove the exclusion once a fixed kernel version is released.
|
|
|
|
## Quick Diagnostic Commands
|
|
|
|
```bash
|
|
# 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](https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/)
|
|
|
|
## See Also
|
|
|
|
- [docker-caddy-selinux-post-reboot-recovery](docker-caddy-selinux-post-reboot-recovery.md)
|
|
- [managing-linux-services-systemd-ansible](../01-linux/process-management/managing-linux-services-systemd-ansible.md)
|