[Fedora-livecd-list] [PATCH] livecd persistence - devicemapper style - v3 - still not robust

[Douglas McClendon]

The 3rd pass at my overlay/persistence patch for livecd-tools, isn't 
really bigger than the 2nd, but it is fairly big, and definitely not the 
final version.

So if you want it, or any further updates if and as they become 
available, see

http://filteredperception.org/downloads/overlay/

Summary of changes from the last version -

- much better remount read-only teardown of overlayfs
- findoverlay script debugging cleaned up, and obeys 'quiet' kernel arg
- live script will technically work for initialization of an overlay 
image file, but it is still pretty much a placeholder
- more organized, and revised todo/notes in findoverlay script.
- very ugly (but maybe a bit less than before) mechanism for patching 
the halt and functions scripts to support clean shutdown.  I'm _very_ 
open to suggestions for better ways to do it, than the 
livecd-creator->mayflower->initramfs->/etc/rc.d/init.d/fedora-live path 
currently.  Also note that to get that done I had to put the same ugly 
temporary hack in 3 different config files.  Maybe it is time to take 
care of the TODO that suggests getting fedora-live out of the kickstart 
and into a package.

Of particular note, is that at this point in time, I'm getting a bit 
wary as to whether or not, short of 'fixing' problems that are probably 
beyond my abilities and/or desires, that this entire devicemapper 
snapshot mechanism, using overlay image files on disk, may be fatally 
flawed.  See notes at end of findoverlay script for exact ext3 
corruption error messages, and my random musings on the subject.

I think it may well be that a vastly simpler implementation using only 
raw partitions, such as Ashok's might actually work better.  At least 
for the short term, until I can figure out the problems I'm seeing.  Or 
perhaps even an implementation with unionfs/funionfs.

I would _really_ like to see my method work, but there are also other 
unrelated lower hanging fruit of interest to me that I think I might 
rather be working on.

That said, my code is there, and I'll be more than happy to answer 
questions or brainstorm about it if anybody inquires.  And maybe some 
idea will hit me or someone else soon, and I'll actually be able to make 
it work robustly.  Or really, I may have just run into one bad failure 
case that isn't even reproducable, and further testing will show that it 
works pretty well.

-dmc