On Tue, 2015-06-23 at 15:44 -0700, Saul Wold wrote:
> On 06/23/2015 02:53 PM, Richard Purdie wrote:
> > On Tue, 2015-06-23 at 12:22 -0700, Saul Wold wrote:
> >> The image bbclass will try to find the kernel-abiversion file which is not
> >> part
> >> of the linux-dummy kernel since there is no actual kernel. In this case
> >> using
> >> depmod also does not make sense since there should not be any kernel
> >> module built.
> >>
> >> [YOCTO #7884]
> >>
> >> Signed-off-by: Saul Wold <s...@linux.intel.com>
> >> ---
> >> meta/classes/image.bbclass | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> >> index 01f8b3f..be245e9 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?=
> >> "${FEATURE_INSTALL_OPTIONAL}"
> >> EXCLUDE_FROM_WORLD = "1"
> >>
> >> USE_DEVFS ?= "1"
> >> -USE_DEPMOD ?= "1"
> >> +USE_DEPMOD ?=
> >> '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
> >> "linux-dummy", "0", "1", d)}'
> >>
> >
> > I'm not convinced this is the right way to solve this. How about we
> > teach the code in rootfs.py not to generate a modules.dep file if there
> > are no kernel modules to generate dependency information for?
> >
> I guess we could check for /lib/modules, but I think checking for
> virtual/kernel is cleaner and safer since we know we don't want to run
> this for linux-dummy, but if some random recipe happens to create
> /lib/modules it will break.
>
> Unless you has some other check in mind to verify no modules are created
Something like "find -name *.ko" on /lib/modules was what I was
wondering about. Extrapolating, perhaps this code should iterate any
version directories here in case multiple sets of modules for different
kernel versions were installed? That way it wouldn't need to know about
the kernel-abiversion file?
> I also thought about a change to linux-dummy to place an
> kernel-abiversion, but that had other dangers.
Right. Unfortunately this file is used to populate KERNEL_VERSION
elsewhere and we may also have problems in those places with linux-dummy
too :/
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
