☰

insmod 失败 - 模块与正在运行的内核不匹配，但模块已针对正确的内核进行编译

tag-icon • tag-icon linux linux-kernel drivers kernel-modules
insmod 失败 - 模块与正在运行的内核不匹配，但模块已针对正确的内核进行编译

搬自这里因为这是正确的 StackExchange。

目标

  • 在 Rocky Linux 9 上重新编译 NVMe 驱动程序，无需任何更改（我想做一些，但现在我只是想获得一个工作模块）

更新如下

  1. 我找出了导致符号错误的原因。这是由于没有首先加载 nvme-common 造成的。 nvme-core 依赖于 nvme-common，因此您必须先加载它，这样做可以让我克服该错误。
  2. 现在我有同样的问题这个问题。一切都表明内核版本之间存在一些差异，但正如该人指出的那样，我能找到的所有内容都匹配。

我的新设置是：

dnf install -y rpm-build rpmdevtools git python3-devel make gcc flex bison kernel-headers ncurses-devel tmux elfutils-libelf-devel openssl-devel bc kernel-devel-$(uname -r) dwarves
rpmdev-setuptree
dnf download --source kernel
rpm -ivh kernel-5.14.0-362.18.1.el9_3.src.rpm
rpmbuild -bp kernel.spec
cd /root/rpmbuild/BUILD/kernel-5.14.0-362.18.1.el9_3/linux-5.14.0-362.18.1.el9.x86_64/
cp -f /boot/config-$(uname -r) .config
cp -f /usr/src/kernels/$(uname -r)/Module.symvers .
make -j$(nproc --all) scripts prepare modules_prepare
make ARCH=x86_64 -j$(nproc --all) M=drivers/nvme
insmod drivers/nvme/common/nvme-common.ko
insmod drivers/nvme/host/nvme-core.ko

这样做也可以使依赖关系完美匹配。

我在做什么

  1. 更新所有内容 ( dnf update -y && reboot) 并重新启动以确保其全部位于需要的位置
  2. 安装标头dnf install -y kernel-headers ncurses-devel
  3. 获取内核源代码dnf download --source kernel && rpm2cpio kernel-5.14.0-362.18.1.el9_3.src.rpm | cpio -idmv && tar -xf linux-5.14.0-362.18.1.el9_3.tar.xz（这是我获取 NVMe 源代码的地方）
  4. Module.symvers从标题中拉入cp /usr/src/kernels/5.14.0-362.18.1.el9_3.x86_64/Module.symvers .
  5. 从我的特定内核中提取配置cp /boot/config-$(uname -r) .config
  6. 运行以下命令来构建：
make clean
cp -f /boot/config-$(uname -r) .config
cp -f /usr/src/kernels/5.14.0-362.18.1.el9_3.x86_64/Module.symvers .
make -j$(nproc --all) scripts prepare modules_prepare
make ARCH=x86_64 -j$(nproc --all) M=drivers/nvme

问题

如果我将 NVMe 选项保留为默认值：

在此输入图像描述

然后构建它会产生以下错误：

[23890.056877] nvme_core: disagrees about version of symbol nvme_auth_gen_shared_secret
[23890.056881] nvme_core: Unknown symbol nvme_auth_gen_shared_secret (err -22)
[23890.057140] nvme_core: disagrees about version of symbol nvme_auth_gen_pubkey
[23890.057142] nvme_core: Unknown symbol nvme_auth_gen_pubkey (err -22)
[23890.057471] nvme_core: disagrees about version of symbol nvme_auth_gen_privkey
[23890.057472] nvme_core: Unknown symbol nvme_auth_gen_privkey (err -22)

如果我更新选项以删除所有我不关心的内容，我会收到不同的错误：

在此输入图像描述

module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 0000000087bc08cc, val ffffffffc071647a

但我完全不知所措。网上的所有内容都说造成这种情况的原因是不同的内核版本，但我不知道在哪里。每个资源似乎都在说一些关于确保.config和Module.symvers匹配我所做的事情。

以下是修改后的/原始的两个模块的比较：

