From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: Gary Thomas <gary@mlbassoc.com>,
openembedded-core@lists.openembedded.org
Subject: Re: Create more than one image with WIC
Date: Wed, 15 Mar 2017 14:58:10 +0200 [thread overview]
Message-ID: <20170315125810.GA28986@linux.intel.com> (raw)
In-Reply-To: <1489562674.6396.89.camel@intel.com>
On Wed, Mar 15, 2017 at 08:24:34AM +0100, Patrick Ohly wrote:
> On Tue, 2017-03-14 at 20:06 +0200, Ed Bartosh wrote:
> > On Tue, Mar 14, 2017 at 06:49:45PM +0100, Patrick Ohly wrote:
> > >
> > > > It's not a big deal to run wic sequentially to produce multiple images,
> > > > but it will create more problems than it solves I believe. It will be slower and
> > > > will make a mess in image naming in deploy directory.
> > >
> > > I personally would prefer to support generating more than one wic image
> > > per image recipe. The different output files could be distinguished with
> > > an additional suffix (".efi.wic", ".live.wiC", etc.) where the suffix is
> > > either specified by the WKS file or the configuration where the WKS file
> > > is selected - the latter might be a bit more flexible.
> > >
> >
> > From my point of view ths would be against the current design of oe
> > image building susbsystem. It would be also more complex and slower
> > unless we'll find a way to dynamically generate multiple image creation
> > tasks per one recipe and run them in parallel. In this case it will be
> > even more complex.
>
> That's a good point. However, directly sharing the content of the build
> directory from different recipes is also against the OE design and
> requires special attention, for example to suppressing the do_rootfs
> task in one recipe and preventing do_rm_work in the other.
>
> Either way, something that works out of the box might be useful.
I'm going to address this in near future when I'll be working on
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073
Feel free to comment on it, btw.
So far the plan is to treat EFI boot partition as a rootfs. wic job
would be to simply put content of multiple rootfs-es into partitions of
the final image. No suppressing of do_rootfs would be needed, I hope.
Regarding do_rm_work. It should not touch rootfs directories, I believe.
--
Regards,
Ed
next prev parent reply other threads:[~2017-03-15 13:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 9:44 Create more than one image with WIC Daniel Schultz
2017-03-08 10:57 ` Ed Bartosh
2017-03-08 13:41 ` Gary Thomas
2017-03-08 13:43 ` Ed Bartosh
2017-03-13 16:16 ` Daniel Schultz
2017-03-14 17:11 ` Ed Bartosh
2017-03-14 17:49 ` Patrick Ohly
2017-03-14 18:06 ` Ed Bartosh
2017-03-15 7:24 ` Patrick Ohly
2017-03-15 12:58 ` Ed Bartosh [this message]
2017-03-15 13:39 ` Patrick Ohly
2017-03-15 13:41 ` Patrick Ohly
2017-03-15 14:01 ` Ed Bartosh
2017-03-15 14:47 ` Ed Bartosh
2017-03-15 15:09 ` Patrick Ohly
2017-03-15 15:04 ` Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170315125810.GA28986@linux.intel.com \
--to=ed.bartosh@linux.intel.com \
--cc=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.