On Oct 7, 2016 12:39 PM, "Adam Williamson" <adamwill@xxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 2016-10-03 at 20:03 +0000, John Florian wrote:
> > On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
> > If we do not 'support' livecd-iso-to-disk any more, we no longer
> > support:
> >
> > 1) persistent storage (via overlays)
> > 2) non-destructive write
> >
> >
> > I've known for quite some time that livecd-tools was/is to be
> > replaced with livemedia-creator, but only now did I realize that lm-c
> > won't have persistent storage -- I simply have never had the time to
> > explore it. I'm extremely dependent on the persistent storage as my
> > whole day job revolves around making hundreds of little mostly-
> > stateless appliances for data collection purposes and has so since
> > F13 or so. These have been built with livecd-iso-to-disk and lots of
> > glue via specialized kickstarts and other custom packages. These
> > appliances leverage a stateless OS very robustness, but do expect
> > some persistent storage for their management. So the above certainly
> > caught my attention.
>
> There's a slight misconception in the above.
>
> livemedia-creator *creates the image files themselves*. We're not
> talking about that in this thread. We're talking about the tools for
> taking an image that's been created - whether by livecd-creator or
> livemedia-creator or anything else - and writing them to a USB stick.
>
> The 'persistence' feature requires support both in the image itself and
> in the tool used to write it. I believe livemedia-creator-produced
> images are set up to support persistence, just like livecd-creator-
> produced images were.
>
> The issue here is that we are discussing what tools for *writing the
> image to a USB stick* should be 'supported' / 'recommended' / whatever,
> and we'd kinda like to drop livecd-iso-to-disk from that group, but it
> is currently the only one of the 'write image to stick' tools which
> supports persistence.
At the risk of muddying the waters a bit: now that OverlayFS is here, I think that even a dd-copied image should be able to support persistence. The image could notice that it's dd-copied (by checking GPT GUIDs or layout or whatever), see that there's extra space at the end, and allocate it.
This could reduce the testing explosion a bit if all of the supported image writing tools ended up being equivalent to dd.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
