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

[Bruce Ashfield]

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 ?

I'd suggest double checking meta-initramfs:

http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/

And checking with Andrea to be sure that none of the existing use
cases are broken.

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