[root@nvmetest linux-5.14.0-362.18.1.el9_3]# !mod
modinfo ./drivers/nvme/host/nvme-core.ko
filename:       /root/new_driver/linux-5.14.0-362.18.1.el9_3/./drivers/nvme/host/nvme-core.ko
version:        1.0
license:        GPL
rhelversion:    9.3
srcversion:     A869617A5E58420845515F4
depends:        t10-pi
retpoline:      Y
name:           nvme_core
vermagic:       5.14.0 SMP preempt mod_unload modversions
parm:           multipath:turn on native support for multiple controllers per subsystem (bool)
parm:           iopolicy:Default multipath I/O policy; 'numa' (default) or 'round-robin'
parm:           admin_timeout:timeout in seconds for admin commands (uint)
parm:           io_timeout:timeout in seconds for I/O (uint)
parm:           shutdown_timeout:timeout in seconds for controller shutdown (byte)
parm:           max_retries:max number of retries a command may have (byte)
parm:           default_ps_max_latency_us:max power saving latency for new devices; use PM QOS to change per device (ulong)
parm:           force_apst:allow APST for newly enumerated devices even if quirked off (bool)
parm:           apst_primary_timeout_ms:primary APST timeout in ms (ulong)
parm:           apst_secondary_timeout_ms:secondary APST timeout in ms (ulong)
parm:           apst_primary_latency_tol_us:primary APST latency tolerance in us (ulong)
parm:           apst_secondary_latency_tol_us:secondary APST latency tolerance in us (ulong)
[root@nvmetest linux-5.14.0-362.18.1.el9_3]# modinfo /lib/modules/5.14.0-362.18.1.el9_3.x86_64/kernel/drivers/nvme/host/nvme-core.ko.xz
filename:       /lib/modules/5.14.0-362.18.1.el9_3.x86_64/kernel/drivers/nvme/host/nvme-core.ko.xz
version:        1.0
license:        GPL
rhelversion:    9.3
srcversion:     ADFE53FFFB5D30ECFF130B0
depends:        nvme-common,t10-pi
retpoline:      Y
intree:         Y
name:           nvme_core
vermagic:       5.14.0-362.18.1.el9_3.x86_64 SMP preempt mod_unload modversions
sig_id:         PKCS#7
signer:         Rocky kernel signing key
sig_key:        37:B0:46:2C:D4:62:CB:E7:6C:CA:AE:9F:2A:A2:BE:E1:36:3A:8A:AF
sig_hashalgo:   sha256
signature:      60:89:BA:1D:1C:71:38:82:DF:09:73:B4:23:3E:C8:FE:7B:E4:9F:0D:
                62:6E:28:D7:3E:5A:5E:11:CD:7B:D2:52:E2:C6:ED:5E:B6:A7:19:54:
                8A:FB:BB:E8:2D:A5:77:3F:A1:C1:7E:EB:45:74:30:E9:18:1C:3D:9A:
                53:4A:2B:B0:1E:F0:35:D3:D1:E5:B6:A5:D0:47:6C:2F:B7:C6:6F:00:
                30:0E:82:BA:FD:4F:9D:0E:3B:4A:17:A4:1B:E8:31:FC:FB:BC:C2:93:
                1C:6D:5E:94:FD:DE:65:3B:3E:0B:F4:B4:B0:82:67:87:8C:90:C9:74:
                44:BB:14:D9:F9:43:33:CC:CC:77:29:11:2C:3D:79:30:EA:B3:63:74:
                F3:02:F0:DA:68:40:BA:65:B0:E5:D8:90:FF:B0:CA:8D:D7:31:00:47:
                FE:9C:B9:17:8F:81:1D:7F:45:F6:98:E8:14:1F:73:99:00:51:18:48:
                1F:29:98:F4:37:FA:62:46:FF:1B:64:B5:1F:03:C3:5C:87:2E:13:9E:
                EE:8C:32:DE:D8:B6:3F:1D:C2:69:45:46:E2:8B:E4:BD:C2:7C:00:14:
                3F:7B:76:C8:43:4E:ED:24:BE:C8:9D:85:16:C6:9B:55:1F:BA:7B:39:
                07:57:A7:46:1A:E4:98:D5:29:C9:27:07:0B:3A:FE:6D:49:4B:DD:24:
                E0:4C:99:C1:C4:88:4D:E1:D9:78:EC:46:4F:D6:94:D6:93:B0:D4:24:
                23:08:40:35:F9:41:0D:1E:4A:78:3C:B2:A9:DB:51:C9:D0:96:F5:64:
                43:7E:FF:69:71:09:06:9D:79:B0:56:A0:49:71:69:64:3D:50:B6:0B:
                DE:A0:FA:36:D7:86:AD:B9:2A:8C:11:B5:73:F3:C5:2B:C5:2F:C2:A6:
                AB:7F:01:B1:E6:60:8F:6A:F0:A1:AE:A9:32:E1:30:DA:4D:7A:98:F5:
                89:F7:7B:4D:FF:23:4B:77:29:BA:62:1B:54:09:1F:33:57:8F:44:A3:
                FE:19:D6:43
