Ubuntu 24.04 下 Realtek RTL8111/8168 网卡频繁掉线与解决方案
在 Ubuntu 24.04 上，我的有线网卡（Realtek RTL8111/8168 系列）经常出现 几分钟就掉线一次 的情况。掉线时系统日志里充斥着 Link DOWN / Lost carrier / DHCP lease lost 的信息，IP 地址会丢失，SSH 会中断，非常影响使用。更新：20260513实际中发现Ubuntu的某些软件/配置/设置等导致了这个问题，再更换为Debian 13系统后，问题得以解决。当时此Debian 13系统连接到了一台运行OpenWrt的，并且启用了固定IP地址，又出现了上述掉线问题。在使用DHCP之后，问题彻底得以解决。以下为此前的排查，但实际效果并不理想，最终使用了Debian 13系统和上述DHCP方案彻底解决了问题本文记录了问题排查过程和最终解决方案。1. 问题现象查看 systemd-networkd 日志，可以看到类似输出：Sep 04 14:12:32 systemd-networkd[754]: enp37s0: Link DOWN Sep 04 14:12:32 systemd-networkd[754]: enp37s0: Lost carrier Sep 04 14:12:32 systemd-networkd[754]: enp37s0: DHCP lease lost Sep 04 14:12:34 systemd-networkd[754]: enp37s0: Link UP Sep 04 14:12:38 systemd-networkd[754]: enp37s0: DHCPv4 address 192.168.1.246/24, gateway 192.168.1.1 acquired可以看到，网卡反复掉线 → 重新获取 IP，而不是单纯 DHCP 租约到期。2. 确认网卡型号通过 lspci 查看网卡型号，确认是 Realtek RTL8111/8168 系列。lspci | grep -i eth 25:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)3. 问题原因Ubuntu 默认使用内核自带的r8169驱动来驱动 RTL8111/8168 网卡，但这个驱动对硬件支持不完整，常见问题包括：随机掉线（Link DOWN）DHCP 租约频繁丢失省电特性 (EEE) 导致链路不稳定Realtek 官方推荐使用r8168驱动，而不是r81694. 解决步骤4.1 安装r8168-dkmsUbuntu 提供了r8168-dkms包，直接安装即可：sudo apt update sudo apt install r8168-dkms安装后会生成配置文件/etc/modprobe.d/r8168-dkms.conf，但其中的blacklist r8169默认是被注释掉的。4.2 屏蔽 r8169编辑配置文件：sudo vim /etc/modprobe.d/r8168-dkms.conf找到这一行：#blacklist r8169改成：blacklist r8169保存退出后，更新initramfs：sudo update-initramfs -u4.3 重启并确认重启系统：sudo reboot然后检查驱动：lspci -k -s 25:00.0预期输出：Kernel driver in use: r8168 Kernel modules: r8168此时，网卡已经使用r8168驱动。5. 可选优化5.1 关闭 EEE（节能以太网）某些 Realtek 网卡在开启 EEE 时会出现不稳定，可以关闭：sudo ethtool --set-eee enp37s0 eee off若确认稳定，可以写入systemd service中，开机自动执行。5.2 强制速率/双工模式如果交换机/路由器兼容性有问题，可以强制固定速率：sudo ethtool -s enp37s0 speed 1000 duplex full autoneg on
在 Ubuntu 24.04 上运行 apt update 时，可能会遇到长时间的卡顿。通过抓包（tcpdump）可以发现，APT 在访问镜像站之前，会发送一些 SRV 记录查询：SRV? _https._tcp.esm.ubuntu.com. SRV? _https._tcp.mirrors.tuna.tsinghua.edu.cn. SRV? _https._tcp.developer.download.nvidia.com.但是大多数镜像站/CDN 并不会提供 SRV 记录，只支持常规的 A / AAAA。这会导致 DNS 请求超时或 fallback，从而拖慢 apt update 的整体速度。解决方案：禁用 APT 的 SRV 查询APT 支持通过配置文件禁用 SRV 查询。只需要在 /etc/apt/apt.conf.d/ 目录下添加一个配置文件，例如：echo 'Acquire::EnableSrvRecords "false";' | sudo tee /etc/apt/apt.conf.d/99-disable-srv这样，APT 在解析镜像站地址时就只会做标准的 A/AAAA 查询，不再尝试 SRV，从而避免卡顿。验证方法开启抓包：sudo tcpdump -i any port 53 -vvv执行：sudo apt update如果配置生效，你会看到只有 A? 和 AAAA? 查询，不再有 _https._tcp.* 的 SRV 查询。恢复方法如果需要恢复默认行为，只需删除配置文件即可：sudo rm /etc/apt/apt.conf.d/99-disable-srv总结原因：APT 默认会尝试 SRV 查询，但绝大多数镜像站并不支持，导致卡顿。解决办法：在 /etc/apt/apt.conf.d/ 下添加Acquire::EnableSrvRecords "false";即可永久禁用 SRV 查询，提升 apt update 的速度。
Ubuntu为了实现secure boot以及便于管理，将英伟达的驱动打包之后配合Linux modules签名，然后通过ubuntu-drivers提供，看起来，一切都很美好。按照正流程安装：sudo ubuntu-drivers install --gpgpu在服务器上安装nvidia-headless-no-dkms-570-server驱动sudo apt install nvidia-utils-570-server安装了常用软件，包括nvidia-smi输入nvidia-smi查看GPU信息，报错NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.。然而，ubuntu-drivers-common的包有个不大不小的bug：只安装nvidia-driver-no-dkms-<series>，不安装linux-modules-nvidia。本来就是no-dkms，再加上缺少内核模块，注定无法正常工作。Ubuntu其实在2024-10-07就已经发现这个问题了（1:0.9.7.6ubuntu3.1），但是直到2025-03-11才修复这个问题并重新发布（1:0.9.7.6ubuntu3.2）。但是，问题又来了，一直被推迟:The following upgrades have been deferred due to phasing: ubuntu-drivers-common至于原因？不好意思，我们分批推送，但是还没有推送，因为还是有问题，已经被暂停并回滚了，至于修复版的修复版，你先等着吧：ubuntu-drivers-common: Installed: 1:0.9.7.6ubuntu3.1 Candidate: 1:0.9.7.6ubuntu3.2 Version table: 1:0.9.7.6ubuntu3.2 500 (phased 0%) 500 http://cn.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages *** 1:0.9.7.6ubuntu3.1 100 100 /var/lib/dpkg/status 1:0.9.7.6ubuntu3 500 500 http://cn.archive.ubuntu.com/ubuntu noble/main amd64 Packages想解决也很简单，把没有安装的包，手动安装linux-modules-nvidia-570-server-generic，然后重启即可。
TensorFlow不知道又干了什么，最近脑子抽风，删掉了conda相关的安装教程。只剩下pip和docker了，而pip安装在Ubuntu22.04上需要额外的折腾才能正常跑起来。下面把conda安装教程记录一下。安装miniconda具体的步骤可以找其他教程，其实一路确认就可以了。curl https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -o Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh创建conda环境conda create --name tf python=3.9 # 环境名称为tf，python版本为3.9 conda deactivate # 脱离原始conda环境 conda activate tf # 进入刚才创建的tf环境设置GPU环境nvidia-smi # 查看是否安装了驱动安装CUDA和cuDNNconda install -c conda-forge cudatoolkit=11.2.2 cudnn=8.1.0配置自动激活工具，省得后面环境掉了还不知道mkdir -p $CONDA_PREFIX/etc/conda/activate.d echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CONDA_PREFIX/lib/' > $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh安装TensorFlowpip install --upgrade pip pip install tensorflow==2.11.* # 注意不要用conda安装，会有一堆奇怪的bug确认GPU是否正常工作 先看完后面的Ubuntu 22.04配置再执行命令python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"正常工作会出现下列内容，机器有几张显卡就会出现几个物理设备。[ "PhysicalDevice(name='/physical_device:GPU:0'", "device_type='GPU')", "PhysicalDevice(name='/physical_device:GPU:1'", "device_type='GPU')", "PhysicalDevice(name='/physical_device:GPU:2'", "device_type='GPU')", "PhysicalDevice(name='/physical_device:GPU:3'", "device_type='GPU')" ]Ubuntu 22.04的问题因为系统原因，直接上述的GPU检查，系统无法找到显卡，或者报错：Can't find libdevice directory ${CUDA_DIR}/nvvm/libdevice. Couldn't invoke ptxas --version InternalError: libdevice not found at ./libdevice.10.bc [Op:__some_op]需要按照以下步骤安装nvcc并正确配置：conda install -c nvidia cuda-nvcc=11.3.58 # 安装nvcc mkdir -p $CONDA_PREFIX/etc/conda/activate.d # 配置XLA cuda文件夹 printf 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CONDA_PREFIX/lib/\nexport XLA_FLAGS=--xla_gpu_cuda_data_dir=$CONDA_PREFIX/lib/\n' > $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh source $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh mkdir -p $CONDA_PREFIX/lib/nvvm/libdevice # 复制所需文件 cp $CONDA_PREFIX/lib/libdevice.10.bc $CONDA_PREFIX/lib/nvvm/libdevice/