I've been flat on my back for a while, so if I repeat anything previously sad, apologies.

I've got a kickstart that is used to create a two partition solution on a 1G flash device.  On the code side, I use a number of shell scripts.  But, the main thing that makes is work is that I use a directory structure that looks like this

project
    - files/
    - partition_2/
    - kickstart file

files holds various odds & ends (some custom rpms, some specific files, etc).  partition_2 holds all the stuff I want on the second partion.  I then have a simple script that backbones the livecd creation process and a second script that bundles up everything in the partition 2 directory as another iso.  When I'm ready to burn the stuff to flash, I run a second script that handles the partitioning, writes the livecd to the first partition and the partition_2 iso's contents to the second partition.

Mark, if this sounds helpful, I'd be happy to tar/zip the scripts in question with some basic directions.  If the person who created the livecd creation tool (sorry ... I've forgotten your name and I seem to have accidently deleted the email) is interested, I could turn it into an rpm that could become part of that kickstart.

Tim


Mark McLoughlin wrote: 
On Wed, 2008-05-28 at 14:36 -0400, Jeremy Katz wrote:
  
The ability for a tool to create these partitioned disk images via the
command like, livecd-creator, is very helpful in reproducing known state
appliances, epically with the rising use of visualization.  Going
through a actual install in a vm limits you to VM container, xen, kvm,
vmware and adds extra overhead of building on a machine with extra virt
resources.  
      
Reproducing known state should work just as well with a kickstart config 
and doing an install via, eg, virt-install.  Yes, it adds overhead, but 
there are also advantages in functionality and it also means *not* 
maintaining this sort of code in multiple places.  And that's a pretty 
big win as partitioning code is not in the least bit trivial. 
Especially as you start trying to handle more and more of the cases.
    

That pretty lame - you're trying to curtail what use cases people make
imgcreate support purely because we haven't figured out how to do a
better job of sharing code with anaconda.

The very least we should be doing is allowing imgcreate to be extended
externally in this manner ... but that doesn't fix the "multiple copies
of this code" issue, it merely pushes it elsewhere and makes it less
likely it'll ever be fixed.

Clearly, one advantage of imgcreate tools over a full blown anaconda
install in a VM is that it's far less complex to debug when it all goes
wrong. That's a huge advantage to people repeatedly rebuilding images as
they develop a LiveCD or an appliance.

Cheers,
Mark.

--
Fedora-livecd-list mailing list
Fedora-livecd-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

  


-- 
_________________________________
Tim Wood, CLP, RHCT
719.338.7484 (tel)

The Data Wranglers
Web, Database & more since    since 1994
www.datawranglers.com