parm:           multipath:turn on native support for multiple controllers per subsystem (bool)
parm:           iopolicy:Default multipath I/O policy; 'numa' (default) or 'round-robin'
parm:           admin_timeout:timeout in seconds for admin commands (uint)
parm:           io_timeout:timeout in seconds for I/O (uint)
parm:           shutdown_timeout:timeout in seconds for controller shutdown (byte)
parm:           max_retries:max number of retries a command may have (byte)
parm:           default_ps_max_latency_us:max power saving latency for new devices; use PM QOS to change per device (ulong)
parm:           force_apst:allow APST for newly enumerated devices even if quirked off (bool)
parm:           apst_primary_timeout_ms:primary APST timeout in ms (ulong)
parm:           apst_secondary_timeout_ms:secondary APST timeout in ms (ulong)
parm:           apst_primary_latency_tol_us:primary APST latency tolerance in us (ulong)
parm:           apst_secondary_latency_tol_us:secondary APST latency tolerance in us (ulong)
[root@nvmetest linux-5.14.0-362.18.1.el9_3]#

我可以使用 强制版本魔法完全相同CONFIG_LOCALVERSION，但产生的错误是相同的。这个帖子也表明基础内核版本足够。

答案1

当我不顾警告尝试 depmod 时，对内核进行了核攻击后，我进行了重建。重建后我做了以下事情：

确认没有可用的更新。如果有，请更新后重新启动盒子。然后：

dnf install -y rpm-build rpmdevtools git python3-devel make gcc flex bison kernel-headers ncurses-devel tmux elfutils-libelf-devel openssl-devel bc kernel-devel-$(uname -r) dwarves
rpmdev-setuptree
dnf download --source kernel
rpm -ivh kernel-5.14.0-362.18.1.el9_3.src.rpm
cd /root/rpmbuild/SPECS
rpmbuild -bp kernel.spec
cd /root/rpmbuild/BUILD/kernel-5.14.0-362.18.1.el9_3/linux-5.14.0-362.18.1.el9.x86_64/
cp -f /boot/config-$(uname -r) .config
cp -f /usr/src/kernels/$(uname -r)/Module.symvers .
make -j$(nproc --all) scripts prepare modules_prepare
make ARCH=x86_64 -j$(nproc --all) M=drivers/nvme
insmod drivers/nvme/common/nvme-common.ko
insmod drivers/nvme/host/nvme-core.ko

我不知道三角洲是什么。我检查了至少十几次我的内核源与之前运行的内核相匹配的不同方式，但显然我错过了一些东西。在重建时，上述第一次尝试就完美地工作了。

答案2

解决方案

在看到我的评论上面的额外内容后DEPENDS，我查了一下Linux 内核驱动程序数据库：CONFIG_NVME_COMMON。根据该链接，该选项仅从内核版本 6 开始可用。这促使我写下这个答案，该答案以以下问题开头：当存储库中没有 6.x 分支内核时，我们如何在基于 RedHat/Fedora 的发行版上获取它？

我们有两个选择：

  1. 我们可以建立我们自己的。
  2. 我们可以添加企业 Linux 存储库，其中 6.x 内核版本可用，并且可能还有 OP 所需的 NVMe 驱动程序。

自从Rocky 是 CentOS 的一个分支，而 CentOS 是 RedHat Enterprise Linux 的一个分支，#2 似乎是理想的选择。引用他们的主页：

ELRepo 项目专注于与硬件相关的软件包，以增强您的 Enterprise Linux 体验。这包括 SCSI/SATA/PATA 驱动程序、文件系统驱动程序、图形驱动程序、网络驱动程序、声音驱动程序和视频驱动程序。

该引用没有提到的是，存储库还包含更新的内核。我本来打算手动编写获取该内核所需的步骤，但为了简洁起见，并希望 OP 所需的驱动程序也在该存储库中，我找到了多个包含这些说明的链接：

如您所见，两个链接中的步骤是相同的​​。如果我们开始出现链接腐烂的情况，我会在某个时候添加它们。从存储库升级内核后elrepo-kernel，根据任一链接，我将搜索 EL 存储库以查看 OP 的驱动程序是否也可用。如果不是，OP 可以自由使用上面提供的选项 1，我相信这是他开始的地方。

相关内容