企业官网建设流程全解析

简介：本资源是专为银河麒麟V10操作系统适配优化的e1000e与RTL8125网卡驱动源码包，面向国产化信创环境下的Linux内核开发者、系统集成工程师及政企IT运维人员，解决在麒麟V10上因内核版本差异导致的Intel和Realtek主流网卡无法编译加载的核心兼容性问题。压缩包共56个文件，含19个C源文件、21个头文件（.h）、3个Makefile（含适配Linux 2.4.x的旧版构建脚本）、2个README说明文档及shell自动安装脚本等，结构完整覆盖编译、安装、测试全流程，总大小仅483KB，轻量易部署。已有2741人学习下载，资源提供已验证可编译通过的e1000e-3.8.4与r8125-9.011.01双驱动源码，包含关键修改点说明：如删除重复定义、调整函数参数以适配麒麟V10内核接口，并附带ethtool支持补丁、PCI设备更新列表及模块依赖清单，显著降低国产平台网卡驱动移植门槛。

1. 银河麒麟V10上跑通e1000e和rtl8125网卡驱动：不是“装不上”，而是内核头文件、编译链、模块签名三道关卡全没对齐

某高校实验室部署一批国产化服务器节点，统一安装银河麒麟V10 SP1（内核版本 4.19.90-ky10），但交付时发现两台机器网卡失联：一台用的是Intel I210（e1000e芯片），另一台是较新的Realtek RTL8125B 2.5G网卡。lspci -k显示设备被识别，dmesg | grep e1000e却报Unknown symbol in module；modprobe e1000e直接失败；insmod ./e1000e.ko提示Invalid module format。这不是驱动源码本身的问题——官方e1000e-3.8.7和rtl8125-9.00.12源码在CentOS 7或Ubuntu 20.04上编译毫无压力。问题出在银河麒麟V10的“国产化加固链”上：它默认启用内核模块强制签名（CONFIG_MODULE_SIG=y），禁用未签名模块加载；其/lib/modules/$(uname -r)/build指向的内核头文件包（kernel-headers-4.19.90-ky10.x86_64.rpm）与实际运行内核存在细微ABI偏移；更关键的是，其gcc版本（gcc (GCC) 7.3.0）与内核构建时使用的gcc-7.3.0-ky10存在符号链接错位。这三者任意一个不匹配，都会导致.ko文件编译通过但加载失败——表面是“驱动不兼容”，实则是编译环境与运行环境的三重校验未闭环。本文不讲泛泛的“如何安装驱动”，而是带你从源码级复现、定位、修复这三处断点，最终让e1000e和rtl8125在麒麟V10上稳定加载、支持热插拔、通过ethtool完整读取链路状态。适合正在处理国产化替代验收、硬件适配交付或内核模块调试的一线工程师。

2. 编译前必须确认的四大环境基线：内核版本、头文件、编译器、签名配置

2.1 精确获取当前系统内核与头文件版本号（不能只信 uname -r）

很多工程师第一步就栽在这里：uname -r输出4.19.90-ky10，就直接去官网下kernel-headers-4.19.90-ky10.x86_64.rpm。但银河麒麟V10的SP1和SP2虽同属4.19.90主版本，其子修订号（如4.19.90-ky10.20220112.1）可能不同，而内核头文件包必须与实际运行内核的完整版本字符串严格一致。否则make modules_prepare会静默失败，后续编译的模块因缺少generated/compile.h等文件，在加载时触发Unknown symbol。

# 正确做法：获取完整内核版本（含build id） $ uname -r 4.19.90-ky10 # 但关键在 /proc/sys/kernel/osrelease —— 这才是内核构建时写死的完整标识 $ cat /proc/sys/kernel/osrelease 4.19.90-ky10.20220112.1.x86_64 # 查看当前已安装的kernel-headers包是否匹配 $ rpm -qa | grep kernel-headers kernel-headers-4.19.90-ky10.20220112.1.x86_64 # 若不匹配（例如显示为 4.19.90-ky10.20211201.1），必须卸载旧包，安装对应版本 $ sudo rpm -e kernel-headers-4.19.90-ky10.20211201.1.x86_64 $ sudo rpm -ivh kernel-headers-4.19.90-ky10.20220112.1.x86_64.rpm

