企业官网建设流程全解析

简介：这是适用于H3C T1100 G3服务器板载Intel网卡芯片组的Linux驱动程序包，主要面向服务器运维工程师、Linux系统管理员及VMware ESXi虚拟化平台实施人员。e1000e驱动用于支撑操作系统与网卡硬件之间的稳定通信，在部署ESXi时，若网卡未被默认驱动正确识别，就需要借助此类驱动完成适配，从而解决网络不识别、丢包或链路不稳定等常见故障。压缩包整体共包含三十五个文件，主体由十三个C语言源文件与十三个头文件构成，覆盖网卡初始化、链路管理、电源管理和中断处理等核心模块；另附Makefile编译脚本、e1000e.spec打包配置、README使用说明、SUMS校验文件以及pci.updates与Module.supported等硬件适配信息，便于用户理解驱动结构并按需编译集成。整个压缩包仅有三百零七KB，体量轻巧，适合直接下载到离线服务器或ESXi主机使用。目前已有三百八十三人学习下载，对于需要手动为Linux或ESXi环境编译网卡驱动的技术人员，这套资料提供了完整的源码、构建配置和适配记录，可大幅缩短排查与调优时间，是一份值得收藏的服务器驱动升级素材。

1. 搞懂 e1000e 到底解决什么问题

1.1 这类网卡驱动为何需要手动装

e1000e 是 Intel 官方推出的千兆以太网控制器驱动模块，覆盖的路由芯片组包括 82571、82572、82573、82574、82583 以及后来的 I217、I218、I219 等系列。名字里的 "e1000e" 不是打错了，它是从经典 e1000 驱动里分支出来的独立版本线，专门服务 PCIe 接口的千兆网卡，而不是老式板载 82540/82544 那批早期芯片。很多时候发行版自带的 kernel 里已经有这个模块，但版本偏旧，或者安装系统时内核配置里没有启用它，这时候网卡就会呈现“系统装好了却上不了网”的尴尬状态。

我最早遇到这个问题是在一台老服务器上，系统识别到了物理网卡，ip link能看到设备，但一配 IP 就报 "No such device"，dmesg 里也找不到 e1000e 相关输出。后来查明原因：这台机器跑的是自定义编译的精简内核，模块清单里根本没有 e1000e。这种情况下，最稳妥的办法就是去 Intel 官方下载对应源码包，手动编译一个匹配当前内核版本的.ko文件。

所以这篇内容面向的对象很明确：服务器运维人员、嵌入式 Linux 玩家，还有自己折腾软路由或 NAS 的朋友。只要你想让 Intel 千兆网卡在 Linux 下稳定工作，并且希望驱动版本可控，下面的流程就能直接照抄。

1.2 怎么确认你的网卡就是 e1000e 管理的那颗

下载驱动之前，先花一分钟确认网卡型号，避免白忙活一场。在终端跑一条命令：

lspci | grep -i ethernet

输出里通常长这样：

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V

只要看到 Intel、I210/I217/I218/I219、82574L 这类型号，基本就是 e1000e 的管辖范围。还有一种确认方式是在已经能用的系统上执行：

ethtool -i eth0

driver 字段如果显示 e1000e，说明当前已经加载了这个驱动。如果显示 e1000、igb、igc，那就不是同一个驱动，别装错包。硬要区分的话，e1000 管的是老古董网卡，igb 管 I350/I210 这种 PCIe 千兆，igc 管 I225/I226 这种 2.5G 网卡，e1000e 则刚好卡在中间那一档。下载源码包时注意别选错目录，Intel 的下载页面上这两个驱动是分开的，文件名一个叫e1000e-x.x.x.tar.gz，一个叫igb-x.x.x.tar.gz，点错的话编译会直接报错，因为源码结构和 Makefile 差异很大。

2. 安装前准备：先把系统和源码包摸清楚

2.1 内核版本与工具链检查

手动编译驱动本质上就是编译一个内核模块，所以必须保证系统里有完整的编译环境。我见过太多人卡在make那一步，其实问题都出在缺依赖。先检查三样东西：gcc、make、内核头文件。

gcc --version make --version ls /lib/modules/$(uname -r)/build

第三条命令最关键。/lib/modules/xxx/build是一个软链接，指向内核源码或内核头文件目录，编译模块时必须用到里面的 Makefile 和头文件。如果这个路径不存在，说明你没装 kernel-devel（CentOS/RHEL 系）或 linux-headers（Debian/Ubuntu 系）。安装方式分别是：

# Debian/Ubuntu apt install linux-headers-$(uname -r) build-essential # CentOS/RHEL yum install kernel-devel gcc make

注意 CentOS 系的 kernel-devel 版本必须和uname -r完全一致，否则编出来的模块无法加载。如果是自己编译的内核，那就更简单，直接用原内核源码目录，进入 e1000e 的 src 目录编译时会自动定位到/lib/modules/$(uname -r)/build，前提是你之前执行过make modules_prepare。我建议在编译前先看一眼当前内核版本：

uname -r

记录下这个版本号，后面排查问题时要反复用到。

