[OE-core] issues encountered using wic

Tom Zanussi tom.zanussi at intel.com
Fri Oct 31 16:47:02 UTC 2014


Hi,

On Fri, 2014-10-31 at 10:36 -0500, Peter A. Bigot wrote:
> 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.
> 

It sounds like a nice enhancement, though I'm not sure about the exact
implementation.  As it happens, someone just today asked me to review
some changes to wic that include a 'rootfs building functionality' that
might overlap with this.  Let me take a look at that and get back to
once I've taken a look.

> 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.
> 

I don't see any way around this, unless you added wildcarding.  Adding
Maciej, who added this capability for uboot and might have some ideas...

Tom 

> Peter





More information about the Openembedded-core mailing list