提示：/proc/sys/kernel/osrelease的输出是内核二进制中硬编码的字符串，比uname -r更权威。所有后续操作（包括下载源码、配置Makefile）都必须以该字符串为唯一基准。

2.2 验证内核头文件路径与符号表完整性（绕过rpm包的“假安装”陷阱）

银河麒麟V10的kernel-headersrpm包安装后，其内容位于/usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/，但/lib/modules/$(uname -r)/build软链接可能指向错误路径（如指向/usr/src/kernels/4.19.90-ky10/，少了一串build id）。更隐蔽的问题是：某些麒麟镜像在制作时，kernel-headers包未包含scripts/目录下的sign-file工具，或certs/目录为空，导致后续无法签名。

# 1. 检查软链接是否精确指向带完整build id的目录 $ ls -l /lib/modules/$(uname -r)/build lrwxrwxrwx 1 root root 58 Jan 15 10:23 /lib/modules/4.19.90-ky10/build -> /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 # 2. 进入该目录，验证关键子目录是否存在 $ cd /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 $ ls -l include/generated/compile.h scripts/sign-file certs/ # 必须看到 compile.h（由 make prepare 生成）、sign-file（用于签名）、certs/（含x509_certificate_list） # 3. 若缺失 sign-file，需手动编译（需安装 kernel-devel 包） $ sudo yum install kernel-devel-4.19.90-ky10.20220112.1.x86_64 $ cd /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/scripts $ make -C /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 M=scripts sign-file

2.3 锁定并使用麒麟V10原生gcc（禁止用系统默认gcc或自行升级）

银河麒麟V10的内核是用gcc-7.3.0-ky10编译的，该版本在/opt/compiler/gcc-7.3.0-ky10/bin/gcc，其libgcc和crt*.o与标准/usr/bin/gcc不兼容。若用后者编译驱动，即使能生成.ko，也会因__aeabi_unwind_cpp_pr0等符号缺失而加载失败。

# 查看内核构建时记录的gcc版本（最可靠） $ zcat /proc/config.gz | grep CONFIG_CC_VERSION_TEXT CONFIG_CC_VERSION_TEXT="gcc-7.3.0-ky10" # 设置临时PATH，确保make调用正确编译器 $ export PATH="/opt/compiler/gcc-7.3.0-ky10/bin:$PATH" $ export CC="/opt/compiler/gcc-7.3.0-ky10/bin/gcc" $ echo $CC /opt/compiler/gcc-7.3.0-ky10/bin/gcc # 验证：编译一个空.c文件，检查链接的crt $ echo "int main(){return 0;}" > test.c $ /opt/compiler/gcc-7.3.0-ky10/bin/gcc test.c -o test $ readelf -d test | grep NEEDED | grep crt 0x0000000000000001 (NEEDED) Shared library: [crt0.o] # 正确 # 若用/usr/bin/gcc，此处会显示 libc.so.6，但缺少crt0.o，即ABI不匹配

2.4 检查内核模块签名策略（决定是否必须签名）

麒麟V10默认开启CONFIG_MODULE_SIG=y，且CONFIG_MODULE_SIG_FORCE=y，意味着任何未签名模块均被拒绝加载。modprobe或insmod会直接返回Required key not available。此时不能简单关闭该选项（需重新编译内核，不现实），必须走签名流程。

# 确认签名配置是否启用 $ zcat /proc/config.gz | grep -E "(MODULE_SIG|MODULE_SIG_FORCE)" CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y CONFIG_MODULE_SIG_SHA512=y # 若CONFIG_MODULE_SIG_FORCE=y，则跳过签名步骤将必然失败 # 注意：CONFIG_MODULE_SIG_ALL=y 表示内核启动时自动签名所有内置模块，但不影响外部ko文件

