[CentOS-devel] [CentOS-qa] 5.4 - i386 isos and tree

[Douglas McClendon]

Patrice Guay wrote:
> Douglas McClendon wrote:
>>>>> Patrice Guay wrote:
>>>>>> Phil Schaffner wrote:
>>>>>>> What help do you need on
>>>>>>> getting persistence working, or on LiveCD development in general?
>>>>>>>
>>>>>> For the persistence feature, I am looking for a set of patches 
>>>>>> that apply for the current livecd-tools package. I am currently 
>>>>>> comparing livecd-tools 015 and 014. Since the persistence feature 
>>>>>> was added in the 015 version, I will try to extract the required 
>>>>>> patches from the differences between both versions. Any help on 
>>>>>> this front would be appreciated.
>> The bleeding edge first pass bits are here-
>>
>> http://filteredperception.org/downloads/overlay/20091027/livecd-tools-014-6dmc.src.rpm 
>>
>>
>> I've successfully tested something that either is equivalent to that 
>> build, or very very close.  But I'll put out a really tested srpm in a 
>> couple more days, which hopefully will also have the useful 
>> separate-filesystem persistenthome feature, as well as the global 
>> persistence incorporated here.
>>
> I will take a look at this updated version of livecd-tools. To 
> incorporate this version into the current livecd-tools project, I will 
> explode your source RPM, examine and pick the relevant patches.

Cool.  I think I made it pretty simple, just the additions of the
patches.  The patches themselves were all just vanilla downloads from
the gitweb 'raw' links.  I believe I only put relevant patches in.  Or
rather, I think I took all the patches up to the mayflower split because
I knew they would apply, then after that only took relevant, or what
seemed like really useful patches.

Also, my test in progress of those exact bits just succeeded, so you can 
take that as is.  There might be one or two patches (reset_overlay) 
which are in there, and postdate the persistenthome ones that are also 
desirable.  But I'd guess applying just the one or two out of order 
won't interfere much.

Now if only I could get some other devicemapper developers to buy into 
my theory of having dm-snapshot intelligently respond to the new discard 
request mechanism.  Then this form of LiveUSB persistence would be much 
more usable.  I.e. currently your overlay file resources can and do get 
drained by created and deleted files that the block layer at the moment 
doesn't handle as efficiently as possible.  This is also the reason why 
you might want /home on a seperately mounted, not-dm-shapshotted 
loopback file ala the persistenthome feature.

Cheers,

-dmc