2021. 08. 30. 21:51 keltezéssel, Jon Mason írta:
On Mon, Aug 30, 2021 at 6:26 AM Andrey Zhizhikin <[email protected]> wrote:
On Mon, Aug 30, 2021 at 12:06 PM Böszörményi Zoltán <[email protected]> wrote:
2021. 08. 30. 11:30 keltezéssel, Andrey Zhizhikin írta:
Hello Zoltan,
On Fri, Aug 27, 2021 at 9:37 AM Zoltan Boszormenyi via
lists.openembedded.org <[email protected]> wrote:
From: Zoltán Böszörményi <[email protected]>
If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.
The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.
This creates an issue because then the modules either don't work
or taint the kernel.
Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.
The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.
Signed-off-by: Zoltán Böszörményi <[email protected]>
---
meta/classes/kernel.bbclass | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
I'm seeing errors during the do_rootfs() with this patch applied,
there are few messages like this:
* Solver encountered 1 problem(s):
* Problem 1/1:
* - package
kernel-module-libchacha-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-5.13.13+g91381833a4e2, but none of the providers can
be installed
* - package kernel-modules-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-module-libchacha-5.13.13+g91381833a4e2, but none of
the providers can be installed
* - package
kernel-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-image-5.13.13+g91381833a4e2 =
5.13.13+git0+91381833a4-r0, but none of the providers can be installed
* - conflicting requests
* - nothing provides kernel-image-image-5.13.13+g91381833a4e2 =
5.13.13+gitAUTOINC+91381833a4-r0 needed by
This seems to be the problem.
Is there a "kernel-image-image-5.13.13" built from your kernel recipe?
Yes, it is produced. But for some reasons opkg cannot resolve it
during the do_rootfs(), which is quite odd.
I'm seeing the same issue. All of the BSPs that I set the kernel to
not be 5.13 (i.e., 5.10, 5.4, etc) fail. For example,
https://gitlab.com/jonmason00/meta-arm/-/jobs/1544819828
If I set the PACKAGE_CLASS to be rpm instead of ipk, everything works
as expected. So, there must be some difference in the dep calculation
in ipk.
Interesting.
Can you both please try setting KERNEL_SPLIT_MODULES="0" in your kernel recipe?
In my testing, it works for both ipk and rpm properly.
I am thinking that probably the full version dependency should
only be used in the KERNEL_SPLIT_MODULES="0" case.
This can be easily tested, unlike the packaging method.
Thanks,
Jon
For me, a kernel-image-bzimage-x.y.z is built.
kernel-image-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
*
* Solution 1:
* - do not ask to install a package providing kernel-modules
Reverting this commit does solve it, but I would like to understand
more on what should be done in order to use this new mechanism you've
introduced. Do you have any suggestion on what should be adapted in
the BSP layer to have those RDEPENDS properly resolved?
Package manager is set for me to IPK.
Setting KERNEL_SPLIT_MODULES="1" does not solve the issue.
This is the default.
But setting it to "0" won't change whether the
kernel-image-image-x.y.z subpackage gets built or not.
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155515):
https://lists.openembedded.org/g/openembedded-core/message/155515
Mute This Topic: https://lists.openembedded.org/mt/85181063/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
