On Oct 7, 2016 12:39 PM, "Adam Williamson" <adamw...@fedoraproject.org> 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
