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

[Saul Wold <sgw@linux.intel.com>]

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@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

I also thought about a change to linux-dummy to place an 
kernel-abiversion, but that had other dangers.

Sau!

> Cheers,
>
> Richard
>