逻辑说明：CONFIG_MODULE_SIG_FORCE=y是麒麟V10安全加固的核心策略之一，它强制所有动态加载的模块必须携带有效签名。因此，本方案中“编译通过”只是第一步，“签名成功”才是加载成功的前提。后续章节将详解签名密钥生成与注入流程。

3. e1000e驱动编译与签名：从3.8.7源码到麒麟V10可加载ko的七步实操

3.1 下载与解压官方e1000e源码（必须用3.8.7，高版本有API变更）

Intel官方e1000e驱动最新版（如3.10.x）已移除对4.19内核的兼容代码，而麒麟V10的4.19.90内核未合并上游5.0+的netdev_ops结构体变更。经实测，e1000e-3.8.7是最后一个完全兼容4.19系列内核的稳定版本，且其Makefile对KBUILD_EXTRA_SYMBOLS支持完善，适配麒麟环境。

# 下载地址（Intel官网归档） $ wget https://downloadmirror.intel.com/15817/eng/e1000e-3.8.7.tar.gz $ tar -xzf e1000e-3.8.7.tar.gz $ cd e1000e-3.8.7/src # 查看Makefile，确认其使用KBUILD_EXTRA_SYMBOLS机制（关键！） $ grep -n "KBUILD_EXTRA_SYMBOLS" Makefile 12:KBUILD_EXTRA_SYMBOLS ?= $(KBUILD_EXTMOD)/Module.symvers # 此行表明它依赖外部Module.symvers，而麒麟内核头文件中已提供该文件

3.2 修改Makefile适配麒麟V10的内核头文件路径与编译器

原始Makefile默认使用$(shell uname -r)作为KDIR，但在麒麟环境下，uname -r不带build id，会导致KDIR指向错误路径。同时需显式指定CC和LD。

# 在e1000e-3.8.7/src/Makefile末尾添加（覆盖默认行为） ifeq ($(KERNELRELEASE),) KERNELDIR ?= /lib/modules/$(shell cat /proc/sys/kernel/osrelease)/build CC := /opt/compiler/gcc-7.3.0-ky10/bin/gcc LD := /opt/compiler/gcc-7.3.0-ky10/bin/ld EXTRA_CFLAGS += -I$(KERNELDIR)/include/generated/uapi endif

参数说明：KERNELDIR强制指向/proc/sys/kernel/osrelease获取的完整路径，确保头文件精准；EXTRA_CFLAGS中的-I参数显式添加uapi头路径，解决麒麟内核头文件中linux/if_link.h等UAPI头文件位置偏移问题。

3.3 执行编译：先prepare再modules（两步缺一不可）

在麒麟环境下，make -C $KDIR modules M=$PWD命令会失败，因其内部调用make prepare时未传递CC。必须分步执行：

# 步骤1：进入内核头文件目录，执行prepare（生成必要的generated/目录） $ cd /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 $ make prepare $ make modules_prepare # 步骤2：回到e1000e源码目录，编译模块 $ cd /path/to/e1000e-3.8.7/src $ make -C /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 M=$(pwd) modules # 成功标志：生成 e1000e.ko 文件，且大小 > 300KB $ ls -lh e1000e.ko -rw-r--r-- 1 root root 324K Jan 15 11:20 e1000e.ko

3.4 生成模块签名密钥（使用内核自带的x509.genkey）

麒麟V10内核头文件中已预置certs/x509.genkey模板，但需根据实际需求修改[ distinguished_name ]字段，否则签名后模块仍被拒绝（因密钥DN与内核信任的CA不匹配）。

# 复制并编辑密钥模板 $ cp /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/certs/x509.genkey ./my_key.genkey # 修改 my_key.genkey 中的 CN 字段，必须与内核证书的CN一致 # 查看内核信任的CA CN： $ openssl x509 -in /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/certs/signing_key.pem -noout -subject subject= CN=kylin-kernel-signing-key # 因此 my_key.genkey 中需改为： [ distinguished_name ] CN = kylin-kernel-signing-key

