On Fri, Oct 7, 2016 at 2:32 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > 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. It's come up, and mbriza has some ideas about how to do it safely, so we'll see if it's worth the risks. I'm very skeptical that persistence is a critical necessity, rather than neat. If you need persistence, the installer should be capable of installing to your USB stick media and making it a real installed OS seeing as that's what it's being used for. Modifying the image at all breaks the existing media verification option in the boot menu, and we know people get bad writes using bad or flaky media. We could get this back various ways: embedded sha1sum of the squashfs.img and have dracut do a comparison at boot time; dmverity is a valid option geared explicitly for this and can include Reed-Solomon error correction; and Btrfs. The Btrfs option is kinda need because a.) it's on-the-fly instead of all at once b.) it's every time a block is read, not one time, c.) can't be bypassed by the user, and d.) Btrfs supports overlays with the seed device function. [1] Seed device was actually intended for this specific use case. And it's not a new feature, January 2009, upstream considers it stable. [2] [1] https://btrfs.wiki.kernel.org/index.php/Seed-device [2] https://btrfs.wiki.kernel.org/index.php/Status -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
