wiki: add 4 new articles from archive, merge 8 archive notes into existing articles (73 articles)

New: mdadm RAID rebuild, Mastodon instance tuning, Ventoy, Fedora networking/kernel recovery.
Merged: Glacier Deep Archive into rsync, SpamAssassin into hardening checklist,
OBS captions/VLC capture into OBS setup, yt-dlp subtitles/temp fix into yt-dlp.
Updated index.md, README.md, SUMMARY.md with 21 previously missing articles.
Fixed merge conflict in index.md Recently Updated table.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

05-troubleshooting/fedora-networking-kernel-recovery.md

@@ -0,0 +1,141 @@
+---
+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]]
+- [[managing-linux-services-systemd-ansible]]