[OE-core] Wic and "live" images

Wed May 25 20:04:50 UTC 2016

On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh <ed.bartosh at linux.intel.com>
wrote:

> On Tue, May 24, 2016 at 01:30:19PM -0700, Christopher Larson wrote:
> > On Tue, May 24, 2016 at 1:16 PM, Ed Bartosh <ed.bartosh at linux.intel.com>
> > wrote:
> >
> > > On Tue, May 24, 2016 at 12:56:39PM -0700, Christopher Larson wrote:
> > > > On Tue, May 24, 2016 at 12:51 PM, Ed Bartosh <ed.bartosh
> @linux.intel.com
> > > >
> > > > wrote:
> > > >
> > > > > On Mon, May 23, 2016 at 08:13:28AM -0400, Ian Geiser wrote:
> > > > > >  > On Thu, May 19, 2016 at 05:52:45AM -0400, Ian Geiser wrote:
> > > > > >  > > Greetings, I am trying to learn "wic" and have been
> confused as
> > > how
> > > > > to create a "live" style image.  I am following "
> > > > >
> > >
> http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html#creating-partitioned-images
> > > "
> > > > > but am getting confused on the target to use to create the a file
> > > system
> > > > > that has a single squashfs file containing my root file system.
> > > > > >  > >
> > > > > >  > > My desired partition layout is as follows:
> > > > > >  > >       40MiB                 40MiB               300MiB
> > > > > >  > >
> > > > >
> +--------------------+-----------------+-----------------------------+
> > > > > >  > > |      BOOT (esp)    |    DATA (fat)   |          ROOT
> (live)
> > > > >   |
> > > > > >  > >
> > > > >
> +--------------------+-----------------+-----------------------------+
> > > > > >  > >
> > > > > >  > > BOOT - efi boot partition with kernel and initramfs
> > > > > >  > > DATA - generic fat filesystem to hold configuration files
> > > > > >  > > ROOT - an ext4 filesystem that contains a single os.img,
> which
> > > is a
> > > > > squashfs file.
> > > > > >  > >
> > > > > >  > > I have ROOT and DATA figured out but I am at a loss as how
> to
> > > > > generate the os.img file and copy it into ROOT.  If I generate the
> > > os.img
> > > > > file with bitbake and then use the "-r" option to manually supply a
> > > > > directory structure it works, but I would rather have it done from
> a
> > > wks
> > > > > file for automation reasons.
> > > > > >  > >
> > > > > >  > > Any hints?
> > > > > >  > I'd suggest to use wic image type and generate your image by
> > > bitbake.
> > > > > >  > You can find example wic-image-minimal.bb and
> > > wic-image-minimal.wks
> > > > > in ../meta-selftest/recipes-test/images/
> > > > > >  >
> > > > > > This is where I started.  I was able to make it work but not
> with my
> > > > > configuration above.  It looks like I can use a type of "fsimage"
> for
> > > my
> > > > > "ROOT" partition, but I have not been able to figure out the syntax
> > > there
> > > > > yet.  For "BOOT" I am at a complete loss.  In theory "bootimg-efi"
> but
> > > > > there doesn't seem to be a way to provide an initramfs.
> > > > >
> > > > > How about creating recipe to prepare content or your boot
> partition and
> > > > > then using --source rootfs --rootfs-dir=<your recipe> ?
> > > > > This is much more generic way of creating partitioned images from
> my
> > > > > point of view. Image recipes should take care of content and wic
> takes
> > > > > care of
> > > > > putting that content into partitions according to the partitioning
> > > > > scheme described in .wks
> > > > >
> > > > > Does it make sense for you?
> > > > >
> > > > > >
> > > > > >  > You can probably do the same by using wic plugins, but I'd not
> > > suggest
> > > > > >  > to go this way. Using wic image type is simpler, more
> consistent,
> > > > > easier to do and provides higher level of automation.
> > > > > >
> > > > > > Is using the wic image type and a plugin mutually exclusive?
> > > > > No, not at all. However, I personally found the way I described
> above
> > > > > more consistent, flexible and easy to implement and maintain.
> > > > >
> > > >
> > > > The thing is, it's likely the machine/bsp setting the WKS_FILE, yet
> in
> > > > OE/yocto we prefer machine/distro/image to be orthogonal. If you're
> > > > injecting machine specific logic into an image, that image isn't
> going to
> > > > be generally useful for all machines, and so violates our philosophy.
> > >
> > > I'm not sure I understand why it has to be machine-dependent setting in
> > > the .wks Can you give some example?
> >
> >
> > I don't understand the question. The .wks is machine specific by
> > definition. It includes knowledge of the expectations of the boot process
> > on the hardware the image is used on, what the boot device name is, etc.
>
> Sorry for not being clear. Now I understand what you mean. I didn't know
> about this philosopy when I implemented handling wic image types in
> image core classes. Are you suggesting to remove it and keep using wic
> as only as a separate tool?

It's debatable. As long as we keep the logic separated, such that anything
bsp specific is in the machine or bsp layer, so the images are independent
of any bsp, then we're fine. If we need to keep certain aspects of rootfs /
image preparation outside of wic, then we'd need the machines which need
such setup to use a hook to ensure it's applied to all images, i.e. an
IMAGE_POSTPROCESS_COMMAND, and we'd need to document that.

That might be doable, but we definitely need to give careful thought to
what pieces of information about the image creation process come from
where. Certain aspects are clearly distro, i.e. extra image space, and
possibly other partitioning like splitting up the rootfs into multiple
partitions, but others are clearly bsp, i.e. setup of a boot partition if
the bootloader expects it, and image recipes need to work regardless of
what distro or machine are selected.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160525/a9217f8c/attachment-0002.html>