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

2016-01-26 Thread Ming Liu



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 

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














--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-26 Thread Andrea Adami
On Tue, Jan 26, 2016 at 11:12 PM, Ming Liu  wrote:
>
>
> 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 
>>>
>>> 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 
>>> ---
>>>   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
>>>   }
>>>
>>>
>>
>

>>>
>>
>

Hi,

I could not yet test the proposed changes.
For a quick test please do build initramfs-kexecboot-klibc-image for qemu.
Thanks

Andrea

P.S. We did restore the old documentation about plain embedded
initramfs, pls have a look at the (outdated) msg:
https://github.com/kexecboot/kexecboot/wiki/oe-yocto
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-22 Thread 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 

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












--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-20 Thread Ming Liu



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 

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.


//Ming Liu


Bruce


//Ming Liu


Bruce



Signed-off-by: Ming Liu 
---
  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
  }










--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-19 Thread Ming Liu



On 01/19/2016 08:39 PM, Bruce Ashfield wrote:

On 16-01-05 08:12 AM, Ming Liu wrote:

From: Ming Liu 

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.




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.


//Ming Liu


Bruce



Signed-off-by: Ming Liu 
---
  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
  }






--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-19 Thread Bruce Ashfield

On 16-01-05 08:12 AM, Ming Liu wrote:

From: Ming Liu 

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 ?

I'm probably missing something, which just means we need to tweak
the commit log a bit more.

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.

Bruce



Signed-off-by: Ming Liu 
---
  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
  }




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-19 Thread Bruce Ashfield

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 

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 ?

Bruce


//Ming Liu


Bruce



Signed-off-by: Ming Liu 
---
  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
  }








--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-01-05 Thread Ming Liu
From: Ming Liu 

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.

Signed-off-by: Ming Liu 
---
 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
 }
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core