[OE-core] [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image

Ming Liu liu.ming50 at gmail.com
Tue Jan 26 22:12:53 UTC 2016



On 01/22/2016 09:39 PM, Bruce Ashfield wrote:
> On 16-01-20 6:29 PM, Ming Liu wrote:
>>
>>
>> On 01/20/2016 05:43 AM, Bruce Ashfield wrote:
>>> On 2016-01-19 4:57 PM, Ming Liu wrote:
>>>>
>>>>
>>>> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>>>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>>>> From: Ming Liu <peter.x.liu at external.atlascopco.com>
>>>>>>
>>>>>> It makes no sense to install a initramfs bundled kernel image since
>>>>>> do_package does not depend on do_bundle_initramfs at all,
>>>>>> otherwise, it
>>>>>> leads to a implicit kernel-image package depending on do_package run
>>>>>> before
>>>>>> or after do_bundle_initramfs.
>>>>>
>>>>> Again. So why not just add the ordering in the task dependencies ?
>>>> If we add a intertask dependency like:
>>>> add bundle_initramfs before do_install after do_deploy do_package
>>>>
>>>> Then it will somehow introduce a circular dependency as I described in
>>>> another mail.
>>>>>
>>>>> I'm probably missing something, which just means we need to tweak
>>>>> the commit log a bit more.
>>>> Maybe I should add some description in commit log about why I think we
>>>> could not introduce a intertask dependency as a fix.
>>>>
>>>
>>> That would be ideal, the more information the better.
>>>
>>>>>
>>>>> The code you are removing is conditional, and is run after an
>>>>> explicit kernel_do_compile is called, to rebuild the existing
>>>>> kernel configuration with an embedded initramfs (via alternate 
>>>>> initrd).
>>>>> So outside of some ordering/parallel execution issues, I'm not seeing
>>>>> it as broken.
>>>> Yes, I agree, it will not break the kernel re-compiling, the problem I
>>>> want to fix here is just that it does not provide a certain way 
>>>> that we
>>>> could add initramfs bundled kernel image into a rootfs.
>>>>
>>>
>>> Speaking of breaking. What happens to existing users of 
>>> INITRAMFS_IMAGE?
>>> Do their existing image types and bundling continue to work without
>>> modification ?
>> That depends, the existing users always can find the INITRAMFS_IMAGE
>> bundled kernel in DEPLOY_DIR with or without my patches, it is not
>> broken. But if they want it installed in the rootfs, for some reasons,
>> they will have the problem, like in my company, we want to boot the
>> kernel from /boot/ on a USB disk, but it is not guaranteed we will get
>> the INITRAMFS_IMAGE bundled kernel there during the build.
>
> Right. And if someone isn't doing any initramfs bundling, is there
> any impact ? No variables to change, etc ?
Would not impact, no need to change any variables.

>
> I'd suggest double checking meta-initramfs:
>
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/ 
>
>
OK, I will do that and let you know the results.

> And checking with Andrea to be sure that none of the existing use
> cases are broken.
>
OK, I will check with Andrea after I finished the tests with 
meta-initramfs layer.

//Ming Liu
> Bruce
>
>>
>> //Ming Liu
>>>
>>> Bruce
>>>
>>>> //Ming Liu
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Signed-off-by: Ming Liu <peter.x.liu at external.atlascopco.com>
>>>>>> ---
>>>>>>   meta/classes/kernel.bbclass | 4 ----
>>>>>>   1 file changed, 4 deletions(-)
>>>>>>
>>>>>> diff --git a/meta/classes/kernel.bbclass 
>>>>>> b/meta/classes/kernel.bbclass
>>>>>> index 4ce1611..d1ca614 100644
>>>>>> --- a/meta/classes/kernel.bbclass
>>>>>> +++ b/meta/classes/kernel.bbclass
>>>>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>>>>           kernel_do_compile
>>>>>>           mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>>>>           mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>>>>> -        # Update install area
>>>>>> -        echo "There is kernel image bundled with initramfs:
>>>>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>> -        install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>>>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>>>>> -        echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>>       fi
>>>>>>   }
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the Openembedded-core mailing list