简介本资源是专为银河麒麟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 I210e1000e芯片另一台是较新的Realtek RTL8125B 2.5G网卡。lspci -k显示设备被识别dmesg | grep e1000e却报Unknown symbol in modulemodprobe e1000e直接失败insmod ./e1000e.ko提示Invalid module format。这不是驱动源码本身的问题——官方e1000e-3.8.7和rtl8125-9.00.12源码在CentOS 7或Ubuntu 20.04上编译毫无压力。问题出在银河麒麟V10的“国产化加固链”上它默认启用内核模块强制签名CONFIG_MODULE_SIGy禁用未签名模块加载其/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 Mscripts sign-file2.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_TEXTgcc-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_SIGy且CONFIG_MODULE_SIG_FORCEy意味着任何未签名模块均被拒绝加载。modprobe或insmod会直接返回Required key not available。此时不能简单关闭该选项需重新编译内核不现实必须走签名流程。# 确认签名配置是否启用 $ zcat /proc/config.gz | grep -E (MODULE_SIG|MODULE_SIG_FORCE) CONFIG_MODULE_SIGy CONFIG_MODULE_SIG_FORCEy CONFIG_MODULE_SIG_ALLy CONFIG_MODULE_SIG_SHA512y # 若CONFIG_MODULE_SIG_FORCEy则跳过签名步骤将必然失败 # 注意CONFIG_MODULE_SIG_ALLy 表示内核启动时自动签名所有内置模块但不影响外部ko文件逻辑说明CONFIG_MODULE_SIG_FORCEy是麒麟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.ko3.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 CNkylin-kernel-signing-key # 因此 my_key.genkey 中需改为 [ distinguished_name ] CN kylin-kernel-signing-key3.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: yes3.7 故障回退当签名后仍报Required key not available时的三重检查即使完成上述步骤modprobe e1000e仍可能报错。此时需按优先级排查检查内核日志中的具体拒绝原因$ dmesg | tail -20 | grep -i signature\|key [ 1234.567890] module: e1000e: signature verification failed: -74 # -74 对应 EKEYREJECTED说明密钥不被信任确认签名密钥的CN与内核CA证书完全一致字符、空格、大小写$ openssl x509 -in kylin_signing_key.crt -noout -subject | tr -d subjectCNkylin-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 subjectCNkylin-kernel-signing-key # 必须一字不差验证签名后的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.hMakefile硬编码路径其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.diff4.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.ko4.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: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f4.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 -f5. 避坑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 -a5.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 macxx:xx:xx:xx:xx:xx | sudo tee /etc/modprobe.d/e1000e.conf $ sudo modprobe -r e1000e sudo modprobe e1000e5.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 -a5.4 现象ethtool eth1显示Speed: Unknown!Link detected: no原因rtl8125驱动加载后PHY初始化超时常见于BIOS中禁用了PCIe ASPMActive State Power Management。解决在GRUB启动参数中添加pcie_aspmoff$ sudo vi /etc/default/grub # 修改 GRUB_CMDLINE_LINUX 行添加 pcie_aspmoff GRUB_CMDLINE_LINUX... pcie_aspmoff $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg $ sudo reboot5.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: r81256. 进阶技巧构建可复用的麒麟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 hrefhttps://download.csdn.net/download/lizheng2017/89368568 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p