New distribution definition for poky-tiny
v3 cover New distribution definition for poky-tiny
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):
1.2M bzImage-qemux86.bin
1.4M core-image-minimal-qemux86.cpio.gz
After mounting the rootfs:
$ sudo du -hs . 3.4M .
$ sudo ~/bin/dirsize.py 25000
[sudo] password for dvhart:
2927998 .
1754686 ./lib
1022080 ./lib/libc-2.13.so
157124 ./lib/libm-2.13.so
119036 ./lib/ld-2.13.so
96128 ./lib/libpthread-2.13.so
91960 ./lib/libnsl-2.13.so
83748 ./lib/libresolv-2.13.so
46656 ./lib/libnss_files-2.13.so
34588 ./lib/libnss_compat-2.13.so
30624 ./lib/librt-2.13.so
26056 ./lib/libcrypt-2.13.so
549600 ./bin
549600 ./bin/busybox
531908 ./sbin
531908 ./sbin/ldconfig
71860 ./etc
28006 ./etc/init.d
Displayed 2789508/2927998 bytes (95.27%)This image can be tested in qemu with:
qemu-system-i386 -kernel /build/poky/qemux86/tmp/deploy/images/bzImage-qemux86.bin -append "console=ttyS0,115200 root=0800" -nographic /build/poky/qemux86/tmp/deploy/images/core-image-minimal-qemux86.ext2
This results in booting to a busybox shell:/bin/sh: can't access tty; job control turned off
/ #
While some improvement is still needed, especially with the init scripting and the linux-yocto-tiny integration with the linux-yocto kernel tools, this gets us started and gets the core in place for others to start using it and help to shape the init process, etc.
Thanks,
Darren
The following changes since commit 6cd5faddad3c69e7e81e7f66d87a3ee650ec717e:
task-core-boot: Allow DISTRO to disable keymaps via VIRTUAL-RUNTIME_keymaps (2011-12-28 15:28:20 -0800)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dvhart/tiny-v3
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/tiny-v3
Darren Hart (3):
distro: Add POKY_DEFAULT_EXTRA_R* variables
distro: Add poky-tiny distro definition
image_types: Ensure /init exists for cpio rootfs archives
meta-yocto/conf/distro/poky-tiny.conf | 103 +++++++++++++++++++++++++++++++++ meta-yocto/conf/distro/poky.conf | 8 ++- meta/classes/image_types.bbclass | 10 +++- 3 files changed, 117 insertions(+), 4 deletions(-) create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
Signature · 1 line
1.7.6.4
PATCH v3 1/3 distro: Add POKY_DEFAULT_EXTRA_R* variables
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".
--- meta-yocto/conf/distro/poky.conf | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-)
meta-yocto/conf/distro/poky.conf +6 -2
@@ -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}"
Signature · 1 line
1.7.6.4
PATCH v3 2/3 distro: Add poky-tiny distro definition
In reply to Darren HartPoky-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.
--- 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
meta-yocto/conf/distro/poky-tiny.conf new file +103 -0
@@ -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 = ""
Signature · 1 line
1.7.6.4
Re: [PATCH 2/3] distro: Add poky-tiny distro definition
Quoted 17 lines · Darren Hart
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_FEATUREelements.Signed-off-by Darren Hart <[email protected]>---
meta-yocto/conf/distro/poky-tiny.conf | 103 +++++++++++++++++++++++++++++++++1 files changed, 103 insertions(+), 0 deletions(-)create mode 100644
meta-yocto/conf/distro/poky-tiny.confmeta-yocto/conf/distro/poky-tiny.conf new file +0
-0
meta-yocto/conf/distro/poky-tiny.conf line 5
Quoted 5 lines
meta-yocto/conf/distro/poky-tiny.conf new file +5
-0@@ -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.
Quoted 101 lines
meta-yocto/conf/distro/poky-tiny.conf new file +98
-1+# 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
Re: [PATCH 2/3] distro: Add poky-tiny distro definition
Quoted 12 lines · Khem Raj
Quoted 11 lines · Darren Hart
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_FEATUREelements.Signed-off-by Darren Hart <[email protected]>--- 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
Quoted 14 lines
meta-yocto/conf/distro/poky-tiny.conf line 5
Quoted 11 lines
meta-yocto/conf/distro/poky-tiny.conf new file +5
-0@@ -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?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 2/3] distro: Add poky-tiny distro definition
Quoted 11 lines · Darren Hart
Quoted 10 lines
meta-yocto/conf/distro/poky-tiny.conf line 5
Quoted 7 lines
+++
b/meta-yocto/conf/distro/poky-tiny.confmeta-yocto/conf/distro/poky-tiny.conf new file +5
-0@@ -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.
Quoted 2 lines
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 :)
Signature · 1 line
Christopher Larson
Re: [PATCH 2/3] distro: Add poky-tiny distro definition
In reply to Darren HartDarren,
Quoted 10 lines · Darren Hart
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_FEATUREelements.Signed-off-by Darren Hart <[email protected]>--- 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.
Re: [PATCH 2/3] distro: Add poky-tiny distro definition
Quoted 22 lines · Leon Woestenberg
Darren,
On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <[email protected]> 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 otherDISTRO_FEATURE
elements.Signed-off-by Darren Hart <[email protected]>---
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.
Quoted 7 lines
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 directoryWhat 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
PATCH v3 3/3 image_types: Ensure /init exists for cpio rootfs archives
In reply to Darren HartIn 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.
--- meta/classes/image_types.bbclass | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
meta/classes/image_types.bbclass +8 -2
@@ -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}"
Signature · 1 line
1.7.6.4
Re: [PATCH 3/3] image_types: Ensure /init exists for cpio rootfs archives
Apologies, this should have gone to oe-core :/
I will forward there.
Quoted 33 lines · Darren Hart
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 <[email protected]>--- meta/classes/image_types.bbclass | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +8
-2@@ -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}"
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
PATCH 1/1 image_types: Ensure /init exists for cpio rootfs archives
In reply to Darren Hart<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.
--- meta/classes/image_types.bbclass | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
meta/classes/image_types.bbclass +8 -2
@@ -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}"
Signature · 6 lines
1.7.6.4 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 1 line · Darren Hart
<I sent this to the yocto list by mistake, forwarding here for comment>
Seems sane to me.
Signature · 1 line
Christopher Larson
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
In reply to Darren HartQuoted 5 lines · Darren Hart
<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?
Quoted 3 lines
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 "
Quoted 35 lines
Signed-off-by Darren Hart <[email protected]>---
meta/classes/image_types.bbclass | 10 ++++++++--1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +0
-0@@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAMEIMAGE_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 ."
meta/classes/image_types.bbclass +8
-2-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
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Regards
Andrea Adami
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 9 lines · Andrea Adami
Quoted 5 lines · Darren Hart
<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
Quoted 55 lines
Quoted 4 lines
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 "
Quoted 35 lines
Signed-off-by Darren Hart <[email protected]>--- meta/classes/image_types.bbclass | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +8
-3@@ -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
[email protected]
https://lists.yoctoproject.org/listinfo/yoctoQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreRegards
Andrea Adami
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 10 lines · Darren Hart
Quoted 7 lines · Andrea Adami
Quoted 5 lines · Darren Hart
<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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 64 lines
--
DarrenQuoted 49 lines
Quoted 4 lines
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 "
Quoted 35 lines
Signed-off-by Darren Hart <[email protected]>---
meta/classes/image_types.bbclass | 10 ++++++++--1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +0
-0@@ -110,8 +110,14 @@ IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAMEIMAGE_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 ."
meta/classes/image_types.bbclass +8
-2-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
[email protected]
https://lists.yoctoproject.org/listinfo/yoctoQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreRegards
Quoted 6 lines
Andrea Adami
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
In reply to Darren HartQuoted 25 lines · Darren Hart
<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<[email protected]>--- meta/classes/image_types.bbclass | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +1
-2@@ -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 () {
meta/classes/image_types.bbclass IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS}&& tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME · line 123
Quoted 10 lines
meta/classes/image_types.bbclass +7
-0+ 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!
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 58 lines · Saul Wold
Quoted 42 lines · Darren Hart
<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<[email protected]>---
meta/classes/image_types.bbclass | 10 ++++++++--1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +0
-0@@ -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)meta/classes/image_types.bbclass +5
-1+} +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) +}Quoted 9 lines
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.
Quoted 8 lines
Thanks
Sau!_______________________________________________
Openembedded-core mailing list
[email protected]
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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 68 lines · Andrea Adami
Quoted 58 lines · Saul Wold
Quoted 42 lines · Darren Hart
<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<[email protected]>---
meta/classes/image_types.bbclass | 10 ++++++++--1 files changed, 8 insertions(+), 2 deletions(-)meta/classes/image_types.bbclass +0
-0@@ -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)meta/classes/image_types.bbclass +5
-1+} +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) +}Quoted 9 lines
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.
Quoted 8 lines
Thanks
Sau!_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 8 lines
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 deniedAndrea
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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 10 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeif [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiNow, 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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 8 lines · Richard Purdie
Quoted 7 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeif [! -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?
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 8 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 4 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg like
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiWhy? 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
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
)
Quoted 21 lines
--
DarrenQuoted 10 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Regards
Andrea
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 13 lines · Andrea Adami
Quoted 12 lines · Darren Hart
Quoted 8 lines · Richard Purdie
Quoted 7 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeif [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fi
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
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
Quoted 29 lines
Quoted 21 lines
--
DarrenQuoted 10 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux KernelQuoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreRegards
Andrea
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
In reply to Andrea AdamiQuoted 24 lines · Andrea Adami
Quoted 8 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 4 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeQuoted 8 lines
Quoted 3 lines
Quoted 3 lines
if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiWhy? 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
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 39 lines · Richard Purdie
Quoted 24 lines · Andrea Adami
Quoted 8 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 4 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeQuoted 8 lines
Quoted 3 lines
Quoted 3 lines
if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiWhy? 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
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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,
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 54 lines · Andrea Adami
Quoted 39 lines · Richard Purdie
Quoted 24 lines · Andrea Adami
Quoted 8 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 4 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeQuoted 8 lines
Quoted 3 lines
Quoted 3 lines
if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiWhy? 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
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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,
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreok, 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/
Quoted 7 lines
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
Re: [PATCH] image_types: Ensure /init exists for cpio rootfs archives
Quoted 66 lines · Andrea Adami
Quoted 54 lines · Andrea Adami
Quoted 39 lines · Richard Purdie
Quoted 24 lines · Andrea Adami
Quoted 8 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 4 lines · Andrea Adami
I'd say we have to test for the in-existence of the file instead of blindly touching it.
Smthg likeQuoted 8 lines
Quoted 3 lines
Quoted 3 lines
if [! -e ${IMAGE_ROOTFS}/init]; then
touch ${IMAGE_ROOTFS}/init
fiWhy? 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
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Now, repeating that block for all 4 cpio images is a bit ugly... better ideas?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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,
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreok, 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/
Quoted 7 lines
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:
Quoted 8 lines
the /init symlink in rootfs is absolute, being its path is pointing to
/usr/bin/kexecbootin 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
Quoted 6 lines
Afterall, I think it would be easier to add a guard around touch as initially proposed.
Just my 2 cents
Andrea
Quoted 9 lines · Darren Hart
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.
Quoted 6 lines
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.
Signature · 1 line
Christopher Larson
Hello Darren,
Quoted 5 lines · Darren Hart
V3:
o Rebase on master
o Dependent on oe-core series "Fixes for tiny distros and
linux-yocto-tiny"
Quoted 9 lines
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.
Quoted 13 lines · Leon Woestenberg
Quoted 11 lines · Darren Hart
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.
Quoted 8 lines
Quoted 3 lines
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 :)
Signature · 1 line
Christopher Larson
Hello all,
Quoted 10 lines · Chris Larson
Quoted 7 lines · Leon Woestenberg
Quoted 2 lines · Darren Hart
Poky-tiny defines a new distro policy for building tiny Linux images.
Does this current image require write access at first boot?
Quoted 7 lines
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.
Quoted 11 lines · Leon Woestenberg
Ah, I missed this line:
o Read-only or RAMFS root filesystemHowever, 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
Quoted 16 lines · Leon Woestenberg
Hello Darren,
On Thu, Dec 29, 2011 at 12:45 AM, Darren Hart <[email protected] <mailto:[email protected]>> 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.
Quoted 8 lines
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.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel