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

[Douglas McClendon]

Jerry Vonau wrote:
> 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?

I think you are thinking more here about devicemapper snapshot devices. 
  I was talking about something that just split up one logical 
filesystem into parts that needed to all be put back together before 
having something useful.

But yes, one could do something like like that with snapshot devices. 
But I think there is an easier way to get what you described.

If you just took the existing livecd image, and copied the contents of 
the traditional installer DVD into it (either the whole iso, or just the 
/Fedora (or /Packages if its called that now) directory).  Then you 
could have a boot argument, which would be used in place of the existing 
'live' boot argument, say 'installer'.  Then where the current 'live' 
argument is detected, it would detect 'installer', and run an 
environment like the stage2 that you are thinking of.

But, I have pondered other similar uses of snapshots which are very much 
like what you suggested.  One thing you could do, is have the base, and 
then a snapshot for the gnome livecd, a different snapshot for the kde 
livecd, another for FEL and development, etc...  and then at the boot 
menu, let the user choose which spin to boot up, and at install time, 
let the user choose which spin to install.  Of course this mostly makes 
sense for a LiveDVD where you have that kind of room to spare.  But 
there may be better ways to get the same functionality without using 
dm-snapshots.

$0.02...

-dmc