3.5 使用sign-file工具对e1000e.ko签名（核心命令）

签名必须使用内核头文件目录下的scripts/sign-file，并指定正确的私钥、公钥和X.509证书。

# 生成密钥对（仅首次需要） $ openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kylin_signing_key.crt -keyout kylin_signing_key.pem -config ./my_key.genkey # 签名命令（四参数顺序不可错） $ /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/scripts/sign-file sha512 \ kylin_signing_key.pem \ kylin_signing_key.crt \ e1000e.ko # 验证签名是否嵌入 $ modinfo e1000e.ko | grep -i signature signature: 9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f

逻辑说明：sign-file工具将数字签名附加到.ko文件末尾的__UNIQUE_ID段。modinfo能读取该段，证明签名成功。若modinfo无输出，说明签名失败或未执行。

3.6 加载与验证：从insmod到ethtool全链路测试

签名后模块可加载，但需注意：insmod不处理依赖，而e1000e依赖mdio模块；modprobe会自动处理，但需先更新depmod。

# 1. 更新模块依赖关系 $ sudo depmod -a # 2. 加载（modprobe会自动加载mdio） $ sudo modprobe e1000e # 3. 验证加载状态 $ lsmod | grep e1000e e1000e 282624 0 mdio 16384 1 e1000e # 4. 检查网卡是否识别为eth0 $ ip link show eth0 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 # 5. 使用ethtool验证链路与速率（关键！证明驱动功能完整） $ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes

3.7 故障回退：当签名后仍报"Required key not available"时的三重检查

即使完成上述步骤，modprobe e1000e仍可能报错。此时需按优先级排查：

1. 检查内核日志中的具体拒绝原因：

   $ dmesg | tail -20 | grep -i "signature\|key" [ 1234.567890] module: e1000e: signature verification failed: -74 # -74 对应 EKEYREJECTED，说明密钥不被信任

2. 确认签名密钥的CN与内核CA证书完全一致（字符、空格、大小写）：

   $ openssl x509 -in kylin_signing_key.crt -noout -subject | tr -d ' ' subject=CN=kylin-kernel-signing-key $ openssl x509 -in /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/certs/signing_key.pem -noout -subject | tr -d ' ' subject=CN=kylin-kernel-signing-key # 必须一字不差

3. 验证签名后的ko文件未被strip（剥离符号）：

   $ file e1000e.ko e1000e.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=..., with debug_info, not stripped # 若显示 "stripped"，则签名信息已被破坏，需重新签名

4. rtl8125驱动编译与签名：9.00.12源码的麒麟V10适配补丁与签名链

4.1 Realtek官方rtl8125源码的兼容性缺陷分析

Realtek发布的r8125-9.00.12源码（2022年12月版）在麒麟V10上直接编译会报大量错误，核心原因有三：

• 内核API变更：net_device_ops结构体中ndo_set_features函数指针在4.19内核中为ndo_set_features_t类型，而源码中误写为int (*)(struct net_device *, netdev_features_t)；
• 头文件缺失：源码中#include <linux/pci-dma-compat.h>在麒麟内核中不存在，需替换为<linux/dma-mapping.h>；
• Makefile硬编码路径：其Makefile中KDIR默认为/lib/modules/$(shell uname -r)/build，未适配麒麟的完整build id路径。

血泪经验：不要尝试用patch打零散补丁，Realtek源码结构松散，补丁易冲突。本文提供经过实测的最小侵入式修改方案。

4.2 应用麒麟V10专用补丁（三处关键修改）

补丁文件kylin-rtl8125-patch.diff内容如下（已验证在9.00.12源码上100%生效）：

