[OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
This change moves the initramfs bundling functions and tasks into a
separate class called 'kernel-initramfs'. The change also converts the
copy_initramfs into a task that itself depends on the do_image_complete
of the initramfs image. Making this change allows for the do_initramfs_*
tasks to be conditionally added instead of relying on the task checking
the variables, with the exception of do_deploy(_append).
The 'use_alternate_initrd' of kernel_do_compile is replaced with a
general use 'extra_make' variable. And the INITRAMFS_TASK functionality
of kernel_do_compile is removed.
The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
do_deploy in order to allow these classes to append to the do_deploy
task without breaking the do_deploy task itself.
The functionality for INITRAMFS_TASK remained for backwards
compatibility when the bundle changes were introduced. The bundle
functionality has been available for a number of releases since, as such
this change does not carry forward the functionality of INITRAMFS_TASK.
The information regarding INITRAMFS_TASK issues for is kept along with
the generation of a bb.fatal when a user attempts to use it.
Signed-off-by: Nathan Rossi
---
meta/classes/kernel-initramfs.bbclass | 114 +
meta/classes/kernel.bbclass | 155 +-
2 files changed, 133 insertions(+), 136 deletions(-)
create mode 100644 meta/classes/kernel-initramfs.bbclass
diff --git a/meta/classes/kernel-initramfs.bbclass
b/meta/classes/kernel-initramfs.bbclass
new file mode 100644
index 00..b23fb51495
--- /dev/null
+++ b/meta/classes/kernel-initramfs.bbclass
@@ -0,0 +1,114 @@
+
+INITRAMFS_IMAGE ?= ""
+INITRAMFS_IMAGE_NAME ?= "${@'${INITRAMFS_IMAGE}-${MACHINE}' if
d.getVar('INITRAMFS_IMAGE') else ''}"
+INITRAMFS_IMAGE_BUNDLE ?= ""
+
+python __anonymous () {
+# NOTE: setting INITRAMFS_TASK was for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+if d.getVar('INITRAMFS_TASK'):
+bb.fatal("The INITRAMFS_TASK variable is no longer supported. Use
INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE.")
+
+image = d.getVar("INITRAMFS_IMAGE")
+bundle = oe.types.boolean(d.getVar("INITRAMFS_IMAGE_BUNDLE") or "0")
+if image and bundle:
+# add all the tasks
+bb.build.addtask('do_initramfs_copy', 'do_initramfs_bundle',
'do_install', d)
+bb.build.addtask('do_initramfs_bundle', 'do_deploy',
'do_initramfs_copy', d)
+
+# make the do_initramfs_copy task depend on the image
do_image_complete task
+d.appendVarFlag('do_initramfs_copy', 'depends', '
${INITRAMFS_IMAGE}:do_image_complete')
+}
+
+do_initramfs_copy[dirs] = "${B}"
+do_initramfs_copy () {
+echo "Copying initramfs into ./usr ..."
+# In case the directory is not created yet from the first pass compile:
+mkdir -p ${B}/usr
+# Find and use the first initramfs image archive type we find
+rm -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
+for img in cpio cpio.gz cpio.lz4 cpio.lzo cpio.lzma cpio.xz; do
+if [ -e "${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img" ]; then
+cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img ${B}/usr/.
+case $img in
+*gz)
+echo "gzip decompressing image"
+gunzip -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
+break
+;;
+*lz4)
+echo "lz4 decompressing image"
+lz4 -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
+break
+;;
+*lzo)
+echo "lzo decompressing image"
+lzop -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
+break
+;;
+*lzma)
+echo "lzma decompressing image"
+lzma -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
+break
+;;
+*xz)
+echo "xz decompressing image"
+xz -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
+break
+;;
+esac
+fi
+done
+if [ ! -e ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio ]; then
+bbfatal "Failed to copy initramfs cpio for image
${INITRAMFS_IMAGE_NAME}"
+fi
+echo "Finished copy of initramfs into ./usr"
+}
+
+do_initramfs_bundle[dirs] = "${B}"
+do_initramfs_bundle () {
+echo "Creating a kernel image with a bundled initramfs..."
+# Backing up kernel image relies on its type(regular file or symbolic link)
+tmp_path=""
+for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
+if [ -h ${KERNEL_OUTPUT_DIR}/$imageType ] ; then
+linkpath=`readlink -n ${KERNEL_OUTPUT_DIR}/$imageType`
+realpath=`readlink -fn ${KERNEL_OUTPUT_DIR}/$imageType`
+
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
On Wed, Nov 7, 2018 at 1:16 PM Nathan Rossi wrote:
>
> This change moves the initramfs bundling functions and tasks into a
> separate class called 'kernel-initramfs'. The change also converts the
> copy_initramfs into a task that itself depends on the do_image_complete
> of the initramfs image. Making this change allows for the do_initramfs_*
> tasks to be conditionally added instead of relying on the task checking
> the variables, with the exception of do_deploy(_append).
>
> The 'use_alternate_initrd' of kernel_do_compile is replaced with a
> general use 'extra_make' variable. And the INITRAMFS_TASK functionality
> of kernel_do_compile is removed.
>
> The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
> do_deploy in order to allow these classes to append to the do_deploy
> task without breaking the do_deploy task itself.
>
> The functionality for INITRAMFS_TASK remained for backwards
> compatibility when the bundle changes were introduced. The bundle
> functionality has been available for a number of releases since, as such
> this change does not carry forward the functionality of INITRAMFS_TASK.
> The information regarding INITRAMFS_TASK issues for is kept along with
> the generation of a bb.fatal when a user attempts to use it.
>
> Signed-off-by: Nathan Rossi
Hi Nathan,
thanks for your efforts, clearly cleaning is needed wrt the bunling.
As for the results of this work, I fear it will break the existent (10
yrs) infrastructure.
A brief recap: we want to build a non-yocto kernel bundled with our
initramfs image, this in a single kernel recipe.
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
In the years I have adjusted the recipe which is today needing both
INITRAMFS_IMAGE = "initramfs-kexecboot-klibc-image"
INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete"
I will test your patch and include the new kernel-initramfs.bbclass.
The point is that I don't want/need the NITRAMFS_IMAGE_BUNDLE for th
emain kernel, just for thi ssecond kernel provided by the a.m. recipe.
I have to check again but this var has to be set upper in local.conf,
not in the recipe afaik.
Let me pls check this before (n)acking it...
Cheers
Andrea
> ---
> meta/classes/kernel-initramfs.bbclass | 114 +
> meta/classes/kernel.bbclass | 155
> +-
> 2 files changed, 133 insertions(+), 136 deletions(-)
> create mode 100644 meta/classes/kernel-initramfs.bbclass
>
> diff --git a/meta/classes/kernel-initramfs.bbclass
> b/meta/classes/kernel-initramfs.bbclass
> new file mode 100644
> index 00..b23fb51495
> --- /dev/null
> +++ b/meta/classes/kernel-initramfs.bbclass
> @@ -0,0 +1,114 @@
> +
> +INITRAMFS_IMAGE ?= ""
> +INITRAMFS_IMAGE_NAME ?= "${@'${INITRAMFS_IMAGE}-${MACHINE}' if
> d.getVar('INITRAMFS_IMAGE') else ''}"
> +INITRAMFS_IMAGE_BUNDLE ?= ""
> +
> +python __anonymous () {
> +# NOTE: setting INITRAMFS_TASK was for backward compatibility
> +# The preferred method is to set INITRAMFS_IMAGE, because
> +# this INITRAMFS_TASK has circular dependency problems
> +# if the initramfs requires kernel modules
> +if d.getVar('INITRAMFS_TASK'):
> +bb.fatal("The INITRAMFS_TASK variable is no longer supported. Use
> INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE.")
> +
> +image = d.getVar("INITRAMFS_IMAGE")
> +bundle = oe.types.boolean(d.getVar("INITRAMFS_IMAGE_BUNDLE") or "0")
> +if image and bundle:
> +# add all the tasks
> +bb.build.addtask('do_initramfs_copy', 'do_initramfs_bundle',
> 'do_install', d)
> +bb.build.addtask('do_initramfs_bundle', 'do_deploy',
> 'do_initramfs_copy', d)
> +
> +# make the do_initramfs_copy task depend on the image
> do_image_complete task
> +d.appendVarFlag('do_initramfs_copy', 'depends', '
> ${INITRAMFS_IMAGE}:do_image_complete')
> +}
> +
> +do_initramfs_copy[dirs] = "${B}"
> +do_initramfs_copy () {
> +echo "Copying initramfs into ./usr ..."
> +# In case the directory is not created yet from the first pass compile:
> +mkdir -p ${B}/usr
> +# Find and use the first initramfs image archive type we find
> +rm -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
> +for img in cpio cpio.gz cpio.lz4 cpio.lzo cpio.lzma cpio.xz; do
> +if [ -e "${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img" ]; then
> +cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img ${B}/usr/.
> +case $img in
> +*gz)
> +echo "gzip decompressing image"
> +gunzip -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
> +break
> +;;
> +*lz4)
> +echo "lz4 decompressing image"
> +lz4 -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
> +break
> +;;
> +*lzo)
> +echo "lzo decompressing image"
> +lzop -d
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
On Wed, 7 Nov 2018 at 23:21, Andrea Adami wrote:
>
> On Wed, Nov 7, 2018 at 1:16 PM Nathan Rossi wrote:
> >
> > This change moves the initramfs bundling functions and tasks into a
> > separate class called 'kernel-initramfs'. The change also converts the
> > copy_initramfs into a task that itself depends on the do_image_complete
> > of the initramfs image. Making this change allows for the do_initramfs_*
> > tasks to be conditionally added instead of relying on the task checking
> > the variables, with the exception of do_deploy(_append).
> >
> > The 'use_alternate_initrd' of kernel_do_compile is replaced with a
> > general use 'extra_make' variable. And the INITRAMFS_TASK functionality
> > of kernel_do_compile is removed.
> >
> > The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
> > do_deploy in order to allow these classes to append to the do_deploy
> > task without breaking the do_deploy task itself.
> >
> > The functionality for INITRAMFS_TASK remained for backwards
> > compatibility when the bundle changes were introduced. The bundle
> > functionality has been available for a number of releases since, as such
> > this change does not carry forward the functionality of INITRAMFS_TASK.
> > The information regarding INITRAMFS_TASK issues for is kept along with
> > the generation of a bb.fatal when a user attempts to use it.
> >
> > Signed-off-by: Nathan Rossi
>
> Hi Nathan,
>
> thanks for your efforts, clearly cleaning is needed wrt the bunling.
>
> As for the results of this work, I fear it will break the existent (10
> yrs) infrastructure.
> A brief recap: we want to build a non-yocto kernel bundled with our
> initramfs image, this in a single kernel recipe.
>
> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
>
> In the years I have adjusted the recipe which is today needing both
>
> INITRAMFS_IMAGE = "initramfs-kexecboot-klibc-image"
> INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete"
>
> I will test your patch and include the new kernel-initramfs.bbclass.
> The point is that I don't want/need the NITRAMFS_IMAGE_BUNDLE for th
> emain kernel, just for thi ssecond kernel provided by the a.m. recipe.
> I have to check again but this var has to be set upper in local.conf,
> not in the recipe afaik.
My understanding is that since image.bbclass no longer has any task
dependence on the initramfs bundling you should be able to mark
INITRAMFS_IMAGE_BUNDLE in your second kernel recipe and it will
achieve a similar result. I did test this with a single kernel recipe,
which resulted in correct kernel+image build and deploying. If you
have issues with it behaving as desired then I can look into and see
if it is possible to solve all bundling use cases with the one
implementation similar to this change.
The dependence on the kernel's bundling tasks was removed here:
http://git.openembedded.org/openembedded-core/commit/?id=eca501aeb4f2cc9255fabab14c68f6910367aaf9
Other than the task dependencies that were in image I could find no
evidence that INITRAMFS_IMAGE_BUNDLE was explicitly required in a
.conf apart from the comment in local.conf.extended
(http://git.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample.extended#n350).
Regards,
Nathan
>
> Let me pls check this before (n)acking it...
>
> Cheers
> Andrea
>
> > ---
> > meta/classes/kernel-initramfs.bbclass | 114 +
> > meta/classes/kernel.bbclass | 155
> > +-
> > 2 files changed, 133 insertions(+), 136 deletions(-)
> > create mode 100644 meta/classes/kernel-initramfs.bbclass
> >
> > diff --git a/meta/classes/kernel-initramfs.bbclass
> > b/meta/classes/kernel-initramfs.bbclass
> > new file mode 100644
> > index 00..b23fb51495
> > --- /dev/null
> > +++ b/meta/classes/kernel-initramfs.bbclass
> > @@ -0,0 +1,114 @@
> > +
> > +INITRAMFS_IMAGE ?= ""
> > +INITRAMFS_IMAGE_NAME ?= "${@'${INITRAMFS_IMAGE}-${MACHINE}' if
> > d.getVar('INITRAMFS_IMAGE') else ''}"
> > +INITRAMFS_IMAGE_BUNDLE ?= ""
> > +
> > +python __anonymous () {
> > +# NOTE: setting INITRAMFS_TASK was for backward compatibility
> > +# The preferred method is to set INITRAMFS_IMAGE, because
> > +# this INITRAMFS_TASK has circular dependency problems
> > +# if the initramfs requires kernel modules
> > +if d.getVar('INITRAMFS_TASK'):
> > +bb.fatal("The INITRAMFS_TASK variable is no longer supported. Use
> > INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE.")
> > +
> > +image = d.getVar("INITRAMFS_IMAGE")
> > +bundle = oe.types.boolean(d.getVar("INITRAMFS_IMAGE_BUNDLE") or "0")
> > +if image and bundle:
> > +# add all the tasks
> > +bb.build.addtask('do_initramfs_copy', 'do_initramfs_bundle',
> > 'do_install', d)
> > +bb.build.addtask('do_initramfs_bundle', 'do_deploy',
> > 'do_initramfs_copy', d)
> > +
> > +# make the do_initramfs_copy task depend on the i
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
On Thu, Nov 8, 2018 at 2:25 PM Nathan Rossi wrote:
>
> On Wed, 7 Nov 2018 at 23:21, Andrea Adami wrote:
> >
> > On Wed, Nov 7, 2018 at 1:16 PM Nathan Rossi wrote:
> > >
> > > This change moves the initramfs bundling functions and tasks into a
> > > separate class called 'kernel-initramfs'. The change also converts the
> > > copy_initramfs into a task that itself depends on the do_image_complete
> > > of the initramfs image. Making this change allows for the do_initramfs_*
> > > tasks to be conditionally added instead of relying on the task checking
> > > the variables, with the exception of do_deploy(_append).
> > >
> > > The 'use_alternate_initrd' of kernel_do_compile is replaced with a
> > > general use 'extra_make' variable. And the INITRAMFS_TASK functionality
> > > of kernel_do_compile is removed.
> > >
> > > The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
> > > do_deploy in order to allow these classes to append to the do_deploy
> > > task without breaking the do_deploy task itself.
> > >
> > > The functionality for INITRAMFS_TASK remained for backwards
> > > compatibility when the bundle changes were introduced. The bundle
> > > functionality has been available for a number of releases since, as such
> > > this change does not carry forward the functionality of INITRAMFS_TASK.
> > > The information regarding INITRAMFS_TASK issues for is kept along with
> > > the generation of a bb.fatal when a user attempts to use it.
> > >
> > > Signed-off-by: Nathan Rossi
> >
> > Hi Nathan,
> >
> > thanks for your efforts, clearly cleaning is needed wrt the bunling.
> >
> > As for the results of this work, I fear it will break the existent (10
> > yrs) infrastructure.
> > A brief recap: we want to build a non-yocto kernel bundled with our
> > initramfs image, this in a single kernel recipe.
> >
> > http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
> >
> > In the years I have adjusted the recipe which is today needing both
> >
> > INITRAMFS_IMAGE = "initramfs-kexecboot-klibc-image"
> > INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete"
> >
> > I will test your patch and include the new kernel-initramfs.bbclass.
> > The point is that I don't want/need the NITRAMFS_IMAGE_BUNDLE for th
> > emain kernel, just for thi ssecond kernel provided by the a.m. recipe.
> > I have to check again but this var has to be set upper in local.conf,
> > not in the recipe afaik.
>
> My understanding is that since image.bbclass no longer has any task
> dependence on the initramfs bundling you should be able to mark
> INITRAMFS_IMAGE_BUNDLE in your second kernel recipe and it will
> achieve a similar result. I did test this with a single kernel recipe,
> which resulted in correct kernel+image build and deploying. If you
> have issues with it behaving as desired then I can look into and see
> if it is possible to solve all bundling use cases with the one
> implementation similar to this change.
>
> The dependence on the kernel's bundling tasks was removed here:
> http://git.openembedded.org/openembedded-core/commit/?id=eca501aeb4f2cc9255fabab14c68f6910367aaf9
>
> Other than the task dependencies that were in image I could find no
> evidence that INITRAMFS_IMAGE_BUNDLE was explicitly required in a
> .conf apart from the comment in local.conf.extended
> (http://git.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample.extended#n350).
>
> Regards,
> Nathan
>
Hello,
so I applied both patches and had to comment out (as expected) the
INITRAMFS_TASK.
I have added INITRAMFS_IMAGE_BUNDLE in my 2nd kernel recipe but last
night build did fail: the initramfs.cpio.xz was not found.
I did only scrub the last lines... will debug later.
Cheers
Andrea
> >
> > Let me pls check this before (n)acking it...
> >
> > Cheers
> > Andrea
> >
> > > ---
> > > meta/classes/kernel-initramfs.bbclass | 114 +
> > > meta/classes/kernel.bbclass | 155
> > > +-
> > > 2 files changed, 133 insertions(+), 136 deletions(-)
> > > create mode 100644 meta/classes/kernel-initramfs.bbclass
> > >
> > > diff --git a/meta/classes/kernel-initramfs.bbclass
> > > b/meta/classes/kernel-initramfs.bbclass
> > > new file mode 100644
> > > index 00..b23fb51495
> > > --- /dev/null
> > > +++ b/meta/classes/kernel-initramfs.bbclass
> > > @@ -0,0 +1,114 @@
> > > +
> > > +INITRAMFS_IMAGE ?= ""
> > > +INITRAMFS_IMAGE_NAME ?= "${@'${INITRAMFS_IMAGE}-${MACHINE}' if
> > > d.getVar('INITRAMFS_IMAGE') else ''}"
> > > +INITRAMFS_IMAGE_BUNDLE ?= ""
> > > +
> > > +python __anonymous () {
> > > +# NOTE: setting INITRAMFS_TASK was for backward compatibility
> > > +# The preferred method is to set INITRAMFS_IMAGE, because
> > > +# this INITRAMFS_TASK has circular dependency problems
> > > +# if the initramfs requires kernel modules
> > > +if d.getVar('INITRAMFS_TASK'):
> > > +bb.fatal("The INITRAMFS
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
On Thu, Nov 8, 2018 at 3:25 PM Andrea Adami wrote:
>
> On Thu, Nov 8, 2018 at 2:25 PM Nathan Rossi wrote:
> >
> > On Wed, 7 Nov 2018 at 23:21, Andrea Adami wrote:
> > >
> > > On Wed, Nov 7, 2018 at 1:16 PM Nathan Rossi
> > > wrote:
> > > >
> > > > This change moves the initramfs bundling functions and tasks into a
> > > > separate class called 'kernel-initramfs'. The change also converts the
> > > > copy_initramfs into a task that itself depends on the do_image_complete
> > > > of the initramfs image. Making this change allows for the do_initramfs_*
> > > > tasks to be conditionally added instead of relying on the task checking
> > > > the variables, with the exception of do_deploy(_append).
> > > >
> > > > The 'use_alternate_initrd' of kernel_do_compile is replaced with a
> > > > general use 'extra_make' variable. And the INITRAMFS_TASK functionality
> > > > of kernel_do_compile is removed.
> > > >
> > > > The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
> > > > do_deploy in order to allow these classes to append to the do_deploy
> > > > task without breaking the do_deploy task itself.
> > > >
> > > > The functionality for INITRAMFS_TASK remained for backwards
> > > > compatibility when the bundle changes were introduced. The bundle
> > > > functionality has been available for a number of releases since, as such
> > > > this change does not carry forward the functionality of INITRAMFS_TASK.
> > > > The information regarding INITRAMFS_TASK issues for is kept along with
> > > > the generation of a bb.fatal when a user attempts to use it.
> > > >
> > > > Signed-off-by: Nathan Rossi
> > >
> > > Hi Nathan,
> > >
> > > thanks for your efforts, clearly cleaning is needed wrt the bunling.
> > >
> > > As for the results of this work, I fear it will break the existent (10
> > > yrs) infrastructure.
> > > A brief recap: we want to build a non-yocto kernel bundled with our
> > > initramfs image, this in a single kernel recipe.
> > >
> > > http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
> > >
> > > In the years I have adjusted the recipe which is today needing both
> > >
> > > INITRAMFS_IMAGE = "initramfs-kexecboot-klibc-image"
> > > INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete"
> > >
> > > I will test your patch and include the new kernel-initramfs.bbclass.
> > > The point is that I don't want/need the NITRAMFS_IMAGE_BUNDLE for th
> > > emain kernel, just for thi ssecond kernel provided by the a.m. recipe.
> > > I have to check again but this var has to be set upper in local.conf,
> > > not in the recipe afaik.
> >
> > My understanding is that since image.bbclass no longer has any task
> > dependence on the initramfs bundling you should be able to mark
> > INITRAMFS_IMAGE_BUNDLE in your second kernel recipe and it will
> > achieve a similar result. I did test this with a single kernel recipe,
> > which resulted in correct kernel+image build and deploying. If you
> > have issues with it behaving as desired then I can look into and see
> > if it is possible to solve all bundling use cases with the one
> > implementation similar to this change.
> >
> > The dependence on the kernel's bundling tasks was removed here:
> > http://git.openembedded.org/openembedded-core/commit/?id=eca501aeb4f2cc9255fabab14c68f6910367aaf9
> >
> > Other than the task dependencies that were in image I could find no
> > evidence that INITRAMFS_IMAGE_BUNDLE was explicitly required in a
> > .conf apart from the comment in local.conf.extended
> > (http://git.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample.extended#n350).
> >
> > Regards,
> > Nathan
> >
>
> Hello,
>
> so I applied both patches and had to comment out (as expected) the
> INITRAMFS_TASK.
> I have added INITRAMFS_IMAGE_BUNDLE in my 2nd kernel recipe but last
> night build did fail: the initramfs.cpio.xz was not found.
>
> I did only scrub the last lines... will debug later.
>
Ok, so the problem is copy_initramfs() is done too late and do_compile fails
|
/tmp/build/tmp-musl/work-shared/spitz/kernel-source/scripts/gen_initramfs_list.sh:
Cannot open 'initramfs.cpio.xz'
| /tmp/build/tmp-musl/work-shared/spitz/kernel-source/usr/Makefile:73:
recipe for target 'usr/initramfs_data.cpio.xz' failed
do_compile log before
1 DEBUG: Executing shell function do_compile
2 Copying initramfs into ./usr ...
3 gzip decompressing image
4 Finished copy of initramfs into ./usr
5 NOTE: make -j ...
do_compile with patch applied (build fails):
1 DEBUG: Executing shell function do_compile
2 NOTE: make -j ...
Please check again the task order. Thanks.
Cheers
Andrea
>
> > >
> > > Let me pls check this before (n)acking it...
> > >
> > > Cheers
> > > Andrea
> > >
> > > > ---
> > > > meta/classes/kernel-initramfs.bbclass | 114 +
> > > > meta/classes/kernel.bbclass | 155
> > > > +-
> > > > 2 files changed, 133 insertions(+), 136 deletions(-)
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
On Fri, 9 Nov 2018 at 08:55, Andrea Adami wrote:
>
> On Thu, Nov 8, 2018 at 3:25 PM Andrea Adami wrote:
> >
> > On Thu, Nov 8, 2018 at 2:25 PM Nathan Rossi wrote:
> > >
> > > On Wed, 7 Nov 2018 at 23:21, Andrea Adami wrote:
> > > >
> > > > On Wed, Nov 7, 2018 at 1:16 PM Nathan Rossi
> > > > wrote:
> > > > >
> > > > > This change moves the initramfs bundling functions and tasks into a
> > > > > separate class called 'kernel-initramfs'. The change also converts the
> > > > > copy_initramfs into a task that itself depends on the
> > > > > do_image_complete
> > > > > of the initramfs image. Making this change allows for the
> > > > > do_initramfs_*
> > > > > tasks to be conditionally added instead of relying on the task
> > > > > checking
> > > > > the variables, with the exception of do_deploy(_append).
> > > > >
> > > > > The 'use_alternate_initrd' of kernel_do_compile is replaced with a
> > > > > general use 'extra_make' variable. And the INITRAMFS_TASK
> > > > > functionality
> > > > > of kernel_do_compile is removed.
> > > > >
> > > > > The 'KERNEL_CLASSES' inherit is moved to after the EXPORT_FUNCTIONS
> > > > > do_deploy in order to allow these classes to append to the do_deploy
> > > > > task without breaking the do_deploy task itself.
> > > > >
> > > > > The functionality for INITRAMFS_TASK remained for backwards
> > > > > compatibility when the bundle changes were introduced. The bundle
> > > > > functionality has been available for a number of releases since, as
> > > > > such
> > > > > this change does not carry forward the functionality of
> > > > > INITRAMFS_TASK.
> > > > > The information regarding INITRAMFS_TASK issues for is kept along with
> > > > > the generation of a bb.fatal when a user attempts to use it.
> > > > >
> > > > > Signed-off-by: Nathan Rossi
> > > >
> > > > Hi Nathan,
> > > >
> > > > thanks for your efforts, clearly cleaning is needed wrt the bunling.
> > > >
> > > > As for the results of this work, I fear it will break the existent (10
> > > > yrs) infrastructure.
> > > > A brief recap: we want to build a non-yocto kernel bundled with our
> > > > initramfs image, this in a single kernel recipe.
> > > >
> > > > http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-kexecboot_4.4.bb
> > > >
> > > > In the years I have adjusted the recipe which is today needing both
> > > >
> > > > INITRAMFS_IMAGE = "initramfs-kexecboot-klibc-image"
> > > > INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete"
> > > >
> > > > I will test your patch and include the new kernel-initramfs.bbclass.
> > > > The point is that I don't want/need the NITRAMFS_IMAGE_BUNDLE for th
> > > > emain kernel, just for thi ssecond kernel provided by the a.m. recipe.
> > > > I have to check again but this var has to be set upper in local.conf,
> > > > not in the recipe afaik.
> > >
> > > My understanding is that since image.bbclass no longer has any task
> > > dependence on the initramfs bundling you should be able to mark
> > > INITRAMFS_IMAGE_BUNDLE in your second kernel recipe and it will
> > > achieve a similar result. I did test this with a single kernel recipe,
> > > which resulted in correct kernel+image build and deploying. If you
> > > have issues with it behaving as desired then I can look into and see
> > > if it is possible to solve all bundling use cases with the one
> > > implementation similar to this change.
> > >
> > > The dependence on the kernel's bundling tasks was removed here:
> > > http://git.openembedded.org/openembedded-core/commit/?id=eca501aeb4f2cc9255fabab14c68f6910367aaf9
> > >
> > > Other than the task dependencies that were in image I could find no
> > > evidence that INITRAMFS_IMAGE_BUNDLE was explicitly required in a
> > > .conf apart from the comment in local.conf.extended
> > > (http://git.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample.extended#n350).
> > >
> > > Regards,
> > > Nathan
> > >
> >
> > Hello,
> >
> > so I applied both patches and had to comment out (as expected) the
> > INITRAMFS_TASK.
> > I have added INITRAMFS_IMAGE_BUNDLE in my 2nd kernel recipe but last
> > night build did fail: the initramfs.cpio.xz was not found.
> >
> > I did only scrub the last lines... will debug later.
> >
>
> Ok, so the problem is copy_initramfs() is done too late and do_compile fails
>
> |
> /tmp/build/tmp-musl/work-shared/spitz/kernel-source/scripts/gen_initramfs_list.sh:
> Cannot open 'initramfs.cpio.xz'
> | /tmp/build/tmp-musl/work-shared/spitz/kernel-source/usr/Makefile:73:
> recipe for target 'usr/initramfs_data.cpio.xz' failed
>
>
> do_compile log before
>
> 1 DEBUG: Executing shell function do_compile
> 2 Copying initramfs into ./usr ...
> 3 gzip decompressing image
> 4 Finished copy of initramfs into ./usr
> 5 NOTE: make -j ...
>
> do_compile with patch applied (build fails):
>
> 1 DEBUG: Executing shell function do_compile
> 2 NOTE: make -j ...
>
> Please check again the task order. Thanks.
So the task order is copied from
Re: [OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup
> > > Hello, > > > > > > so I applied both patches and had to comment out (as expected) the > > > INITRAMFS_TASK. > > > I have added INITRAMFS_IMAGE_BUNDLE in my 2nd kernel recipe but last > > > night build did fail: the initramfs.cpio.xz was not found. > > > > > > I did only scrub the last lines... will debug later. > > > > > > > Ok, so the problem is copy_initramfs() is done too late and do_compile fails > > > > | > > /tmp/build/tmp-musl/work-shared/spitz/kernel-source/scripts/gen_initramfs_list.sh: > > Cannot open 'initramfs.cpio.xz' > > | /tmp/build/tmp-musl/work-shared/spitz/kernel-source/usr/Makefile:73: > > recipe for target 'usr/initramfs_data.cpio.xz' failed > > > > > > do_compile log before > > > > 1 DEBUG: Executing shell function do_compile > > 2 Copying initramfs into ./usr ... > > 3 gzip decompressing image > > 4 Finished copy of initramfs into ./usr > > 5 NOTE: make -j ... > > > > do_compile with patch applied (build fails): > > > > 1 DEBUG: Executing shell function do_compile > > 2 NOTE: make -j ... > > > > Please check again the task order. Thanks. > > So the task order is copied from the previous bundle setup (and needs > to work that way in order to prevent recursive dependency between > kernel do_install -> image -> initramfs_copy). When I mentioned that > this should behave similar to your existing setup I did mean there > were some differences. Specifically you would no longer need to > CONFIG_INITRAMFS_SOURCE in your kernel config. But in order to get the > initramfs kernel you would need to get the image generated from the > bundle. This is deployed separately to the base image type binary > ( vs -initramfs-.bin). I suspect this > might be problematic for you to change to? And as such would make it a > pain to switch away from INITRAMFS_TASK. > > Just looking at the task setup again, it might be relatively straight > forward to keep the INITRAMFS_TASK setup. Where the initramfs_copy > task is simply set as a dep for the do_compile in only that case (but > would break the use of BUNDLE in the same kernel). Would you prefer to > try and keep the INITRAMFS_TASK behaviour working? > > Thanks, > Nathan Nathan, if possible I would prefer to adapt our legacy implementation but I think the whole bundling as intended cannot be done for the 2nd kernel. What we want to keep is the possibility to build a 2nd initramfs-filled kernel living in its recipe without touching local.conf. Thus I'd say for the moment please keep the old INITRAMFS_TASK hook. Thanks Andrea -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
