Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 7/26/21 8:48 AM, Rasmus Villemoes wrote: Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the same way with and without the RRECOMMENDS in play: With RRECOMMENDS, where the build succeeds: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] And no further mention of kernel-module-abcd. Without the RRECOMMENDS: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] ERROR: Unable to install packages. Command '[...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...]' returned 255: * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'kernel-module-abcd'. That's helpful info; thanks. I'll paste it to the bug in the opkg bugzilla and we can continue tracking there. -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154216): https://lists.openembedded.org/g/openembedded-core/message/154216 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 06/07/2021 21.39, Alex Stewart wrote: > Hey Rasmus, > > Sorry for the delay; I was OOO for the holidays and I'm just now working > through my inbox. No need to apologize; as it happens I've just now returned from vacation. > On 6/28/21 4:17 AM, Rasmus Villemoes wrote: >> On 25/06/2021 18.13, Richard Purdie wrote: >>> That is probably a bug that needs opening against opkg in bugzilla then. >>> Added Alex to Cc: (opkg maintainer). >> Indeed, thanks. Alex, do you have enough context from the above, or do I >> need to do anything explicitly to file a bug? >> >> Rasmus > > Could you expand a bit on how OE is supposed to fail when the kernel > module package is unsatisfiable? Does it propagate a opkg satisfaction > error, or is the misconfiguration caught in the OE python modules? > > I ask because it seems most likely to me that the inconsistency here is > in the OE opkg interface modules, rather than opkg itself - which > obviously has no concept of IMAGE_INSTALL or the kernel configuration. > > Can you identify the set of packages that OE is requesting opkg to > install, with and without the RRECOMMENDS? Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the same way with and without the RRECOMMENDS in play: With RRECOMMENDS, where the build succeeds: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] And no further mention of kernel-module-abcd. Without the RRECOMMENDS: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] ERROR: Unable to install packages. Command '[...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...]' returned 255: * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'kernel-module-abcd'. So I assume the difference must be in some of the metadata files (opkg.conf or the ipktemp/ dir argument to the -t flag), but I know nothing about how opkg/ipk works internally or what to look for. Thanks, Rasmus -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154143): https://lists.openembedded.org/g/openembedded-core/message/154143 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 7/6/21 3:12 PM, Richard Purdie wrote: Kernel modules can be: a) not built at all b) built into the kernel3 c) built as separate packages For OE, where something needs a kernel module, we suggest people: RRECOMMEND_XXX += "kernel-module-xxx" and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*". From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC covers kernel-modules-xxx) and then hands off to the package manager. In the case it was built in, the Recommends will be passed over by the package manager since it is just a suggestion. If the module is present, it would be included in the image. The issue as described is that if someone has IMAGE_INSTALL containing kernel-module-xxx *and* some other package in the image RRECOMMENDS that module, it doesn't error if the package doesn't exist. I have to admit I don't remember how IMAGE_INSTALL is being passed into opkg but the change in behaviour due to the addition of a RRECOMMENDS does not sound right to me. The rpm backend does not do that but errors consistently. Yep; I understand all of that and agree. My goal here is just to make sure that the bug is filed to the correct location. As it stands, the only description of the error is from OE's perspective, and I'd like to get some understanding of the interface between OE and opkg, for this special case. It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled by the Recommends from some sub package dependency. I know that IMAGE_INSTALL gets consumed into PACKAGE_INSTALL, which gets pass off to the PM modules (iirc.) And I also recall there being a PACKAGE_INSTALL_ATTEMPTONLY variable[1]. I wonder if RRECOMMENDS are being ATTEMPTed (either through that variable, or a similar one), and the failed attempt is pre-empting the mandatory install attempt. Worth looking into. [1] https://git.openembedded.org/openembedded-core/tree/meta/classes/image.bbclass#n79 If we're driving opkg incorrectly, we should fix that but I'm not sure where the issue is, I suspect opkg... Why do you suspect opkg? The situation from its perspective is only that `kernel-module-xxx` is recommended by another package, but not available in the feeds. There's nothing invalid about that state that would cause opkg to throw an error. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153626): https://lists.openembedded.org/g/openembedded-core/message/153626 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On Tue, 2021-07-06 at 14:39 -0500, Alex Stewart wrote: > Hey Rasmus, > > Sorry for the delay; I was OOO for the holidays and I'm just now working > through my inbox. > > On 6/28/21 4:17 AM, Rasmus Villemoes wrote: > > On 25/06/2021 18.13, Richard Purdie wrote: > > > That is probably a bug that needs opening against opkg in bugzilla then. > > > Added Alex to Cc: (opkg maintainer). > > Indeed, thanks. Alex, do you have enough context from the above, or do I > > need to do anything explicitly to file a bug? > > > > Rasmus > > Could you expand a bit on how OE is supposed to fail when the kernel > module package is unsatisfiable? Does it propagate a opkg satisfaction > error, or is the misconfiguration caught in the OE python modules? > > I ask because it seems most likely to me that the inconsistency here is > in the OE opkg interface modules, rather than opkg itself - which > obviously has no concept of IMAGE_INSTALL or the kernel configuration. > > Can you identify the set of packages that OE is requesting opkg to > install, with and without the RRECOMMENDS? That would help to > distinguish between an inconsistency in the OE PackageManager modules > and a bug in opkg itself. Kernel modules can be: a) not built at all b) built into the kernel c) built as separate packages For OE, where something needs a kernel module, we suggest people: RRECOMMEND_XXX += "kernel-module-xxx" and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*". >From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC covers kernel-modules-xxx) and then hands off to the package manager. In the case it was built in, the Recommends will be passed over by the package manager since it is just a suggestion. If the module is present, it would be included in the image. The issue as described is that if someone has IMAGE_INSTALL containing kernel-module-xxx *and* some other package in the image RRECOMMENDS that module, it doesn't error if the package doesn't exist. I have to admit I don't remember how IMAGE_INSTALL is being passed into opkg but the change in behaviour due to the addition of a RRECOMMENDS does not sound right to me. The rpm backend does not do that but errors consistently. It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled by the Recommends from some sub package dependency. If we're driving opkg incorrectly, we should fix that but I'm not sure where the issue is, I suspect opkg... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153625): https://lists.openembedded.org/g/openembedded-core/message/153625 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
Hey Rasmus, Sorry for the delay; I was OOO for the holidays and I'm just now working through my inbox. On 6/28/21 4:17 AM, Rasmus Villemoes wrote: On 25/06/2021 18.13, Richard Purdie wrote: That is probably a bug that needs opening against opkg in bugzilla then. Added Alex to Cc: (opkg maintainer). Indeed, thanks. Alex, do you have enough context from the above, or do I need to do anything explicitly to file a bug? Rasmus Could you expand a bit on how OE is supposed to fail when the kernel module package is unsatisfiable? Does it propagate a opkg satisfaction error, or is the misconfiguration caught in the OE python modules? I ask because it seems most likely to me that the inconsistency here is in the OE opkg interface modules, rather than opkg itself - which obviously has no concept of IMAGE_INSTALL or the kernel configuration. Can you identify the set of packages that OE is requesting opkg to install, with and without the RRECOMMENDS? That would help to distinguish between an inconsistency in the OE PackageManager modules and a bug in opkg itself. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153624): https://lists.openembedded.org/g/openembedded-core/message/153624 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On Mon, 2021-06-28 at 11:17 +0200, Rasmus Villemoes wrote:
> On 25/06/2021 18.13, Richard Purdie wrote:
> > On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
> > > On 25/06/2021 14.16, Richard Purdie wrote:
> > > > On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
> > > > lists.openembedded.org wrote:
> > > > > I noticed that if I have an image recipe that says
> > > > >
> > > > > IMAGE_INSTALL += "kernel-module-foo"
> > > > >
> > > > > it fails as expected when the kernel hasn't been built with
> > > > > CONFIG_FOO=m.
> > > > >
> > > > > However, if at the same time some other package which happens to get
> > > > > installed in the same image says
> > > > >
> > > > > RRECOMMENDS_${PN} += "kernel-module-foo"
> > > > >
> > > > > the image build silently succeeds, obviously without any foo.ko
> > > > > included. This doesn't seem right. [I'm well aware that the
> > > > > RRECOMMENDS
> > > > > line alone works as expected, this is about the case where both the
> > > > > above lines are in play.]
> > > >
> > > > Which package backend are you using and does this happen if you
> > > > use a different one, particularly swapping ipk and rpm?
> > > >
> > > > That might tell us if this is a package manager issue or a bitbake
> > > > metadata one.
> > >
> > > I was using ipk. It seems to work as expected (i.e. fail the build) when
> > > using rpm.
> >
> > That is probably a bug that needs opening against opkg in bugzilla then.
> > Added Alex to Cc: (opkg maintainer).
>
> Indeed, thanks. Alex, do you have enough context from the above, or do I
> need to do anything explicitly to file a bug?
Please open a bug in bugzilla: https://bugzilla.yoctoproject.org/
That way we ensure it is tracked and doesn't get lost.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153353):
https://lists.openembedded.org/g/openembedded-core/message/153353
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 25/06/2021 18.13, Richard Purdie wrote:
> On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
>> On 25/06/2021 14.16, Richard Purdie wrote:
>>> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
>>> lists.openembedded.org wrote:
I noticed that if I have an image recipe that says
IMAGE_INSTALL += "kernel-module-foo"
it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
However, if at the same time some other package which happens to get
installed in the same image says
RRECOMMENDS_${PN} += "kernel-module-foo"
the image build silently succeeds, obviously without any foo.ko
included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
line alone works as expected, this is about the case where both the
above lines are in play.]
>>>
>>> Which package backend are you using and does this happen if you
>>> use a different one, particularly swapping ipk and rpm?
>>>
>>> That might tell us if this is a package manager issue or a bitbake
>>> metadata one.
>>
>> I was using ipk. It seems to work as expected (i.e. fail the build) when
>> using rpm.
>
> That is probably a bug that needs opening against opkg in bugzilla then.
> Added Alex to Cc: (opkg maintainer).
Indeed, thanks. Alex, do you have enough context from the above, or do I
need to do anything explicitly to file a bug?
Rasmus
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153352):
https://lists.openembedded.org/g/openembedded-core/message/153352
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
> On 25/06/2021 14.16, Richard Purdie wrote:
> > On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
> > lists.openembedded.org wrote:
> > > I noticed that if I have an image recipe that says
> > >
> > > IMAGE_INSTALL += "kernel-module-foo"
> > >
> > > it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
> > >
> > > However, if at the same time some other package which happens to get
> > > installed in the same image says
> > >
> > > RRECOMMENDS_${PN} += "kernel-module-foo"
> > >
> > > the image build silently succeeds, obviously without any foo.ko
> > > included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
> > > line alone works as expected, this is about the case where both the
> > > above lines are in play.]
> >
> > Which package backend are you using and does this happen if you
> > use a different one, particularly swapping ipk and rpm?
> >
> > That might tell us if this is a package manager issue or a bitbake
> > metadata one.
>
> I was using ipk. It seems to work as expected (i.e. fail the build) when
> using rpm.
That is probably a bug that needs opening against opkg in bugzilla then.
Added Alex to Cc: (opkg maintainer).
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153281):
https://lists.openembedded.org/g/openembedded-core/message/153281
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 25/06/2021 14.16, Richard Purdie wrote:
> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
> lists.openembedded.org wrote:
>> I noticed that if I have an image recipe that says
>>
>> IMAGE_INSTALL += "kernel-module-foo"
>>
>> it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
>>
>> However, if at the same time some other package which happens to get
>> installed in the same image says
>>
>> RRECOMMENDS_${PN} += "kernel-module-foo"
>>
>> the image build silently succeeds, obviously without any foo.ko
>> included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
>> line alone works as expected, this is about the case where both the
>> above lines are in play.]
>
> Which package backend are you using and does this happen if you
> use a different one, particularly swapping ipk and rpm?
>
> That might tell us if this is a package manager issue or a bitbake
> metadata one.
I was using ipk. It seems to work as expected (i.e. fail the build) when
using rpm.
Rasmus
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153280):
https://lists.openembedded.org/g/openembedded-core/message/153280
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org
wrote:
> I noticed that if I have an image recipe that says
>
> IMAGE_INSTALL += "kernel-module-foo"
>
> it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
>
> However, if at the same time some other package which happens to get
> installed in the same image says
>
> RRECOMMENDS_${PN} += "kernel-module-foo"
>
> the image build silently succeeds, obviously without any foo.ko
> included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
> line alone works as expected, this is about the case where both the
> above lines are in play.]
Which package backend are you using and does this happen if you
use a different one, particularly swapping ipk and rpm?
That might tell us if this is a package manager issue or a bitbake
metadata one.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153271):
https://lists.openembedded.org/g/openembedded-core/message/153271
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
I noticed that if I have an image recipe that says
IMAGE_INSTALL += "kernel-module-foo"
it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
However, if at the same time some other package which happens to get
installed in the same image says
RRECOMMENDS_${PN} += "kernel-module-foo"
the image build silently succeeds, obviously without any foo.ko
included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
line alone works as expected, this is about the case where both the
above lines are in play.]
=
So I discovered this while trying to figure out how to be able to say
IMAGE_INSTALL += "kernel-module-ext4" , and have that succeed whenever
ext4 is builtin or modular, and have it be a build time error if the
kernel was built with EXT4=n - so the recommends approach is out. It
obviously doesn't work out-of-the-box for the EXT4=y case. So now I'm
contemplating doing
python kernel_base_provide_builtin () {
kname = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
builtin = os.path.join(d.getVar("PKGD"), "lib/modules",
d.getVar("KERNEL_VERSION"), "modules.builtin")
if not os.path.exists(builtin):
return
builtin_mods = []
with open(builtin) as f:
for mod in f:
mod = mod.strip()
mod = os.path.basename(mod)
if not mod.endswith(".ko"):
continue
mod = mod[:-3]
mod = mod.lower().replace("_", "-")
builtin_mods.append("%s-module-%s" % (kname, mod))
basepkg = kname + "-base"
rprovides = (d.getVar("RPROVIDES_" + basepkg) or "").split()
rprovides += builtin_mods
d.setVar("RPROVIDES_" + basepkg, " ".join(rprovides))
}
PACKAGESPLITFUNCS += "kernel_base_provide_builtin"
i.e., make sure that the kernel-base package is an rprovider of
kernel-module-ext4 for the EXT4=y case [*]. That seems to work as
expected in the cases I've tried (provided nobody rrecommends ext4, per
above). Does anybody see anything wrong with that approach? EXT4 is just
an example, I'm gonna use it for other modules/subsystems with more
complicated dependencies that might not be satisfied in a base .config,
so a fragment saying CONFIG_FOO=m might have been ignored due to that,
and I'd prefer catching that no later than at image build time.
I'm not necessarily suggesting the above for oe-core, I can live with it
in my own kernel recipes.
[*] kernel-base and not the package containing the actual kernel binary,
because kernel-base contains the modules.builtin file which is what
modprobe consults first to see if it actually has to do anything, so it
makes sense to have kernel-module-ext4 pull in that file and the other
/lib/modules/ metadata when EXT4=y. The kernel binary is as often as not
not actually in the rootfs image, and wouldn't be useful to modprobe anyway.
Rasmus
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153266):
https://lists.openembedded.org/g/openembedded-core/message/153266
Mute This Topic: https://lists.openembedded.org/mt/83779506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