提示：如果你跑的是云服务器或虚拟化环境，网卡通常是 virtio 或 e1000（不是 e1000e），那这个教程就不适用。确认方式还是用lspci里的设备 ID 去对着 Intel 的驱动支持列表查，别凭感觉。

2.2 拿到 e1000e-3.6.0.tar.tgz 并解压

源码包可以从 Intel 官网的“以太网适配器驱动程序”页面下载，也可以在部分开源镜像站找到。这个包命名很有特点，e1000e-3.6.0.tar.tgz本质上就是个用 tar 打包、再用 gzip 压缩的归档文件，和常见的.tar.gz没有区别，只是后缀写法不同。解压命令：

tar -zxvf e1000e-3.6.0.tar.tgz

解压后会出现一个目录，名字通常叫e1000e-3.6.0，里面有src、README、COPYING等文件。README 是重点，里面写清楚了支持的网卡型号、已知问题和安装步骤，建议花十分钟通读一遍。Intel 官方的驱动包结构这些年基本没变过，src目录下就是驱动源码和 Makefile。

如果系统提示 tar 不认识这个格式，大概率是下载过程出了问题，文件不完整。可以先用file命令看一眼真实类型：

file e1000e-3.6.0.tar.tgz

正常输出应该是gzip compressed data，如果显示HTML document或者ASCII text，说明你下到的是一个错误页面，而不是真正的源码包。

3. 从 tar.tgz 到可加载的 .ko：编译全过程

3.1 编译与安装命令

进入解压后的src目录，安装流程其实就两条命令：

cd e1000e-3.6.0/src make install

make install会自动完成编译和安装两个动作，把生成的e1000e.ko放到当前内核的模块目录下。具体路径一般是：

/lib/modules/$(uname -r)/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

装完后记得执行depmod -a，让它重新生成模块依赖关系。这一步很多人容易漏掉，漏掉之后modprobe e1000e会提示找不到模块。如果你只想编译不安装，也可以只跑make，这时候会在当前目录生成e1000e.ko，方便你手动拷贝测试。

编译过程中如果终端刷出一屏 gcc 警告，不用太紧张。Intel 官方驱动代码风格比较保守，在较新的 gcc 版本下出现unused variable、format-truncation之类警告很常见，只要最后能看到BUILD SUCCESS或者提示生成了.ko文件，就是成功的。

下面是编译成功后的关键输出示例：

CC [M] /root/e1000e-3.6.0/src/e1000e_main.o CC [M] /root/e1000e-3.6.0/src/e1000e_ethtool.o CC [M] /root/e1000e-3.6.0/src/e1000e_phy.o ... LD [M] /root/e1000e-3.6.0/src/e1000e.ko

看到LD [M]这行，说明已经成功链接出内核模块文件。

3.2 替换系统自带模块的正确姿势

编译安装完成后有个隐蔽的坑：系统原本可能已经有一个 e1000e 模块，版本可能是发行版定制的，也可能来自内核自带的构建。即使你手动make install放了一个新模块进去，加载时系统依然可能优先使用原来的。这时候需要先强制卸载旧模块，再加载新的。

# 卸载已有模块 modprobe -r e1000e # 确认卸载干净 lsmod | grep e1000e # 加载新模块 modprobe e1000e

如果系统提示Module e1000e is in use，说明有网卡正在使用这个驱动，直接卸载会导致网络断开。如果通过 SSH 连接服务器，操作前一定要确保有带外管理（IPMI/iDRAC）或者物理 console 权限，否则卸载瞬间你的 SSH 就会掉线，可能再也连不回去。

一个更安全的做法是先把模块加入黑名单，让系统启动时不加载旧模块，再手动加载新的：

echo "blacklist e1000e" > /etc/modprobe.d/e1000e-blacklist.conf

然后重启，等系统完全起来后再modprobe e1000e，这时候加载的就是你编译好的新版本。不过这个操作比较激进，适合驱动导致开机网络异常的紧急场景，正常升级驱动不建议这么搞。

4. 加载驱动与开机自启

4.1 手动加载与验证

模块加载成功后，第一件事是确认网卡是否被正确识别。推荐用这几条命令交叉验证：

# 查看内核日志里有关 e1000e 的记录 dmesg | grep e1000e # 查看网卡接口和驱动绑定情况 ethtool -i eno1 # 查看网卡状态 ip link show eno1

dmesg 里如果出现类似这样的行，说明驱动已经接管了网卡：

e1000e 0000:00:1f.6 eno1: renamed from eth0 e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex

ethtool -i输出的 driver 字段应该是e1000e，version 字段应该是你编译的 3.6.0。注意，ip link show里可能显示接口名为eno1或者eth0，这取决于系统的命名规则，不影响驱动判断。

如果你更谨慎一点，可以顺便测试一下实际网络吞吐，确认驱动没问题：

iperf3 -c 192.168.1.10

或者简单 ping 一下网关，观察延迟和丢包率是否正常。之前遇到过编译成功后能加载、但一跑大流量就断网的案例，后来定位是 ACPI 电源管理策略导致网卡进入低功耗模式，跟驱动本身无关，这种问题可以靠调整 BIOS 或者 ethtool 的 wol 参数来处理。

