[OE-core] [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Richard Purdie]

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 <sgw at 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