Patchwork image_types: Ensure /init exists for cpio rootfs archives

login
mail settings
Submitter Darren Hart
Date Dec. 28, 2011, 11:54 p.m.
Message ID <4EFBAC18.3040909@intel.com>
Download mbox | patch
Permalink /patch/17755/
State Accepted
Commit 849b9aadae41d9b6777787213556bc538858b49a
Headers show

Comments

Darren Hart - Dec. 28, 2011, 11:54 p.m.
<I sent this to the yocto list by mistake, forwarding here for comment>

In order for the kernel to accept an initramfs as a rootfs,
it must have /init - even if it is an empty file. Touch /init
to ensure it exists for cpio and cpio.gz image types.

When used with initrd and rootfs=/dev/ram0, this allows the
cpio and cpio.gz images to be used as the rootfs.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
 meta/classes/image_types.bbclass |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)
Chris Larson - Dec. 29, 2011, 5:39 p.m.
On Wed, Dec 28, 2011 at 4:54 PM, Darren Hart <darren.hart@intel.com> wrote:
> <I sent this to the yocto list by mistake, forwarding here for comment>

Seems sane to me.
Andrea Adami - Dec. 30, 2011, 8:25 a.m.
On Thu, Dec 29, 2011 at 12:54 AM, Darren Hart <darren.hart@intel.com> wrote:
> <I sent this to the yocto list by mistake, forwarding here for comment>
>
> In order for the kernel to accept an initramfs as a rootfs,
> it must have /init - even if it is an empty file. Touch /init
> to ensure it exists for cpio and cpio.gz image types.

Why didn't you add the init to cpio.xz and cpio.lzma?
Any special reason?

>
> When used with initrd and rootfs=/dev/ram0, this allows the
> cpio and cpio.gz images to be used as the rootfs.

Sure, and "...If all else fails, rdinit=/bin/sh "

>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> ---
>  meta/classes/image_types.bbclass |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 6893e38..ebff0ba 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>  IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>  IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>  IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS} && tar --xz -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
> +IMAGE_CMD_cpio () {
> +       touch ${IMAGE_ROOTFS}/init
> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
> +}
> +IMAGE_CMD_cpio.gz () {
> +       touch ${IMAGE_ROOTFS}/init
> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
> +}
>  IMAGE_CMD_cpio.xz = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>  IMAGE_CMD_cpio.lzma = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
>
> --
> 1.7.6.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Regards

Andrea Adami
Darren Hart - Dec. 30, 2011, 11:18 p.m.
On 12/30/2011 12:25 AM, Andrea Adami wrote:
> On Thu, Dec 29, 2011 at 12:54 AM, Darren Hart <darren.hart@intel.com> wrote:
>> <I sent this to the yocto list by mistake, forwarding here for comment>
>>
>> In order for the kernel to accept an initramfs as a rootfs,
>> it must have /init - even if it is an empty file. Touch /init
>> to ensure it exists for cpio and cpio.gz image types.
> 
> Why didn't you add the init to cpio.xz and cpio.lzma?
> Any special reason?

No reason, just missed them I guess. I can resent with them included if
we agree this is a reasonable approach.

--
Darren

> 
>>
>> When used with initrd and rootfs=/dev/ram0, this allows the
>> cpio and cpio.gz images to be used as the rootfs.
> 
> Sure, and "...If all else fails, rdinit=/bin/sh "
> 
>>
>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>> ---
>>  meta/classes/image_types.bbclass |   10 ++++++++--
>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
>> index 6893e38..ebff0ba 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>>  IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>>  IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>>  IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS} && tar --xz -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
>> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
>> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
>> +IMAGE_CMD_cpio () {
>> +       touch ${IMAGE_ROOTFS}/init
>> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
>> +}
>> +IMAGE_CMD_cpio.gz () {
>> +       touch ${IMAGE_ROOTFS}/init
>> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
>> +}
>>  IMAGE_CMD_cpio.xz = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>>  IMAGE_CMD_cpio.lzma = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
>>
>> --
>> 1.7.6.4
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> Regards
> 
> Andrea Adami
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Andrea Adami - Jan. 3, 2012, 2:57 p.m.
On Sat, Dec 31, 2011 at 12:18 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 12/30/2011 12:25 AM, Andrea Adami wrote:
>> On Thu, Dec 29, 2011 at 12:54 AM, Darren Hart <darren.hart@intel.com> wrote:
>>> <I sent this to the yocto list by mistake, forwarding here for comment>
>>>
>>> In order for the kernel to accept an initramfs as a rootfs,
>>> it must have /init - even if it is an empty file. Touch /init
>>> to ensure it exists for cpio and cpio.gz image types.
>>
>> Why didn't you add the init to cpio.xz and cpio.lzma?
>> Any special reason?
>
> No reason, just missed them I guess. I can resent with them included if
> we agree this is a reasonable approach.

