kernel.bbclass: possible regression in Gatesgarth

kernel.bbclass: possible regression in Gatesgarth

[Andrea Adami]

Up to commit 86142da
https://git.openembedded.org/openembedded-core/commit/meta/classes/kernel.bbclass?id=86142dad13935a0d9af4a4177e05ff5c39003db7

in Gatesgarth it was possible to build a second mini-kernel w/out
modules, we have an example here:
https://git.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb

I you look at the recipe there is special care to avoid packaging:

# disable packaging related tasks
inherit nopackages

PACKAGES = ""
PROVIDES = ""

Now the change in kernel.bblass calls a packaging routine.:
do_deploy[prefuncs] += "read_subpackage_metadata"

This uncovers the first problem, even if we don't set/have KERNEL_DEVICETREE:
inherit kernel-devicetree

does unconditionally add some extra packages:

PACKAGES_append = " \
    ${KERNEL_PACKAGE_NAME}-devicetree \
    ${@[d.getVar('KERNEL_PACKAGE_NAME') + '-image-zimage-bundle',
''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
"

this causes the first failure:
ERROR: linux-kexecboot-4.4-r0 do_deploy: Recipe linux-kexecboot is
trying to create package kernel-devicetree which was already written
by recipe linux-handheld

So ok, here we can add some guards like:
- ${KERNEL_PACKAGE_NAME}-devicetree \
+ ${@ d.getVar('KERNEL_PACKAGE_NAME') + '-devicetree' if
(d.getVar('KERNEL_DEVICETREE')) else '' } \


but then the above call to read_subpackage_metadata() causes the second failure:
ERROR: linux-kexecboot-4.4-r0 do_deploy: Recipe linux-kexecboot is
trying to create package kernel-zimage which was already written by
recipe linux-handheld

in fcat here the problem is just the simlink to zImage in /boot
created by bthe second kernel build.

Again, note we don't set KERNEL_DEVICETREE with these legacy devices.

I don't know if this is a regression or not,  there is another way now
to build a second kernel, using a custom KERNEL_PACKAGE_NAME to get in
a subdir of DEPLOYDIR.

It's just that it used to work up to dunfell since years just avoiding
packaging.

If it can be fixed, well, ok, otherwise we'll have to adapt the BSP.

Cheers
A.A.

Re: kernel.bbclass: possible regression in Gatesgarth

[Andrea Adami]

On Mon, Jun 7, 2021 at 6:26 PM Andrea Adami <andrea.adami@gmail.com> wrote:
>
> Up to commit 86142da
> https://git.openembedded.org/openembedded-core/commit/meta/classes/kernel.bbclass?id=86142dad13935a0d9af4a4177e05ff5c39003db7
>
> in Gatesgarth it was possible to build a second mini-kernel w/out
> modules, we have an example here:
> https://git.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
>
> I you look at the recipe there is special care to avoid packaging:
>
> # disable packaging related tasks
> inherit nopackages
>
> PACKAGES = ""
> PROVIDES = ""
>
> Now the change in kernel.bblass calls a packaging routine.:
> do_deploy[prefuncs] += "read_subpackage_metadata"
>
> This uncovers the first problem, even if we don't set/have KERNEL_DEVICETREE:
> inherit kernel-devicetree
>
> does unconditionally add some extra packages:
>
> PACKAGES_append = " \
>     ${KERNEL_PACKAGE_NAME}-devicetree \
>     ${@[d.getVar('KERNEL_PACKAGE_NAME') + '-image-zimage-bundle',
> ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
> "
>
> this causes the first failure:
> ERROR: linux-kexecboot-4.4-r0 do_deploy: Recipe linux-kexecboot is
> trying to create package kernel-devicetree which was already written
> by recipe linux-handheld
>
> So ok, here we can add some guards like:
> - ${KERNEL_PACKAGE_NAME}-devicetree \
> + ${@ d.getVar('KERNEL_PACKAGE_NAME') + '-devicetree' if
> (d.getVar('KERNEL_DEVICETREE')) else '' } \
>
>
> but then the above call to read_subpackage_metadata() causes the second failure:
> ERROR: linux-kexecboot-4.4-r0 do_deploy: Recipe linux-kexecboot is
> trying to create package kernel-zimage which was already written by
> recipe linux-handheld
>
> in fcat here the problem is just the simlink to zImage in /boot
> created by bthe second kernel build.
>
> Again, note we don't set KERNEL_DEVICETREE with these legacy devices.
>
> I don't know if this is a regression or not,  there is another way now
> to build a second kernel, using a custom KERNEL_PACKAGE_NAME to get in
> a subdir of DEPLOYDIR.
>
> It's just that it used to work up to dunfell since years just avoiding
> packaging.
>
> If it can be fixed, well, ok, otherwise we'll have to adapt the BSP.
>
> Cheers
> A.A.

ping?