[Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta

[Jerry Vonau]

Douglas McClendon wrote:
> Jeremy Katz wrote:
>> On Tue, 2007-09-18 at 15:48 -0500, Douglas McClendon wrote:
>>> Jeremy Katz wrote:
>>>> Although then the other question is what to do when we're not squashed.
>>>> Do we just then want to put it on the ext3fs?
>>> Here is the heart of something I think I mentioned that was wrong a
>>> long time ago.  I mentioned something like "osmin can't live on the
>>> squashfs for obvious reasons".  Actually, the truth is "osmin can't
>>> live on the ext3 for obvious reasons".  And the subtle error there
>>> kept the idea out of my mind.
>>
>> The simple answer is just don't do the osmin bits if you're not using
>> squashfs.  Given that it's a debug option only, that's probably not
>> crazy
> 
> Thats the answer to...?  to not having the --ignore-deleted and
> --turbo-liveinst options?  I agree.
> 
> One big problem with skip-compression as is, is that when the ext3 image
> lives natively on the iso9660
> 
> 1) iso9660 does not(?) support sparse files, so currently with your 4.0G
> ext3 image containing 2.2G of data, you have to store 4.0G data.
> 
> 2) iso9660 sortof has 2G filesize limits (apparently 2G->4.2G might
> work, and 4.2G->8TB could theoretically work...)
> 
> One possible solution for 1), might be to house the sparse file in a
> container filesystem (either squashfs, or a properly minimized ext2).
> 
> One possible solution for 2) would be to split the container filesystem
> (1.75G chunks?), and then associate a loop device with each, and use a
> devicemapper linear device to stitch them all together into one big image.

This sounds interesting, would is be possible to do something like have
a "base" image and add let's say a snapshot between gnome or kde and
"base" in a second image file? If that is possible, then using "base" in
place of stage2.img looks promising for a combined live/install/rescue
cdrom.

Thoughts anyone?

Jerry