Darren,

I'm not sure this is the best approach.
Thinking about *bootables* cpio, I can imagine two types:

- barebone, whithout shell, libc,  no init
- generic: with shell and some utils

The first case is usually a custom-purpose rootfs (think about
kexecboot cpio's) and the recipe takes care of creating the init
symlink

e.g.

pkg_postinst_${PN} () {
        ln -sf ${bindir}/kexecboot $D/init
}

The second case, with bigger images, implies we are populating the
rootfs with glibc, eglibc, uclibc or klibc:  I'd say it's up to those
recipes to provide a valid init.

FWIW we can imagine to pile up multiple initramfs and surely we have
to specify the init only for the first, the one in the in-kernel
embedded initramfs.

Just my thoughts

Regards

Andrea


>
> --
> Darren
>
>>
>>>
>>> When used with initrd and rootfs=/dev/ram0, this allows the
>>> cpio and cpio.gz images to be used as the rootfs.
>>
>> Sure, and "...If all else fails, rdinit=/bin/sh "
>>
>>>
>>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>>> ---
>>>  meta/classes/image_types.bbclass |   10 ++++++++--
>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
>>> index 6893e38..ebff0ba 100644
>>> --- a/meta/classes/image_types.bbclass
>>> +++ b/meta/classes/image_types.bbclass
>>> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>>>  IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>>>  IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>>>  IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS} && tar --xz -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
>>> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
>>> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
>>> +IMAGE_CMD_cpio () {
>>> +       touch ${IMAGE_ROOTFS}/init
>>> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
>>> +}
>>> +IMAGE_CMD_cpio.gz () {
>>> +       touch ${IMAGE_ROOTFS}/init
>>> +       cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
>>> +}
>>>  IMAGE_CMD_cpio.xz = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>>>  IMAGE_CMD_cpio.lzma = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
>>>
>>> --
>>> 1.7.6.4
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>> Regards
>>
>> Andrea Adami
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
Saul Wold - Jan. 4, 2012, 12:07 a.m.
On 12/28/2011 03:54 PM, Darren Hart wrote:
> <I sent this to the yocto list by mistake, forwarding here for comment>
>
> In order for the kernel to accept an initramfs as a rootfs,
> it must have /init - even if it is an empty file. Touch /init
> to ensure it exists for cpio and cpio.gz image types.
>
> When used with initrd and rootfs=/dev/ram0, this allows the
> cpio and cpio.gz images to be used as the rootfs.
>
> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> ---
>   meta/classes/image_types.bbclass |   10 ++++++++--
>   1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 6893e38..ebff0ba 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS}&&  tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>   IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS}&&  tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>   IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS}&&  tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>   IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS}&&  tar --xz -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | gzip -c -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
> +IMAGE_CMD_cpio () {
> +	touch ${IMAGE_ROOTFS}/init
> +	cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
> +}
> +IMAGE_CMD_cpio.gz () {
> +	touch ${IMAGE_ROOTFS}/init
> +	cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | gzip -c -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
> +}
>   IMAGE_CMD_cpio.xz = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK}>  ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>   IMAGE_CMD_cpio.lzma = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK}>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
>

This merged as is to OE-Core.

Based on other emails, I will expect some update patch to address 
Andrea's comments.

Thanks
	Sau!