4.2 DKMS 让驱动长期稳定

手动编译安装的模块有个麻烦：一旦升级内核，原有编译好的.ko与新内核不匹配，驱动就失效了。每次内核升级都要重新编译一次，费时费力。这个问题用 DKMS（Dynamic Kernel Module Support）可以很好地解决。

DKMS 的原理不复杂：它把驱动源码注册到系统里，每次安装新内核时自动执行一次编译和安装，保证新内核启动后立刻有对应版本的驱动可用。具体步骤：

# 安装 DKMS（Debian/Ubuntu 系） apt install dkms # 创建 DKMS 源码目录结构 mkdir -p /usr/src/e1000e-3.6.0 cp -a e1000e-3.6.0/src /usr/src/e1000e-3.6.0/ cd /usr/src/e1000e-3.6.0 # 需要添加一个 dkms.conf 配置文件

dkms.conf是 DKMS 的核心配置，内容如下：

PACKAGE_NAME="e1000e" PACKAGE_VERSION="3.6.0" BUILT_MODULE_NAME[0]="e1000e" DEST_MODULE_LOCATION[0]="/kernel/drivers/net/ethernet/intel/e1000e" AUTOINSTALL="yes" MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules" CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

然后依次执行：

dkms add -m e1000e -v 3.6.0 dkms build -m e1000e -v 3.6.0 dkms install -m e1000e -v 3.6.0

dkms status能看到模块状态，如果显示installed，说明已经成功。以后不管是 yum update 还是 apt upgrade 升级内核，重启后驱动都会自动就位，不用再手动操作。我个人强烈建议长期使用 e1000e 驱动的机器都走 DKMS 流程，省心很多。

5. 踩坑记录：编译失败、加载失败怎么排查

5.1 常见故障速查表

实际操作中遇到的问题五花八门，这里整理一份高频故障速查表，基本都是我或者朋友在部署时真实遇到过的。

5.2 关于 Secure Boot 签名问题

Secure Boot 是一个高频坑，特别是这两年新出的台式机和服务器都默认开启。启用 Secure Boot 时，内核只加载有合法签名的模块。手动编译的 e1000e.ko 没有签名，加载时会被拒绝，dmesg 里通常能看到：

Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7

解决方法有三种。第一种最直接：在 BIOS 里关闭 Secure Boot，但部分服务器环境出于安全合规要求不能关。第二种是给模块签名，需要用到mokutil和自签名证书，流程稍长但彻底。第三种是最省事的：去 Linux 发行版仓库里找带签名的预编译驱动包，Ubuntu 的linux-modules-extra里就包含 e1000e，CentOS 的kernel-modules-extra也能找到。

如果你一定要用 Intel 官网的源码包又不想关 Secure Boot，就只能手动签名。大致流程是先创建一个密钥对：

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Custom Module Signing Key/"

然后用mokutil导入公钥：

mokutil --import MOK.der

这时候系统会提示你设置一个一次性密码，重启后会自动进入 MOK 管理界面，选择 Enroll key，输入刚才的密码完成导入。之后用sign-file给模块签名：

/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 MOK.priv MOK.der e1000e.ko

签完名再重新放进模块目录跑depmod就能正常加载了。整个过程不复杂，但需要重启一次，而且不同发行版的 mokutil 界面略有差异，操作时认证看提示。

5.3 模块加载了网卡还是不出现

这种情况最容易让人心态崩掉，dmesg 里明明有 e1000e 的初始化信息，但ip link就是看不到任何新接口。排查顺序一般是：

# 1. 查看 PCI 设备是否被正确识别 lspci -nn | grep -i ethernet # 2. 查看驱动与设备绑定关系 lspci -k -s 00:1f.6 # 3. 查看可用的网络接口 ip link

lspci -k的 Kernel driver in use 字段如果是e1000e，说明绑定成功了。如果显示(null)或者别的驱动，可能是 PCI ID 不匹配，也可能设备被 BIOS 禁用了。还有另一种情况是网络接口被 systemd 改名规则吞掉了，比如 udev 规则里把某个 MAC 地址对应的接口名定义成了enp2s0，但实际驱动加载后的接口名是eth1。用dmesg | grep rename能找到改名记录。

如果上述都正常，检查一下驱动是否被NetworkManager接管：

nmcli device status

有时候驱动加载成功了，但网络管理工具没有自动生成连接配置，导致接口处于unmanaged状态。这时候手动创建一个连接配置就行，和驱动本身无关。

写在最后的体会

折腾 e1000e 系列驱动这几年，一个比较深的感受是：遇到网卡问题不要一上来就怀疑硬件，很多时候就是驱动版本和内核版本不匹配造成的。Intel 官方驱动的更新节奏偏保守，如果系统自带的版本足够稳定，完全没必要追新。只有在遇到丢包、断流、速率协商异常这类问题时，才值得花时间手动换一版驱动试试。编译安装的流程整体不算复杂，但对内核模块机制不熟悉的读者来说，建议第一次操作时先在测试机上跑一遍，把命令都跑通了再上生产环境，不然 SSH 断线回不去的滋味确实不太妙。

本文还有配套的精品资源，点击获取