All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Geiser <geiseri@geekcentral.pub>
To: "ed.bartosh@linux.intel.com" <ed.bartosh@linux.intel.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Wic and "live" images
Date: Tue, 31 May 2016 11:19:53 -0400	[thread overview]
Message-ID: <15507664fc6.c45b162328322.6290427595322992343@geekcentral.pub> (raw)
In-Reply-To: <20160524195145.GA21158@linux.intel.com>


 ---- On Tue, 24 May 2016 15:51:45 -0400 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:  

[...snip...]

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

I am at a loss how to do this because it is a efi system partition.  Really all it needs is the kernel, initramfs and bootx64.  I see how to do the kernel and the bootx64 in the existing plugin.  What I get turned around with is the initramfs.  It seems like there is no way to put that in, or use a kernel with the initramfs appended.  Is this a limitation that is fixed by "send a patch" or am I missing something there.

 >  
 > >  
 > >  > 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. 
 
I am not groking this concept because it seems without a robust library of plugins the wks files become very hard to implement.  Is this true, or am I again missing something obvious.

Thanks for your patience. 



      parent reply	other threads:[~2016-05-31 15:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19  9:52 Wic and "live" images Ian Geiser
2016-05-23 10:36 ` Ed Bartosh
2016-05-23 12:13   ` Ian Geiser
2016-05-23 13:00     ` Sergey 'Jin' Bostandzhyan
2016-05-23 13:09       ` Ian Geiser
2016-05-24 19:51     ` Ed Bartosh
2016-05-24 19:56       ` Christopher Larson
2016-05-24 20:16         ` Ed Bartosh
2016-05-24 20:30           ` Christopher Larson
2016-05-25 11:35             ` Ed Bartosh
2016-05-25 20:04               ` Christopher Larson
2016-05-31 15:31                 ` Ian Geiser
2016-05-31 16:13                   ` Christopher Larson
2016-05-31 15:24         ` Ian Geiser
2016-05-31 15:19       ` Ian Geiser [this message]

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=15507664fc6.c45b162328322.6290427595322992343@geekcentral.pub \
    --to=geiseri@geekcentral.pub \
    --cc=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.