Andrea Adami - Jan. 4, 2012, 11:49 p.m.
On Wed, Jan 4, 2012 at 1:07 AM, Saul Wold <sgw@linux.intel.com> wrote:
> On 12/28/2011 03:54 PM, Darren Hart wrote:
>>
>> <I sent this to the yocto list by mistake, forwarding here for comment>
>>
>> In order for the kernel to accept an initramfs as a rootfs,
>> it must have /init - even if it is an empty file. Touch /init
>> to ensure it exists for cpio and cpio.gz image types.
>>
>> When used with initrd and rootfs=/dev/ram0, this allows the
>> cpio and cpio.gz images to be used as the rootfs.
>>
>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>> ---
>>  meta/classes/image_types.bbclass |   10 ++++++++--
>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 6893e38..ebff0ba 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS}&&  tar -cvf
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>>  IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS}&&  tar -zcvf
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>>  IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS}&&  tar -jcvf
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>>  IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS}&&  tar --xz -cvf
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
>> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H
>> newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
>> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc |
>> gzip -c -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
>> +IMAGE_CMD_cpio () {
>> +       touch ${IMAGE_ROOTFS}/init
>> +       cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H
>> newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
>> +}
>> +IMAGE_CMD_cpio.gz () {
>> +       touch ${IMAGE_ROOTFS}/init
>> +       cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | gzip -c
>> -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
>> +}
>>  IMAGE_CMD_cpio.xz = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . |
>> cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL}
>> --check=${XZ_INTEGRITY_CHECK}>
>>  ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>>  IMAGE_CMD_cpio.lzma = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find .
>> | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL}
>> --check=${XZ_INTEGRITY_CHECK}>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma)
>> ${EXTRA_IMAGECMD}"
>>
>
> This merged as is to OE-Core.
>
> Based on other emails, I will expect some update patch to address Andrea's
> comments.
>
> Thanks
>        Sau!
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

hm.. something is going wrong... permission denied


touch: cannot touch
`/oe/oe-core/build/tmp-eglibc/work/poodle-oe-linux-gnueabi/initramfs-kexecboot-klibc-image-1.0-r0/rootfs/init':
Permission denied

Andrea
Andrea Adami - Jan. 5, 2012, 12:05 a.m.
On Thu, Jan 5, 2012 at 12:49 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Wed, Jan 4, 2012 at 1:07 AM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 12/28/2011 03:54 PM, Darren Hart wrote:
>>>
>>> <I sent this to the yocto list by mistake, forwarding here for comment>
>>>
>>> In order for the kernel to accept an initramfs as a rootfs,
>>> it must have /init - even if it is an empty file. Touch /init
>>> to ensure it exists for cpio and cpio.gz image types.
>>>
>>> When used with initrd and rootfs=/dev/ram0, this allows the
>>> cpio and cpio.gz images to be used as the rootfs.
>>>
>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>>> ---
>>>  meta/classes/image_types.bbclass |   10 ++++++++--
>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/classes/image_types.bbclass
>>> b/meta/classes/image_types.bbclass
>>> index 6893e38..ebff0ba 100644
>>> --- a/meta/classes/image_types.bbclass
>>> +++ b/meta/classes/image_types.bbclass
>>> @@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS}&&  tar -cvf
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
>>>  IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS}&&  tar -zcvf
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
>>>  IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS}&&  tar -jcvf
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
>>>  IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS}&&  tar --xz -cvf
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
>>> -IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H
>>> newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
>>> -IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc |
>>> gzip -c -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
>>> +IMAGE_CMD_cpio () {
>>> +       touch ${IMAGE_ROOTFS}/init
>>> +       cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H
>>> newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
>>> +}
>>> +IMAGE_CMD_cpio.gz () {
>>> +       touch ${IMAGE_ROOTFS}/init
>>> +       cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | gzip -c
>>> -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
>>> +}
>>>  IMAGE_CMD_cpio.xz = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . |
>>> cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL}
>>> --check=${XZ_INTEGRITY_CHECK}>
>>>  ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
>>>  IMAGE_CMD_cpio.lzma = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find .
>>> | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL}
>>> --check=${XZ_INTEGRITY_CHECK}>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma)
>>> ${EXTRA_IMAGECMD}"
>>>
>>
>> This merged as is to OE-Core.
>>
>> Based on other emails, I will expect some update patch to address Andrea's
>> comments.
>>
>> Thanks
>>        Sau!
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> hm.. something is going wrong... permission denied
>
>
> touch: cannot touch
> `/oe/oe-core/build/tmp-eglibc/work/poodle-oe-linux-gnueabi/initramfs-kexecboot-klibc-image-1.0-r0/rootfs/init':
> Permission denied
>
> Andrea

