* [PATCH 1/3] distro: Add POKY_DEFAULT_EXTRA_R* variables
2011-12-28 23:45 [PATCH V3 0/3] New distribution definition for poky-tiny Darren Hart
@ 2011-12-28 23:45 ` Darren Hart
2011-12-28 23:45 ` [PATCH 2/3] distro: Add poky-tiny distro definition Darren Hart
` (3 subsequent siblings)
4 siblings, 0 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-28 23:45 UTC (permalink / raw)
To: Yocto Project, raj.khem, koen, kergoth, martin.jansa,
Bruce Ashfield, Tom Zanussi, Richard Purdie
Allow the reuse of poky.conf by distro definitions wanting to remove
content by introducting POKY_DEFAULT_EXTRA_R*. These are appended
to the corresponding DISTRO_EXTRA_R* variables and can be overriden
by distro configs that "require poky.conf".
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
meta-yocto/conf/distro/poky.conf | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index 80d4e47..86f9bf6 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -24,8 +24,12 @@ SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
EXTRAOPKGCONFIG = "poky-feed-config-opkg"
-DISTRO_EXTRA_RDEPENDS += "task-core-boot"
-DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
+# Override these in poky based distros to modify DISTRO_EXTRA_R*
+POKY_DEFAULT_EXTRA_RDEPENDS = "task-core-boot"
+POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
+
+DISTRO_EXTRA_RDEPENDS += " ${POKY_DEFAULT_EXTRA_RDEPENDS}"
+DISTRO_EXTRA_RRECOMMENDS += " ${POKY_DEFAULT_EXTRA_RRECOMMENDS}"
POKYQEMUDEPS = "${@base_contains("INCOMPATIBLE_LICENSE", "GPLv3", "", "qemu-config",d)}"
DISTRO_EXTRA_RDEPENDS_append_qemuarm = " ${POKYQEMUDEPS}"
--
1.7.6.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 2/3] distro: Add poky-tiny distro definition
2011-12-28 23:45 [PATCH V3 0/3] New distribution definition for poky-tiny Darren Hart
2011-12-28 23:45 ` [PATCH 1/3] distro: Add POKY_DEFAULT_EXTRA_R* variables Darren Hart
@ 2011-12-28 23:45 ` Darren Hart
2012-01-04 0:19 ` Khem Raj
2012-01-04 13:56 ` Leon Woestenberg
2011-12-28 23:45 ` [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives Darren Hart
` (2 subsequent siblings)
4 siblings, 2 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-28 23:45 UTC (permalink / raw)
To: Yocto Project, raj.khem, koen, kergoth, martin.jansa,
Bruce Ashfield, Tom Zanussi, Richard Purdie
Poky-tiny is intended for building very small OS images. The distro
definition sets the providers for the kernel and the runtime services.
It also reduces the eglibc component list and other DISTRO_FEATURE
elements.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
meta-yocto/conf/distro/poky-tiny.conf | 103 +++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
diff --git a/meta-yocto/conf/distro/poky-tiny.conf b/meta-yocto/conf/distro/poky-tiny.conf
new file mode 100644
index 0000000..49c4397
--- /dev/null
+++ b/meta-yocto/conf/distro/poky-tiny.conf
@@ -0,0 +1,103 @@
+# Distribution definition for: poky-tiny
+#
+# Copyright (c) 2011, Intel Corporation.
+# All rights reserved.
+#
+# Poky-tiny is intended to define a tiny Linux system comprised of a
+# Linux kernel tailored to support each specific MACHINE and busybox.
+# Poky-tiny sets some basic policy to ensure a usable system while still
+# keeping the rootfs and kernel image as small as possible.
+#
+# The policies defined are intended to meet the following goals:
+# o Serial consoles only (no framebuffer or VGA console)
+# o Basic support for IPV4 networking
+# o Single user ash shell
+# o Static images (no support for adding packages or libraries later)
+# o Read-only or RAMFS root filesystem
+# o Combined Linux kernel + rootfs in under 4MB
+# o Allow the user to select between eglibc or uclibc with the TCLIBC variable
+#
+# This is currently a partial definition, the following tasks remain:
+# [ ] Integrate linux-yocto-tiny ktype into linux-yocto
+# [ ] Define linux-yocto-tiny configs for all supported BSPs
+# [ ] Drop ldconfig from the installation
+# [ ] Modify the runqemu scripts to work with ext2 parameter:
+# runqemu qemux86 qemuparams="-nographic" bootparams="console=ttyS0,115200 root=0800"
+# [ ] Modify busybox to allow for DISTRO_FEATURES-like confiruration
+
+require conf/distro/poky.conf
+DISTRO = "poky-tiny"
+
+# FIXME: consider adding a new "tiny" feature
+#DISTRO_FEATURES_append = " tiny"
+
+# Distro config is evaluated after the machine config, so we have to explicitly
+# set the kernel provider to override a machine config.
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
+PREFERRED_VERSION_linux-yocto-tiny = "3.0%"
+
+# We can use task-core-boot, but in the future we may need a new task-core-tiny
+#POKY_DEFAULT_EXTRA_RDEPENDS += "task-core-boot"
+# Drop kernel-module-af-packet from RRECOMMENDS
+POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
+
+# FIXME: what should we do with this?
+TCLIBCAPPEND = ""
+
+# Disable wide char support for ncurses as we don't include it in
+# in the LIBC features below.
+ENABLE_WIDEC="false"
+
+# Reconfigure eglibc for a smaller installation
+# Comment out any of the lines below to disable them in the build
+DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
+# Required for "who"
+DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
+DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
+DISTRO_FEATURES_LIBC_NET = "libc-inet libc-nis"
+
+DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
+ ${DISTRO_FEATURES_LIBC_MINIMAL} \
+ ${DISTRO_FEATURES_LIBC_REGEX} \
+ ${DISTRO_FEATURES_LIBC_NET} \
+ "
+
+# Comment out any of the lines below to disable them in the build
+# DISTRO_FEATURES options:
+# alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci
+DISTRO_FEATURES_TINY = "pci"
+DISTRO_FEATURES_NET = "ipv4"
+DISTRO_FEATURES_USB = "usbhost"
+#DISTRO_FEATURES_USBGADGET = "usbgadget"
+#DISTRO_FEATURES_WIFI = "wifi"
+
+DISTRO_FEATURES = "${DISTRO_FEATURES_TINY} \
+ ${DISTRO_FEATURES_NET} \
+ ${DISTRO_FEATURES_USB} \
+ ${DISTRO_FEATURES_USBGADGET} \
+ ${DISTRO_FEATURES_WIFI} \
+ ${DISTRO_FEATURES_LIBC} \
+ "
+
+# Use tmpdevfs and the busybox runtime services
+VIRTUAL-RUNTIME_dev_manager = ""
+VIRTUAL-RUNTIME_login_manager = ""
+VIRTUAL-RUNTIME_init_manager = ""
+VIRTUAL-RUNTIME_keymaps = ""
+
+# FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
+# task-core-base to select modutils-initscripts or not. Similar with "net" and
+# netbase.
+
+# By default we only support ext2 and initramfs. We don't build live as that
+# pulls in a lot of dependencies for the live image and the installer, like
+# udev, grub, etc. These pull in gettext, which fails to build with wide
+# character support.
+IMAGE_FSTYPES = "ext2 cpio.gz"
+
+# Drop v86d from qemu dependency list (we support serial)
+# Drop grub from meta-intel BSPs
+# FIXME: A different mechanism is needed here. We could define -tiny
+# variants of all compatible machines, but that leads to a lot
+# more machine configs to maintain long term.
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
--
1.7.6.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 2/3] distro: Add poky-tiny distro definition
2011-12-28 23:45 ` [PATCH 2/3] distro: Add poky-tiny distro definition Darren Hart
@ 2012-01-04 0:19 ` Khem Raj
2012-01-04 16:16 ` Darren Hart
2012-01-04 13:56 ` Leon Woestenberg
1 sibling, 1 reply; 32+ messages in thread
From: Khem Raj @ 2012-01-04 0:19 UTC (permalink / raw)
To: Darren Hart; +Cc: Yocto Project
On Wed, Dec 28, 2011 at 3:45 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> Poky-tiny is intended for building very small OS images. The distro
> definition sets the providers for the kernel and the runtime services.
> It also reduces the eglibc component list and other DISTRO_FEATURE
> elements.
>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> ---
> meta-yocto/conf/distro/poky-tiny.conf | 103 +++++++++++++++++++++++++++++++++
> 1 files changed, 103 insertions(+), 0 deletions(-)
> create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
>
> diff --git a/meta-yocto/conf/distro/poky-tiny.conf b/meta-yocto/conf/distro/poky-tiny.conf
> new file mode 100644
> index 0000000..49c4397
> --- /dev/null
> +++ b/meta-yocto/conf/distro/poky-tiny.conf
> @@ -0,0 +1,103 @@
> +# Distribution definition for: poky-tiny
> +#
> +# Copyright (c) 2011, Intel Corporation.
> +# All rights reserved.
> +#
should this be MIT licensed ?
or do u plan to keep it closed.
> +# Poky-tiny is intended to define a tiny Linux system comprised of a
> +# Linux kernel tailored to support each specific MACHINE and busybox.
> +# Poky-tiny sets some basic policy to ensure a usable system while still
> +# keeping the rootfs and kernel image as small as possible.
> +#
> +# The policies defined are intended to meet the following goals:
> +# o Serial consoles only (no framebuffer or VGA console)
> +# o Basic support for IPV4 networking
> +# o Single user ash shell
> +# o Static images (no support for adding packages or libraries later)
> +# o Read-only or RAMFS root filesystem
> +# o Combined Linux kernel + rootfs in under 4MB
> +# o Allow the user to select between eglibc or uclibc with the TCLIBC variable
> +#
> +# This is currently a partial definition, the following tasks remain:
> +# [ ] Integrate linux-yocto-tiny ktype into linux-yocto
> +# [ ] Define linux-yocto-tiny configs for all supported BSPs
> +# [ ] Drop ldconfig from the installation
> +# [ ] Modify the runqemu scripts to work with ext2 parameter:
> +# runqemu qemux86 qemuparams="-nographic" bootparams="console=ttyS0,115200 root=0800"
> +# [ ] Modify busybox to allow for DISTRO_FEATURES-like confiruration
> +
> +require conf/distro/poky.conf
> +DISTRO = "poky-tiny"
> +
> +# FIXME: consider adding a new "tiny" feature
> +#DISTRO_FEATURES_append = " tiny"
> +
> +# Distro config is evaluated after the machine config, so we have to explicitly
> +# set the kernel provider to override a machine config.
> +PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
> +PREFERRED_VERSION_linux-yocto-tiny = "3.0%"
> +
> +# We can use task-core-boot, but in the future we may need a new task-core-tiny
> +#POKY_DEFAULT_EXTRA_RDEPENDS += "task-core-boot"
> +# Drop kernel-module-af-packet from RRECOMMENDS
> +POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
> +
> +# FIXME: what should we do with this?
> +TCLIBCAPPEND = ""
> +
> +# Disable wide char support for ncurses as we don't include it in
> +# in the LIBC features below.
> +ENABLE_WIDEC="false"
> +
> +# Reconfigure eglibc for a smaller installation
> +# Comment out any of the lines below to disable them in the build
> +DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
> +# Required for "who"
> +DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
> +DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
> +DISTRO_FEATURES_LIBC_NET = "libc-inet libc-nis"
> +
> +DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
> + ${DISTRO_FEATURES_LIBC_MINIMAL} \
> + ${DISTRO_FEATURES_LIBC_REGEX} \
> + ${DISTRO_FEATURES_LIBC_NET} \
> + "
> +
> +# Comment out any of the lines below to disable them in the build
> +# DISTRO_FEATURES options:
> +# alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci
> +DISTRO_FEATURES_TINY = "pci"
> +DISTRO_FEATURES_NET = "ipv4"
> +DISTRO_FEATURES_USB = "usbhost"
> +#DISTRO_FEATURES_USBGADGET = "usbgadget"
> +#DISTRO_FEATURES_WIFI = "wifi"
> +
> +DISTRO_FEATURES = "${DISTRO_FEATURES_TINY} \
> + ${DISTRO_FEATURES_NET} \
> + ${DISTRO_FEATURES_USB} \
> + ${DISTRO_FEATURES_USBGADGET} \
> + ${DISTRO_FEATURES_WIFI} \
> + ${DISTRO_FEATURES_LIBC} \
> + "
> +
> +# Use tmpdevfs and the busybox runtime services
> +VIRTUAL-RUNTIME_dev_manager = ""
> +VIRTUAL-RUNTIME_login_manager = ""
> +VIRTUAL-RUNTIME_init_manager = ""
> +VIRTUAL-RUNTIME_keymaps = ""
> +
> +# FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
> +# task-core-base to select modutils-initscripts or not. Similar with "net" and
> +# netbase.
> +
> +# By default we only support ext2 and initramfs. We don't build live as that
> +# pulls in a lot of dependencies for the live image and the installer, like
> +# udev, grub, etc. These pull in gettext, which fails to build with wide
> +# character support.
> +IMAGE_FSTYPES = "ext2 cpio.gz"
> +
> +# Drop v86d from qemu dependency list (we support serial)
> +# Drop grub from meta-intel BSPs
> +# FIXME: A different mechanism is needed here. We could define -tiny
> +# variants of all compatible machines, but that leads to a lot
> +# more machine configs to maintain long term.
> +MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
> --
> 1.7.6.4
>
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 2/3] distro: Add poky-tiny distro definition
2012-01-04 0:19 ` Khem Raj
@ 2012-01-04 16:16 ` Darren Hart
2012-01-04 16:31 ` Chris Larson
0 siblings, 1 reply; 32+ messages in thread
From: Darren Hart @ 2012-01-04 16:16 UTC (permalink / raw)
To: Khem Raj; +Cc: Yocto Project
On 01/03/2012 04:19 PM, Khem Raj wrote:
> On Wed, Dec 28, 2011 at 3:45 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> Poky-tiny is intended for building very small OS images. The distro
>> definition sets the providers for the kernel and the runtime services.
>> It also reduces the eglibc component list and other DISTRO_FEATURE
>> elements.
>>
>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>> ---
>> meta-yocto/conf/distro/poky-tiny.conf | 103 +++++++++++++++++++++++++++++++++
>> 1 files changed, 103 insertions(+), 0 deletions(-)
>> create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
>>
>> diff --git a/meta-yocto/conf/distro/poky-tiny.conf b/meta-yocto/conf/distro/poky-tiny.conf
>> new file mode 100644
>> index 0000000..49c4397
>> --- /dev/null
>> +++ b/meta-yocto/conf/distro/poky-tiny.conf
>> @@ -0,0 +1,103 @@
>> +# Distribution definition for: poky-tiny
>> +#
>> +# Copyright (c) 2011, Intel Corporation.
>> +# All rights reserved.
>> +#
>
> should this be MIT licensed ?
> or do u plan to keep it closed.
Should be MIT - my understanding was that was the default if no license
was specified in a particular file. Is that not correct?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] distro: Add poky-tiny distro definition
2012-01-04 16:16 ` Darren Hart
@ 2012-01-04 16:31 ` Chris Larson
0 siblings, 0 replies; 32+ messages in thread
From: Chris Larson @ 2012-01-04 16:31 UTC (permalink / raw)
To: Darren Hart; +Cc: Yocto Project
On Wed, Jan 4, 2012 at 9:16 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> +++ b/meta-yocto/conf/distro/poky-tiny.conf
>>> @@ -0,0 +1,103 @@
>>> +# Distribution definition for: poky-tiny
>>> +#
>>> +# Copyright (c) 2011, Intel Corporation.
>>> +# All rights reserved.
>>> +#
>>
>> should this be MIT licensed ?
>> or do u plan to keep it closed.
>
> Should be MIT - my understanding was that was the default if no license
> was specified in a particular file. Is that not correct?
Well, yes, but this does say "All Rights Reserved", too :)
--
Christopher Larson
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] distro: Add poky-tiny distro definition
2011-12-28 23:45 ` [PATCH 2/3] distro: Add poky-tiny distro definition Darren Hart
2012-01-04 0:19 ` Khem Raj
@ 2012-01-04 13:56 ` Leon Woestenberg
2012-01-04 14:12 ` Richard Purdie
1 sibling, 1 reply; 32+ messages in thread
From: Leon Woestenberg @ 2012-01-04 13:56 UTC (permalink / raw)
To: Darren Hart; +Cc: Yocto Project
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
Darren,
On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com>wrote:
> Poky-tiny is intended for building very small OS images. The distro
> definition sets the providers for the kernel and the runtime services.
> It also reduces the eglibc component list and other DISTRO_FEATURE
> elements.
>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> ---
> meta-yocto/conf/distro/poky-tiny.conf | 103
> +++++++++++++++++++++++++++++++++
>
On retrospect, does poky-tiny.conf below in openembedded-core (rather than
in a Yocto layer)?
I *do* welcome such a distro in -core, as my use case has always been
similar to this.
Also, this seems to be the first entry in meta-yocto/, but it cannot be
used as a layer:
openembedded-core.git/meta-yocto/conf/layer.conf: [Errno 2] No such file or
directory
What is the expected way to use this? Or is it that the layer file is just
missing?
Regards,
Leon.
[-- Attachment #2: Type: text/html, Size: 1291 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] distro: Add poky-tiny distro definition
2012-01-04 13:56 ` Leon Woestenberg
@ 2012-01-04 14:12 ` Richard Purdie
0 siblings, 0 replies; 32+ messages in thread
From: Richard Purdie @ 2012-01-04 14:12 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Yocto Project, Darren Hart
On Wed, 2012-01-04 at 14:56 +0100, Leon Woestenberg wrote:
> Darren,
>
> On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com>
> wrote:
> Poky-tiny is intended for building very small OS images. The
> distro
> definition sets the providers for the kernel and the runtime
> services.
> It also reduces the eglibc component list and other
> DISTRO_FEATURE
> elements.
>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> ---
> meta-yocto/conf/distro/poky-tiny.conf | 103
> +++++++++++++++++++++++++++++++++
>
> On retrospect, does poky-tiny.conf below in openembedded-core (rather
> than in a Yocto layer)?
> I *do* welcome such a distro in -core, as my use case has always been
> similar to this.
>
> Also, this seems to be the first entry in meta-yocto/, but it cannot
> be used as a layer:
> openembedded-core.git/meta-yocto/conf/layer.conf: [Errno 2] No such
> file or directory
>
> What is the expected way to use this? Or is it that the layer file is
> just missing?
I've slipped up when applying the patch, it was meant for meta-yocto,
sorry. I'll fix that. It won't work standalone.
Cheers,
Richard
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:45 [PATCH V3 0/3] New distribution definition for poky-tiny Darren Hart
2011-12-28 23:45 ` [PATCH 1/3] distro: Add POKY_DEFAULT_EXTRA_R* variables Darren Hart
2011-12-28 23:45 ` [PATCH 2/3] distro: Add poky-tiny distro definition Darren Hart
@ 2011-12-28 23:45 ` Darren Hart
2011-12-28 23:52 ` Darren Hart
2011-12-28 23:54 ` [PATCH] " Darren Hart
2011-12-29 0:16 ` [PATCH V3 0/3] New distribution definition for poky-tiny Chris Larson
2011-12-29 1:07 ` Leon Woestenberg
4 siblings, 2 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-28 23:45 UTC (permalink / raw)
To: Yocto Project, raj.khem, koen, kergoth, martin.jansa,
Bruce Ashfield, Tom Zanussi, Richard Purdie
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}"
--
1.7.6.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:45 ` [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives Darren Hart
@ 2011-12-28 23:52 ` Darren Hart
2011-12-28 23:54 ` [PATCH] " Darren Hart
1 sibling, 0 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-28 23:52 UTC (permalink / raw)
To: Yocto Project, raj.khem, koen, kergoth, martin.jansa,
Bruce Ashfield, Tom Zanussi, Richard Purdie
Apologies, this should have gone to oe-core :/
I will forward there.
On 12/28/2011 03:45 PM, Darren Hart wrote:
> 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}"
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:45 ` [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives Darren Hart
2011-12-28 23:52 ` Darren Hart
@ 2011-12-28 23:54 ` Darren Hart
2011-12-29 17:39 ` Chris Larson
` (2 more replies)
1 sibling, 3 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-28 23:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
<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}"
--
1.7.6.4
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:54 ` [PATCH] " Darren Hart
@ 2011-12-29 17:39 ` Chris Larson
2011-12-30 8:25 ` Andrea Adami
2012-01-04 0:07 ` Saul Wold
2 siblings, 0 replies; 32+ messages in thread
From: Chris Larson @ 2011-12-29 17:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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.
--
Christopher Larson
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:54 ` [PATCH] " Darren Hart
2011-12-29 17:39 ` Chris Larson
@ 2011-12-30 8:25 ` Andrea Adami
2011-12-30 23:18 ` Darren Hart
2012-01-04 0:07 ` Saul Wold
2 siblings, 1 reply; 32+ messages in thread
From: Andrea Adami @ 2011-12-30 8:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-30 8:25 ` Andrea Adami
@ 2011-12-30 23:18 ` Darren Hart
2012-01-03 14:57 ` Andrea Adami
0 siblings, 1 reply; 32+ messages in thread
From: Darren Hart @ 2011-12-30 23:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-30 23:18 ` Darren Hart
@ 2012-01-03 14:57 ` Andrea Adami
0 siblings, 0 replies; 32+ messages in thread
From: Andrea Adami @ 2012-01-03 14:57 UTC (permalink / raw)
To: Darren Hart; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2011-12-28 23:54 ` [PATCH] " Darren Hart
2011-12-29 17:39 ` Chris Larson
2011-12-30 8:25 ` Andrea Adami
@ 2012-01-04 0:07 ` Saul Wold
2012-01-04 23:49 ` Andrea Adami
2 siblings, 1 reply; 32+ messages in thread
From: Saul Wold @ 2012-01-04 0:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Darren Hart
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!
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-04 0:07 ` Saul Wold
@ 2012-01-04 23:49 ` Andrea Adami
2012-01-05 0:05 ` Andrea Adami
0 siblings, 1 reply; 32+ messages in thread
From: Andrea Adami @ 2012-01-04 23:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-04 23:49 ` Andrea Adami
@ 2012-01-05 0:05 ` Andrea Adami
2012-01-05 12:30 ` Richard Purdie
0 siblings, 1 reply; 32+ messages in thread
From: Andrea Adami @ 2012-01-05 0:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-05 0:05 ` Andrea Adami
@ 2012-01-05 12:30 ` Richard Purdie
2012-01-05 23:36 ` Darren Hart
0 siblings, 1 reply; 32+ messages in thread
From: Richard Purdie @ 2012-01-05 12:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-05 12:30 ` Richard Purdie
@ 2012-01-05 23:36 ` Darren Hart
2012-01-06 1:00 ` Andrea Adami
0 siblings, 1 reply; 32+ messages in thread
From: Darren Hart @ 2012-01-05 23:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-05 23:36 ` Darren Hart
@ 2012-01-06 1:00 ` Andrea Adami
2012-01-06 1:10 ` Andrea Adami
2012-01-06 10:57 ` Richard Purdie
0 siblings, 2 replies; 32+ messages in thread
From: Andrea Adami @ 2012-01-06 1:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-06 1:00 ` Andrea Adami
@ 2012-01-06 1:10 ` Andrea Adami
2012-01-06 10:57 ` Richard Purdie
1 sibling, 0 replies; 32+ messages in thread
From: Andrea Adami @ 2012-01-06 1:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-06 1:00 ` Andrea Adami
2012-01-06 1:10 ` Andrea Adami
@ 2012-01-06 10:57 ` Richard Purdie
2012-01-06 22:58 ` Andrea Adami
1 sibling, 1 reply; 32+ messages in thread
From: Richard Purdie @ 2012-01-06 10:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-06 10:57 ` Richard Purdie
@ 2012-01-06 22:58 ` Andrea Adami
2012-01-10 23:07 ` Andrea Adami
0 siblings, 1 reply; 32+ messages in thread
From: Andrea Adami @ 2012-01-06 22:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-06 22:58 ` Andrea Adami
@ 2012-01-10 23:07 ` Andrea Adami
2012-01-10 23:28 ` Andrea Adami
0 siblings, 1 reply; 32+ messages in thread
From: Andrea Adami @ 2012-01-10 23:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
2012-01-10 23:07 ` Andrea Adami
@ 2012-01-10 23:28 ` Andrea Adami
0 siblings, 0 replies; 32+ messages in thread
From: Andrea Adami @ 2012-01-10 23:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-28 23:45 [PATCH V3 0/3] New distribution definition for poky-tiny Darren Hart
` (2 preceding siblings ...)
2011-12-28 23:45 ` [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives Darren Hart
@ 2011-12-29 0:16 ` Chris Larson
2011-12-29 1:07 ` Leon Woestenberg
4 siblings, 0 replies; 32+ messages in thread
From: Chris Larson @ 2011-12-29 0:16 UTC (permalink / raw)
To: Darren Hart; +Cc: Yocto Project
On Wed, Dec 28, 2011 at 4:45 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> V3:
> o Rebase on master
> o Dependent on oe-core series "Fixes for tiny distros and linux-yocto-tiny"
>
> RFC V2:
> o Use VIRTUAL-RUNTIME_keymaps as suggested by Martin Jansa
> o Drop poky-common abstraction as suggested by Richard Purdie in
> favor of POKY_DEFAULT_EXTRA_R* variables.
>
> Poky-tiny defines a new distro policy for building tiny Linux images. Rather
> than create new image tasks and recipes, it reuses existing ones, modifying them
> as necessary. See the poky-tiny commit log for details on the policy goals.
>
> In its current form, poky-tiny builds a qemux86 core-image-minimal image
> and kernel in 2.6 MB (compressed):
I haven't had a chance to do much review of this work, though I'm sure
others have done so and commented. I just wanted to say nice work on
this, it's looking quite nice, and the various fixes should make some
lives easier for folks who either do or want to base on the poky
distro configuration.
--
Christopher Larson
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-28 23:45 [PATCH V3 0/3] New distribution definition for poky-tiny Darren Hart
` (3 preceding siblings ...)
2011-12-29 0:16 ` [PATCH V3 0/3] New distribution definition for poky-tiny Chris Larson
@ 2011-12-29 1:07 ` Leon Woestenberg
2011-12-29 1:51 ` Chris Larson
2011-12-29 5:55 ` Darren Hart
4 siblings, 2 replies; 32+ messages in thread
From: Leon Woestenberg @ 2011-12-29 1:07 UTC (permalink / raw)
To: Darren Hart; +Cc: Yocto Project
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
Hello Darren,
On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com>wrote:
> V3:
> o Rebase on master
> o Dependent on oe-core series "Fixes for tiny distros and
> linux-yocto-tiny"
>
> RFC V2:
> o Use VIRTUAL-RUNTIME_keymaps as suggested by Martin Jansa
> o Drop poky-common abstraction as suggested by Richard Purdie in
> favor of POKY_DEFAULT_EXTRA_R* variables.
>
> Poky-tiny defines a new distro policy for building tiny Linux images.
> Rather
>
>
Such images are useful for small Linux firmwares, both often also require a
read-only fs img.
Does this current image require write access at first boot?
Regards,
Leon.
[-- Attachment #2: Type: text/html, Size: 965 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-29 1:07 ` Leon Woestenberg
@ 2011-12-29 1:51 ` Chris Larson
2011-12-29 2:12 ` Leon Woestenberg
2011-12-29 5:55 ` Darren Hart
1 sibling, 1 reply; 32+ messages in thread
From: Chris Larson @ 2011-12-29 1:51 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Yocto Project, Darren Hart
On Wed, Dec 28, 2011 at 6:07 PM, Leon Woestenberg
<sidebranch.openembedded@gmail.com> wrote:
> On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com>
> wrote:
>>
>> V3:
>> o Rebase on master
>> o Dependent on oe-core series "Fixes for tiny distros and
>> linux-yocto-tiny"
>>
>> RFC V2:
>> o Use VIRTUAL-RUNTIME_keymaps as suggested by Martin Jansa
>> o Drop poky-common abstraction as suggested by Richard Purdie in
>> favor of POKY_DEFAULT_EXTRA_R* variables.
>>
>> Poky-tiny defines a new distro policy for building tiny Linux images.
>> Rather
>>
>
> Such images are useful for small Linux firmwares, both often also require a
> read-only fs img.
>
> Does this current image require write access at first boot?
That's a good question. I wonder how well we support ro rootfs today.
It'd be nice to have a declarative mechanism to control use of a
unioning filesystem and/or symlinking or bind mounts. poky-tiny does
say that one of its high level policy guidelines is to have a ro
rootfs, so if it doesn't do it today, presumably it's just a matter of
time :)
--
Christopher Larson
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-29 1:51 ` Chris Larson
@ 2011-12-29 2:12 ` Leon Woestenberg
2012-01-06 11:52 ` Richard Purdie
0 siblings, 1 reply; 32+ messages in thread
From: Leon Woestenberg @ 2011-12-29 2:12 UTC (permalink / raw)
To: Chris Larson; +Cc: Yocto Project, Darren Hart
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Hello all,
On Thu, Dec 29, 2011 at 2:51 AM, Chris Larson <kergoth@gmail.com> wrote:
> On Wed, Dec 28, 2011 at 6:07 PM, Leon Woestenberg
> <sidebranch.openembedded@gmail.com> wrote:
> > On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com>
> > wrote:
> >>
> >> Poky-tiny defines a new distro policy for building tiny Linux images.
> >
> > Does this current image require write access at first boot?
> >
>
> That's a good question. I wonder how well we support ro rootfs today.
> It'd be nice to have a declarative mechanism to control use of a
> unioning filesystem and/or symlinking or bind mounts. poky-tiny does
> say that one of its high level policy guidelines is to have a ro
> rootfs, so if it doesn't do it today, presumably it's just a matter of
> time :)
>
Ah, I missed this line:
o Read-only or RAMFS root filesystem
However, our recipes in many ways depend on write behaviour on first boot.
When under classic OE, I always had to verify each recipe for correct
operation for ro fs's, and did so manually.
Would be nice to cover this use case better.
Regards,
Leon.
[-- Attachment #2: Type: text/html, Size: 1628 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-29 2:12 ` Leon Woestenberg
@ 2012-01-06 11:52 ` Richard Purdie
0 siblings, 0 replies; 32+ messages in thread
From: Richard Purdie @ 2012-01-06 11:52 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Yocto Project, Darren Hart
On Thu, 2011-12-29 at 03:12 +0100, Leon Woestenberg wrote:
> Ah, I missed this line:
> o Read-only or RAMFS root filesystem
>
>
> However, our recipes in many ways depend on write behaviour on first
> boot.
>
> When under classic OE, I always had to verify each recipe for correct
> operation for ro fs's, and did so manually.
>
> Would be nice to cover this use case better.
We are getting much better at running postinstalls at rootfs creation
time meaning that at boot time, there is little remaining work. The
useradd code is one example of where its been hard work to get it
working but hopefully we are there with that.
Cheers,
Richard
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/3] New distribution definition for poky-tiny
2011-12-29 1:07 ` Leon Woestenberg
2011-12-29 1:51 ` Chris Larson
@ 2011-12-29 5:55 ` Darren Hart
1 sibling, 0 replies; 32+ messages in thread
From: Darren Hart @ 2011-12-29 5:55 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Yocto Project
On 12/28/2011 05:07 PM, Leon Woestenberg wrote:
> Hello Darren,
>
>
> On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <dvhart@linux.intel.com
> <mailto:dvhart@linux.intel.com>> wrote:
>
> V3:
> o Rebase on master
> o Dependent on oe-core series "Fixes for tiny distros and
> linux-yocto-tiny"
>
> RFC V2:
> o Use VIRTUAL-RUNTIME_keymaps as suggested by Martin Jansa
> o Drop poky-common abstraction as suggested by Richard Purdie in
> favor of POKY_DEFAULT_EXTRA_R* variables.
>
> Poky-tiny defines a new distro policy for building tiny Linux
> images. Rather
>
>
> Such images are useful for small Linux firmwares, both often also
> require a read-only fs img.
>
> Does this current image require write access at first boot?
I have done a readonly first-boot successfully, and as Chris points out,
it is one of the policy goals. That said, I have not yet looked to see
if there are some post-inst scripts which should be run. There isn't any
kind of init going on, and we'll need to decide how to best handle that
for poky-tiny. Right now I boot using an initramfs with root=/dev/ram0,
it reads an empty /init and falls back to /bin/sh - a more robust and
functional init is probably needed even for poky-tiny.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 32+ messages in thread