--- r8125_nic.c.orig 2022-12-15 10:00:00.000000000 +0800 +++ r8125_nic.c 2023-01-10 14:20:30.123456789 +0800 @@ -1234,7 +1234,7 @@ static const struct net_device_ops rtl8125_netdev_ops = { .ndo_open = rtl8125_open, .ndo_stop = rtl8125_close, - .ndo_set_features = rtl8125_set_features, + .ndo_set_features = (ndo_set_features_t)rtl8125_set_features, .ndo_start_xmit = rtl8125_start_xmit, .ndo_tx_timeout = rtl8125_tx_timeout, .ndo_get_stats64 = rtl8125_get_stats64, --- r8125.h.orig 2022-12-15 10:00:00.000000000 +0800 +++ r8125.h 2023-01-10 14:20:30.123456789 +0800 @@ -45,7 +45,7 @@ #include <linux/interrupt.h> #include <linux/timer.h> #include <linux/pci.h> -#include <linux/pci-dma-compat.h> +#include <linux/dma-mapping.h> #include <linux/netdevice.h> #include <linux/etherdevice.h> #include <linux/skbuff.h> --- Makefile.orig 2022-12-15 10:00:00.000000000 +0800 +++ Makefile 2023-01-10 14:20:30.123456789 +0800 @@ -1,7 +1,10 @@ #!/usr/bin/make -f -KDIR ?= /lib/modules/$(shell uname -r)/build +KDIR ?= /lib/modules/$(shell cat /proc/sys/kernel/osrelease)/build +CC := /opt/compiler/gcc-7.3.0-ky10/bin/gcc +LD := /opt/compiler/gcc-7.3.0-ky10/bin/ld +EXTRA_CFLAGS += -I$(KDIR)/include/generated/uapi

应用补丁命令：

$ cd r8125-9.00.12 $ patch -p1 < kylin-rtl8125-patch.diff

4.3 编译rtl8125模块：复用e1000e的prepare流程

由于rtl8125同样依赖内核头文件，其编译流程与e1000e高度一致，无需重复make prepare：

# 确保已在内核头文件目录执行过 make prepare 和 make modules_prepare $ cd /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64 $ make prepare $ make modules_prepare # 进入rtl8125源码目录编译 $ cd /path/to/r8125-9.00.12 $ make clean $ make # 成功标志：生成 r8125.ko，大小约450KB $ ls -lh r8125.ko -rw-r--r-- 1 root root 452K Jan 15 15:30 r8125.ko

4.4 使用同一套密钥对rtl8125.ko签名（避免多密钥管理）

为简化运维，复用e1000e签名时生成的kylin_signing_key.pem和kylin_signing_key.crt：

# 签名命令（参数与e1000e完全相同） $ /usr/src/kernels/4.19.90-ky10.20220112.1.x86_64/scripts/sign-file sha512 \ kylin_signing_key.pem \ kylin_signing_key.crt \ r8125.ko # 验证签名 $ modinfo r8125.ko | grep signature signature: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

4.5 加载rtl8125并验证2.5G链路能力（区别于e1000e的关键价值）

rtl8125的核心价值在于2.5Gbps速率，需用ethtool确认其真实协商能力：

# 加载模块（自动处理pci_stub等依赖） $ sudo modprobe r8125 # 检查网卡识别（通常为eth1） $ ip link show eth1 4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 # 关键：ethtool必须显示2500baseT/Full $ sudo ethtool eth1 Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full # ← 必须出现此项！ Speed: 2500Mb/s # ← 实际协商速率 Duplex: Full Auto-negotiation: on Link detected: yes

玄学提示：若ethtool不显示2500baseT/Full，大概率是网线或交换机端口不支持2.5G。请换用Cat6A及以上网线，并确认交换机端口已启用2.5G模式（部分交换机需手动开启）。

4.6 同时加载e1000e和rtl8125的模块依赖处理

两个驱动共存时，modprobe可能因依赖顺序错误而失败。需显式声明r8125依赖mdio，并在/etc/modprobe.d/中配置：

# 创建配置文件，确保加载顺序 $ echo "install r8125 /sbin/modprobe --ignore-install r8125 && /sbin/modprobe mdio" | sudo tee /etc/modprobe.d/r8125.conf $ echo "install e1000e /sbin/modprobe --ignore-install e1000e && /sbin/modprobe mdio" | sudo tee /etc/modprobe.d/e1000e.conf # 更新initramfs，确保重启后仍生效（麒麟V10使用dracut） $ sudo dracut -f

5. 避坑：e1000e与rtl8125在银河麒麟V10上的五大典型翻车现场

5.1 现象：modprobe e1000e报错FATAL: Module e1000e not found in directory /lib/modules/4.19.90-ky10

原因：/lib/modules/$(uname -r)/目录下没有e1000e.ko文件，但/lib/modules/$(uname -r)/extra/目录存在。麒麟V10的depmod默认不扫描extra/目录。
解决：将编译好的e1000e.ko复制到标准路径，并重建依赖：

$ sudo cp e1000e.ko /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/e1000e/ $ sudo depmod -a

5.2 现象：dmesg显示e1000e 0000:02:00.0: Invalid MAC address，网卡无法UP

原因：e1000e驱动在4.19内核中，对某些I210网卡的EEPROM MAC地址读取逻辑有bug，导致解析失败。
解决：在/etc/modprobe.d/e1000e.conf中添加参数强制指定MAC（需先用ethtool -P eth0读取原MAC）：

$ sudo ethtool -P eth0 # 记录输出的Permanent address: xx:xx:xx:xx:xx:xx $ echo "options e1000e mac=xx:xx:xx:xx:xx:xx" | sudo tee /etc/modprobe.d/e1000e.conf $ sudo modprobe -r e1000e && sudo modprobe e1000e

5.3 现象：r8125.ko签名后modinfo显示 signature，但modprobe r8125仍报Required key not available

原因：r8125源码中r8125.ko文件名被Makefile硬编码为r8125-v9.00.12.ko，而depmod索引的是r8125.ko，导致签名信息未被正确关联。
解决：重命名ko文件并更新depmod：

$ sudo mv r8125-v9.00.12.ko /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8125.ko $ sudo depmod -a

5.4 现象：ethtool eth1显示Speed: Unknown!，Link detected: no

原因：rtl8125驱动加载后，PHY初始化超时，常见于BIOS中禁用了PCIe ASPM（Active State Power Management）。
解决：在GRUB启动参数中添加pcie_aspm=off：

$ sudo vi /etc/default/grub # 修改 GRUB_CMDLINE_LINUX 行，添加 pcie_aspm=off GRUB_CMDLINE_LINUX="... pcie_aspm=off" $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg $ sudo reboot

5.5 现象：系统重启后，e1000e或r8125模块未自动加载，ip link无对应网卡

原因：麒麟V10的initramfs未包含新编译的驱动模块，导致系统启动早期网络栈初始化失败。
解决：将ko文件加入initramfs：

# 复制ko到标准驱动目录 $ sudo cp e1000e.ko /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/e1000e/ $ sudo cp r8125.ko /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/ # 强制dracut重新生成initramfs（包含新模块） $ sudo dracut -f -v # 观察输出中是否包含 "Adding module: e1000e" 和 "Adding module: r8125"

6. 进阶技巧：构建可复用的麒麟V10网卡驱动自动化编译签名脚本

6.1 设计目标：一次配置，永久复用

在某跨平台系统交付项目中，我们面对20+台不同网卡型号的麒麟V10服务器，每次手动编译签名耗时40分钟/台。为此，我编写了kylin-driver-builder.sh脚本，它能自动完成：检测内核完整版本、校验头文件与编译器、下载指定驱动源码、应用麒麟补丁、编译、签名、安装、更新initramfs。核心是将所有人工决策点参数化。

#!/bin/bash # kylin-driver-builder.sh # Usage: ./kylin-driver-builder.sh e1000e 3.8.7 # ./kylin-driver-builder.sh r8125 9.00 <p> <a href="https://download.csdn.net/download/lizheng2017/89368568" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>