I'd say we have to test for the in-existence of the file instead of
blindly touching it.
Smthg like

if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fi


Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?


Regards

Andrea
Richard Purdie - Jan. 5, 2012, 12:30 p.m.
On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
> I'd say we have to test for the in-existence of the file instead of
> blindly touching it.
> Smthg like
> 
> if [! -e ${IMAGE_ROOTFS}/init]; then
> touch ${IMAGE_ROOTFS}/init
> fi
> 
> 
> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?

Make it a shell function we call? I'd also check for
${base_sbindir}/init first too?

Cheers,

Richard
Darren Hart - Jan. 5, 2012, 11:36 p.m.
On 01/05/2012 04:30 AM, Richard Purdie wrote:
> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>> I'd say we have to test for the in-existence of the file instead of
>> blindly touching it.
>> Smthg like
>>
>> if [! -e ${IMAGE_ROOTFS}/init]; then
>> touch ${IMAGE_ROOTFS}/init
>> fi

Why? Touch creates it if it doesn't exist and updates the modtime if it
does. It doesn't modify the content of the file if it exists. What is
the motivation for testing for it's existence?

>>
>>
>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
> 
> Make it a shell function we call? I'd also check for
> ${base_sbindir}/init first too?

Why check for that? So we can link to it instead of creating an empty file?


--
Darren

> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Andrea Adami - Jan. 6, 2012, 1 a.m.
On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 01/05/2012 04:30 AM, Richard Purdie wrote:
>> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>>> I'd say we have to test for the in-existence of the file instead of
>>> blindly touching it.
>>> Smthg like
>>>
>>> if [! -e ${IMAGE_ROOTFS}/init]; then
>>> touch ${IMAGE_ROOTFS}/init
>>> fi
>
> Why? Touch creates it if it doesn't exist and updates the modtime if it
> does. It doesn't modify the content of the file if it exists. What is
> the motivation for testing for it's existence?
>
touch fails with Permission denied because one package in my rootfs
already created the symlink

>>>
>>>
>>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
>>
>> Make it a shell function we call? I'd also check for
>> ${base_sbindir}/init first too?
>
> Why check for that? So we can link to it instead of creating an empty file?

Nonsense, kernel looks for /init
( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
)

>
>
> --
> Darren
>
>>
>> Cheers,
>>
>> Richard
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Regards

Andrea
Andrea Adami - Jan. 6, 2012, 1:10 a.m.
On Fri, Jan 6, 2012 at 2:00 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>
>>
>> On 01/05/2012 04:30 AM, Richard Purdie wrote:
>>> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>>>> I'd say we have to test for the in-existence of the file instead of
>>>> blindly touching it.
>>>> Smthg like
>>>>
>>>> if [! -e ${IMAGE_ROOTFS}/init]; then
>>>> touch ${IMAGE_ROOTFS}/init
>>>> fi
>>
>> Why? Touch creates it if it doesn't exist and updates the modtime if it
>> does. It doesn't modify the content of the file if it exists. What is
>> the motivation for testing for it's existence?
>>
> touch fails with Permission denied because one package in my rootfs
> already created the symlink
>
Now I'm building from scratch and can't tell you which permission have
the binary and the symlink in my rootfs.

>>>>
>>>>
>>>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
>>>
>>> Make it a shell function we call? I'd also check for
>>> ${base_sbindir}/init first too?
>>
>> Why check for that? So we can link to it instead of creating an empty file?
>
> Nonsense, kernel looks for /init
> ( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> )
>

Sorry if it wasn't clear , it was meant for RP comment about base_sbindir

>> Why check for that? So we can link to it instead of creating an empty file?
I think is best to let the recipe populate the initramfs as they want
and create themselves the symlink.

There are just many scenarios..

Cheers

Andrea

