Repo

场景：YUM/DNF repo 仓库里没有你目标网卡固件 rpm 包，但你手里有独立的固件二进制文件；repo 里有另一款同系列网卡的固件 rpm，想下载这个 rpm，拆开替换里面的固件文件，再安装使用。

1、能不能直接下载 repo 的 rpm，解压替换固件，再装？

• 文件路径、文件权限、md5 校验
• %post脚本（固件加载触发、modprobe、depmod、initramfs 更新）
• 依赖关系、Provides 冲突标记

1. rpm 数据库不知道这个文件存在，后续yum update会覆盖删掉你的固件；
2. 升级内核 / 固件包时，系统会把你手动替换的固件冲掉；
3. initramfs 里的旧固件不会自动更新，开机早期驱动依然加载旧固件；
4. 缺少 post 脚本，不会自动刷新固件缓存，驱动可能识别不到新固件。

⚠严禁：直接修改 rpm 包内部文件，不重新构建 rpm 就 rpm‑ivh 强行安装，rpm 校验会失败，系统包数据库损坏风险。

2、正确两种实操方案

方案 A：重建 RPM 包（规范，适合批量、生产环境）

1. 下载源 rpm

2. 进入 rpmbuild 目录，把你自己的网卡固件二进制替换 SOURCES/ 下对应的固件文件；
3. 修改.spec：改固件文件名、版本号，不要和原有包版本冲突；
4. rpmbuild -ba xxx.spec，生成新的自定义 rpm；
5. 安装自定义 rpm：dnf install ./custom‑firmware‑xxx.rpm

安装后 rpm 数据库完整，yum 升级不会乱覆盖，% post 脚本自动执行 depmod、更新 initramfs。

方案 B：手动部署固件（应急，临时调试，不进 rpm 数据库）

1. 将你的网卡固件 bin 文件放到 /lib/firmware/<厂商目录>/
2. 设置正确权限：

3. 更新固件依赖缓存

4. 更新 initramfs，非常关键！ 内核启动阶段会从 initramfs 读固件，不更新重启还是旧固件

5. 重新加载驱动模块

缺点：

• rpm 数据库无记录，后续dnf update firmware‑*会删除你手动放的固件；
• 内核升级后 initramfs 重新生成，你的自定义固件丢失，需要重复操作。

3、重要风险点（踩坑高频）

1. 固件文件名必须严格匹配驱动请求的文件名
   dmesg 可以看驱动需要加载什么固件名字：

failed to load firmware "xxx/abc.bin"，你的固件文件名必须和这个完全一致，大小写敏感，名字错了驱动不会加载。哪怕固件内容是对的，文件名不对直接报错找不到固件。

2. 不要跨硬件型号混用固件。

   哪怕是同厂商，不同网卡型号固件不能乱刷，会导致网卡硬件挂起、网卡无法识别。
3. initramfs 一定要刷新。很多人替换完固件，reboot 后又变回旧版本，就是 initramfs 里面还打包了旧固件。
4. 如果系统启用 secure boot，自定义固件需要签名，否则内核拒绝加载外部固件。

4、什么时候不建议这么干

1. 生产环境长期运行，优先找官方对应 rpm 包，自制 rpm 只是应急手段；
2. Secure Boot 开启，你没有密钥签名，自定义固件无法加载；
3. 网卡固件存在硬件兼容性校验，固件版本和网卡硬件 PCB 版本不匹配，直接会网卡失联。

快速排查命令，替换完固件验证是否生效

总结

1. 可以借用 repo 现有 rpm 做模板，但是必须重新构建 rpm，不能简单解压替换文件直接用；
2. 应急调试可以手动丢 firmware 目录，但务必执行 depmod + dracut 更新 initramfs；
3. 文件名必须和驱动请求完全一致，secure boot 环境还要考虑签名。