单独编译 ipk 使用内核模块与第一次完整镜像内核模块不一致，导致无法安装

[shuosiw]

1.关于你要提交的问题

Q：是否搜索了issue (使用 "x" 选择)

• [x] 没有类似的issue

2. 详细叙述

(1) 路由器型号和固件版本

A：x86 软路由

(2) 具体问题

已经用仓库完整编译了一次 6.1 版本内核的镜像（修改了 target/linux/x86/Makefile 文件指定使用 6.1 内核）

KERNEL_PATCHVER:=6.1
KERNEL_TESTING_PATCHVER:=6.1

完整一次完整镜像编译后，再通过以下命令单独编译了 luci-app-chinadns-ng

git clone -b luci https://github.com/pexcn/openwrt-chinadns-ng.git package/luci-app-chinadns-ng
./scripts/feeds update -a
./scripts/feeds install luci
make menuconfig
make package/luci-app-chinadns-ng/{clean,compile} V=s

然后在 bin/packages/x86_64/base/ 找到编译好的 ipk 上传到软路由安装，发现还依赖着 5.15 版本内核，导致无法安装，安装报错：

# opkg install luci-app-chinadns-ng_1.1-7_all.ipk
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libpthread and libpthread) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (librt and librt) providing same name marked HOLD or PREFER. Using latest.
Package luci-app-chinadns-ng (1.1-7) installed in root is up to date.
Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-reject
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-ipt
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-log
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-ipt-core
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nfnetlink
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-ipt-ipset

也有重新确认，编译的完整镜像对应的内核模块都是 6.1 版本的：

$ grep kmod-nf bin/targets/x86/64/openwrt-x86-64-generic.manifest
kmod-nf-conntrack - 6.1.45-1
kmod-nf-conntrack6 - 6.1.45-1
kmod-nf-ipt - 6.1.45-1
kmod-nf-log - 6.1.45-1
kmod-nf-nat - 6.1.45-1
kmod-nf-nathelper - 6.1.45-1
kmod-nf-nathelper-extra - 6.1.45-1
kmod-nf-reject - 6.1.45-1
kmod-nf-tproxy - 6.1.45-1
kmod-nfnetlink - 6.1.45-1

不知道是什么情况，各位大佬有没遇到过哇？

[NEARWN]

不需要指定内核，默认编译就是6.1

[shuosiw]

不需要指定内核，默认编译就是6.1

因为我现在用的是 6.1.45 的内核，所以是 pull repo 后 checkout 到当时的 commit 来编译，以保证内核一致。

当时的编译默认是 5.15 内核，所以才做了这个修改。

不过这个不是关键问题，主要问题还是我编译出来完整镜像是 6.1 内核的了，为什么单独编译模块会用到 5.15 内核呢？

[NEARWN]

建议删除一下lede文件夹，重新git一下

[catsimple]

你要么把build_dir里的luci-app-chinadns-ng和相关依赖目录删干净了 要么就make clean

[shuosiw]

我重新拉了一个 debian11 的 docker 从零编译，最后出来的还是依赖 5.15 的 ipk，不知道那里出问题。

[shuosiw]

做了一个新的尝试，删掉 lede 目录重新 git clone 拉下来：

1. 切换到 https://github.com/coolsnowwolf/lede/commit/c5efeaff691ebccbf9419a92896404ab67c97bf4 这个 commit（对应 6.1.45 内核）
2. 将 target/linux/x86 这个目录下所有 5.x 的目录、文件全部删掉
3. 修改 target/linux/x86/Makefile 设置 KERNEL_TESTING_PATCHVER:=6.1
4. 重新完整、单线程进行一次编译（这样应该就不存在使用 5.x 内核的情况了吧）
5. 最后再拉下来 luci-app-chinadns-ng 单独编译模块

我最终编译的是 x86 平台的镜像以及 ipk，理论上这样的操作是不会再存在 5.x 内核的依赖了，但实际上编译出来的 ipk 还是同样的报错：

Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-reject
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-ipt
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nf-log
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-ipt-core
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-nfnetlink
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-61d44f65bd1b028e12cc87814825d543) for kmod-ipt-ipset

最后修改了 luci-app-chinadns-ng 的 makefile，把这个软件包的依赖全部删掉：

LUCI_DEPENDS:=

这样是可以编译出来 ipk 并且安装也不会报错，但是在 luci 页面的服务里面找不到 chinadns-ng 的入口了。

最后猜测，应该是固件里面的 passwall 自带了 chinadns-ng，但是与 luci-app-chinadns-ng 不匹配导致，到这里就不想再折腾了，直接用 passwall 的 chinadns-ng 吧。