Buildroot LTS更新后的内核模块：vermagic、符号与签名

先区分装载、绑定和运行

内核升级后“驱动不能用了”，可能是模块加载器拒绝文件、模块已加载但没有绑定设备，或驱动已绑定但运行失败。首先判断失败发生在哪个边界。模块被拒绝不说明硬件损坏，模块插入成功也不能证明外设工作正常。把阶段分开，才不会在错误层面反复修改。

本文以Buildroot 2025.02产品流程为背景，内核行为固定核对Linux 6.12。Buildroot版本并不强制所有产品使用该内核。执行检查前，应保存实际部署的内核、模块和配置身份；本文没有加载、签名或上板测试任何驱动。

同时保存用户态错误和同一次尝试附近的内核消息。“模块格式无效”往往比内核详细说明的信息更少。记录启动镜像身份，以及加载工具实际解析到的模块路径；同名文件可能存在于不同镜像、更新目录或遗留位置。

# 只读示例：MODULE必须指向待检查的模块文件。
uname -r
modinfo -F vermagic "$MODULE"
modinfo -F depends "$MODULE"
modinfo -F signer "$MODULE"

命令假定modinfo支持相应字段，精简目标系统可能没有该工具，必要时在合适分析主机检查文件。不要为了收集日志而在生产机器随意插入模块；优先使用已有证据，或在具备恢复路径的获准实验系统复现。

比较运行内核release与模块构建时对应的release。版本魔数字符串还体现部分内核构建特性，其精确组成可查Linux v6.12源码。即便人读的源码版本相同，字符串差异也可能暴露不同配置。

字符串相同仍不代表所有ABI都兼容，下游补丁、导出接口和配置依然重要。出现差异时应使用正确内核产物重新构建，不应编辑字符串或使用强制参数跳过拒绝。强行装载移除了诊断边界，却没有消除真正的不兼容。

启用CONFIG_MODVERSIONS时，内核和模块会比较导出符号的版本信息。版本不符可能表明构建使用了不同接口定义；未知符号则可能来自未导出的接口、缺少依赖模块或不合适的配置。先读具体诊断并找到符号生产者，再决定采用哪种解释。

Linux 6.12外部模块说明解释了Module.symvers的作用，并指出modules_prepare不会为符号版本构建生成它。因此需要保留匹配的完整内核产物，用户态导出头文件不能替代。若符号来自另一外部模块，也要保存其配套版本及消费者构建时使用的符号信息。

模块可能ABI匹配，却因为签名缺失、无效或目标不信任而被拒绝；反之，可信签名也不能证明ABI兼容。检查CONFIG_MODULE_SIG相关设置和启动时强制策略，再确定目标信任哪个公钥。Linux 6.12签名说明区分了宽松与严格行为。

signer字段只是产物线索，不能证明运行内核信任它。签名私钥不能进入普通交付包或诊断材料。还应检查处理顺序，签名后的裁剪或内容修改可能使签名失效。发布记录应保存最终分发文件散列，而不是只有签名前的构建散列。

加载器检查通过后，检查依赖、别名与最终镜像中的模块依赖元数据。直接插入与自动解析依赖的加载路径可能表现不同。确认配套模块和固件实际存在于安装镜像，并与驱动版本对应，不能因为源码树里有固件就认为产品一定包含。

模块已加载但无设备绑定时，检查设备身份与描述或枚举路径；绑定后失败则单独保留探测或运行错误。分阶段记录能够防止把后续缺固件归咎于签名变更，也能避免通过替换硬件暂时掩盖原有内核和模块配对错误。

为已知正常镜像与候选镜像建立清单，包含内核release、内核配置散列、模块源码版本、模块散列、符号版本设置及签名策略身份。首先比较完整配对。把旧模块混入新内核，只能作为明确不受支持的诊断实验，不能充当发布验收路径。

重新构建解决问题后，仍应记录究竟是换对内核目录、重建符号信息、补齐依赖，还是修正签名顺序。否则下一次更新还会重新发现同一个手工修复。实验环境可以保留错误配对被拒绝的负向测试，记录类别，但不要因此给生产环境增加绕过机制。

验收应证明源码与内核产物可追踪，装载兼容检查和签名策略分别通过，依赖能够解析，设备成功绑定，约定功能测试通过。公开验证信息与最终散列进入发布清单，私密签名材料留在获准的安全系统。

这是诊断和验收顺序，不保证内部内核ABI长期稳定，也不代表驱动未来支持承诺。vermagic匹配、签名有效和加载成功分别回答更窄的问题。维护这些区别，下一次失败才能依据证据定位，而不是猜测根因或绕过保护。