>>
>>
>> --
>> Darren
>>
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Linux Kernel
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> Regards
>
> Andrea
Richard Purdie - Jan. 6, 2012, 10:57 a.m.
On Fri, 2012-01-06 at 02:00 +0100, Andrea Adami wrote:
> On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >
> >
> > On 01/05/2012 04:30 AM, Richard Purdie wrote:
> >> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
> >>> I'd say we have to test for the in-existence of the file instead of
> >>> blindly touching it.
> >>> Smthg like
> >>>
> >>> if [! -e ${IMAGE_ROOTFS}/init]; then
> >>> touch ${IMAGE_ROOTFS}/init
> >>> fi
> >
> > Why? Touch creates it if it doesn't exist and updates the modtime if it
> > does. It doesn't modify the content of the file if it exists. What is
> > the motivation for testing for it's existence?
> >
> touch fails with Permission denied because one package in my rootfs
> already created the symlink
> 
> >>>
> >>>
> >>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
> >>
> >> Make it a shell function we call? I'd also check for
> >> ${base_sbindir}/init first too?
> >
> > Why check for that? So we can link to it instead of creating an empty file?
> 
> Nonsense, kernel looks for /init
> ( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> )

Yes, please ignore my comment about /sbin/init, I'm misremembering
something. We should deal with the symlink case though.

Cheers,

Richard
Andrea Adami - Jan. 6, 2012, 10:58 p.m.
On Fri, Jan 6, 2012 at 11:57 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2012-01-06 at 02:00 +0100, Andrea Adami wrote:
>> On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>> >
>> >
>> > On 01/05/2012 04:30 AM, Richard Purdie wrote:
>> >> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>> >>> I'd say we have to test for the in-existence of the file instead of
>> >>> blindly touching it.
>> >>> Smthg like
>> >>>
>> >>> if [! -e ${IMAGE_ROOTFS}/init]; then
>> >>> touch ${IMAGE_ROOTFS}/init
>> >>> fi
>> >
>> > Why? Touch creates it if it doesn't exist and updates the modtime if it
>> > does. It doesn't modify the content of the file if it exists. What is
>> > the motivation for testing for it's existence?
>> >
>> touch fails with Permission denied because one package in my rootfs
>> already created the symlink
>>
>> >>>
>> >>>
>> >>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
>> >>
>> >> Make it a shell function we call? I'd also check for
>> >> ${base_sbindir}/init first too?
>> >
>> > Why check for that? So we can link to it instead of creating an empty file?
>>
>> Nonsense, kernel looks for /init
>> ( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
>> )
>
> Yes, please ignore my comment about /sbin/init, I'm misremembering
> something. We should deal with the symlink case though.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

ok, I think the issue is the behavior of touch when trying to change
the timestamp of a symlink.

http://fossplanet.com/f13/bug-7122-touch-gnu-coreutils-7-4-no-way-touch-symlink-57418/

Using 'touch -h' seems solving the issue and the image is built.
However, the timestamp of the /init symlink now differs from the
timestamp of the binary.

Regards

Andrea
Andrea Adami - Jan. 10, 2012, 11:07 p.m.
On Fri, Jan 6, 2012 at 11:58 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Fri, Jan 6, 2012 at 11:57 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Fri, 2012-01-06 at 02:00 +0100, Andrea Adami wrote:
>>> On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> >
>>> >
>>> > On 01/05/2012 04:30 AM, Richard Purdie wrote:
>>> >> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>>> >>> I'd say we have to test for the in-existence of the file instead of
>>> >>> blindly touching it.
>>> >>> Smthg like
>>> >>>
>>> >>> if [! -e ${IMAGE_ROOTFS}/init]; then
>>> >>> touch ${IMAGE_ROOTFS}/init
>>> >>> fi
>>> >
>>> > Why? Touch creates it if it doesn't exist and updates the modtime if it
>>> > does. It doesn't modify the content of the file if it exists. What is
>>> > the motivation for testing for it's existence?
>>> >
>>> touch fails with Permission denied because one package in my rootfs
>>> already created the symlink
>>>
>>> >>>
>>> >>>
>>> >>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
>>> >>
>>> >> Make it a shell function we call? I'd also check for
>>> >> ${base_sbindir}/init first too?
>>> >
>>> > Why check for that? So we can link to it instead of creating an empty file?
>>>
>>> Nonsense, kernel looks for /init
>>> ( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
>>> )
>>
>> Yes, please ignore my comment about /sbin/init, I'm misremembering
>> something. We should deal with the symlink case though.
>>
>> Cheers,
>>
>> Richard
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> ok, I think the issue is the behavior of touch when trying to change
> the timestamp of a symlink.
>
> http://fossplanet.com/f13/bug-7122-touch-gnu-coreutils-7-4-no-way-touch-symlink-57418/
>
> Using 'touch -h' seems solving the issue and the image is built.
> However, the timestamp of the /init symlink now differs from the
> timestamp of the binary.
>
> Regards
>
> Andrea


