issues encountered using wic

["Peter A. Bigot" <pab@pabigot.com>]

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