Hello Richard,
On Tue, Aug 31, 2021 at 3:32 PM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
>
> On Tue, 2021-08-31 at 06:28 +0200, Zoltan Boszormenyi via
> lists.openembedded.org
> wrote:
> > 2021. 08. 30. 21:51 keltezéssel, Jon Mason írta:
> > > On Mon, Aug 30, 2021 at 6:26 AM Andrey Zhizhikin <andre...@gmail.com>
> > > wrote:
> > > >
> > > > On Mon, Aug 30, 2021 at 12:06 PM Böszörményi Zoltán <zbos...@gmail.com>
> > > > 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 <zboszor=pr...@lists.openembedded.org> wrote:
> > > > > > > From: Zoltán Böszörményi <zbos...@gmail.com>
> > > > > > >
> > > > > > > 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 <zbos...@gmail.com>
> > > > > > > ---
> > > > > > > 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.
>
> Ross noticed it was failing with unexpanded AUTOINC references. That made me
> realise that using the unexpanded version of the variable in these cases might
> help. I've sent out that patch for review/testing.
This did solve the build issue! Thanks for narrowing it down!
>
> Cheers,
>
> Richard
>
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155532):
https://lists.openembedded.org/g/openembedded-core/message/155532
Mute This Topic: https://lists.openembedded.org/mt/85181063/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