Ok, now I think I understand the issue:

the /init symlink in rootfs is absolute, being its path is pointing to
/usr/bin/kexecboot in our case.
Now, until this becomes the real rootfs, the symlink appears broken
and that's why adding the -h (do not dereference) fixes the case of
existent symlink.

Unfortunately it appears touch -h fails if /init is a file and not a
symlink (tested now).

Afterall, I think it would be easier to add a guard around touch as
initially proposed.

Just my 2 cents

Andrea
Andrea Adami - Jan. 10, 2012, 11:28 p.m.
On Wed, Jan 11, 2012 at 12:07 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Fri, Jan 6, 2012 at 11:58 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> On Fri, Jan 6, 2012 at 11:57 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Fri, 2012-01-06 at 02:00 +0100, Andrea Adami wrote:
>>>> On Fri, Jan 6, 2012 at 12:36 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>>> >
>>>> >
>>>> > On 01/05/2012 04:30 AM, Richard Purdie wrote:
>>>> >> On Thu, 2012-01-05 at 01:05 +0100, Andrea Adami wrote:
>>>> >>> I'd say we have to test for the in-existence of the file instead of
>>>> >>> blindly touching it.
>>>> >>> Smthg like
>>>> >>>
>>>> >>> if [! -e ${IMAGE_ROOTFS}/init]; then
>>>> >>> touch ${IMAGE_ROOTFS}/init
>>>> >>> fi
>>>> >
>>>> > Why? Touch creates it if it doesn't exist and updates the modtime if it
>>>> > does. It doesn't modify the content of the file if it exists. What is
>>>> > the motivation for testing for it's existence?
>>>> >
>>>> touch fails with Permission denied because one package in my rootfs
>>>> already created the symlink
>>>>
>>>> >>>
>>>> >>>
>>>> >>> Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
>>>> >>
>>>> >> Make it a shell function we call? I'd also check for
>>>> >> ${base_sbindir}/init first too?
>>>> >
>>>> > Why check for that? So we can link to it instead of creating an empty file?
>>>>
>>>> Nonsense, kernel looks for /init
>>>> ( http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
>>>> )
>>>
>>> Yes, please ignore my comment about /sbin/init, I'm misremembering
>>> something. We should deal with the symlink case though.
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>> ok, I think the issue is the behavior of touch when trying to change
>> the timestamp of a symlink.
>>
>> http://fossplanet.com/f13/bug-7122-touch-gnu-coreutils-7-4-no-way-touch-symlink-57418/
>>
>> Using 'touch -h' seems solving the issue and the image is built.
>> However, the timestamp of the /init symlink now differs from the
>> timestamp of the binary.
>>
>> Regards
>>
>> Andrea
>
>
> Ok, now I think I understand the issue:
>
> the /init symlink in rootfs is absolute, being its path is pointing to
> /usr/bin/kexecboot in our case.
> Now, until this becomes the real rootfs, the symlink appears broken
> and that's why adding the -h (do not dereference) fixes the case of
> existent symlink.
>
> Unfortunately it appears touch -h fails if /init is a file and not a
> symlink (tested now).

This must have been an error on my side mixing previous builds.
No errors using touch -h on files.

Sorry for the confusion

>
> Afterall, I think it would be easier to add a guard around touch as
> initially proposed.
>
> Just my 2 cents
>
 Andrea

Patch

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 6893e38..ebff0ba 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -110,8 +110,14 @@  IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME
 IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
 IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
 IMAGE_CMD_tar.xz = "cd ${IMAGE_ROOTFS} && tar --xz -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.xz ."
-IMAGE_CMD_cpio = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)"
-IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)"
+IMAGE_CMD_cpio () {
+	touch ${IMAGE_ROOTFS}/init
+	cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
+}
+IMAGE_CMD_cpio.gz () {
+	touch ${IMAGE_ROOTFS}/init
+	cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz)
+}
 IMAGE_CMD_cpio.xz = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.xz) ${EXTRA_IMAGECMD}"
 IMAGE_CMD_cpio.lzma = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | xz --format=lzma -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"