I've started to transition to wic (in master) in hopes it reduces the
amount of host passwd contamination resulting from creating SD images by
untarring the rootfs onto an SD card. I've run into the following
initial issues:
First, wic requires a populated rootfs, by default in the recipe build
directory. Two issues: (1) this normally removed by rm_work, and (2)
bitbake foo-image will not populate that directory if the required
artifacts are available from sstate-cache (as happens when you then add
foo-image to RM_WORK_EXCLUDE and reinvoke bitbake).
Both could be solved by getting the rootfs contents from an archive
created by the image instead of assuming it's unpacked somewhere
already. Requiring IMAGE_FSTYPES to contain "tar.bz2" for wic doesn't
seem burdensome. Taking this path also opens up the possibility for wic
plug-ins to customize configuration files (such as host keys) in the
image rootfs without contaminating a shared resource used by other
invocations of wic.
If this seems like a reasonable approach and the wic maintainers would
like assistance with it, I'd be happy to put together a patch.
Second, wic requires IMAGE_BOOT_FILES to be provided (normally in
machine.conf, as with meta-yocto-bsp's beaglebone.conf). I normally use
the beaglebone.conf from meta-ti, and found copying the IMAGE_BOOT_FILES
setting to that BSP layer didn't work because the reference to
${UBOOT_SUFFIX} remained empty. meta-yocto-bsp's beaglebone.conf defines
and uses UBOOT_SUFFIX="img", but this is fragile as the real
UBOOT_SUFFIX comes from u-boot.inc (where the default is "bin") or some
other override.
Is there a way to resolve the potential inconsistency other than
hard-coding a specific suffix in machine.conf? "include u-boot.inc" in
the machine.conf seems like a bad idea.
Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
