Lorax is a set of tools used to create bootable images.
Go to file
Will Woods 86937d2c0a ppc.tmpl: clarify comments, fix yaboot.conf for Apple systems
So there's actually two copies of yaboot on a PPC image, and they each
use different config files:

  ppc/chrp/yaboot --> /etc/yaboot.conf
  ppc/mac/yaboot  --> /ppc/ppc{32,64}/yaboot.conf

So we need two copies of yaboot.conf - one in each place - to
boot properly (or all three if we're making hybrid images). Whee!

The comments should now make this more clear for future reference.
2011-11-16 15:17:39 -05:00
etc Remove empty config files 2010-12-08 12:40:46 +01:00
share ppc.tmpl: clarify comments, fix yaboot.conf for Apple systems 2011-11-16 15:17:39 -05:00
src ltmpl: be more careful about checking command names 2011-11-04 13:41:10 -04:00
utils fix udev vs. udev_escape in test-parse-template 2011-11-11 14:10:07 -05:00
.gitignore give version.py its own makefile rule and .gitignore line 2011-10-24 19:01:21 -04:00
ANNOUNCE Added draft on initial announce email as I keep adding to it. 2008-10-06 09:51:01 -10:00
AUTHORS add wwoods to AUTHORS 2011-10-26 12:36:06 -04:00
COPYING Initial project description files imported. 2008-09-11 14:16:39 -10:00
lorax.spec add mkefiboot to lorax.spec 2011-11-04 13:36:37 -04:00
Makefile give version.py its own makefile rule and .gitignore line 2011-10-24 19:01:21 -04:00
POLICY Update the POLICY file. 2008-10-03 15:45:33 -10:00
README Initial project description files imported. 2008-09-11 14:16:39 -10:00
setup.py Write the lorax verion in the .buildstamp (#689697) 2011-10-24 16:07:25 -04:00
TODO Update TODO list. 2009-04-06 09:54:22 -10:00

I am the Lorax.  I speak for the trees [and images].

Tree building tools such as pungi and revisor rely on 'buildinstall' in
anaconda/scripts/ to produce the boot images and other such control files
in the final tree.  The existing buildinstall scripts written in a mix of
bash and Python are unmaintainable.  Lorax is an attempt to replace them
with something more flexible.


EXISTING WORKFLOW:

pungi and other tools call scripts/buildinstall, which in turn call other
scripts to do the image building and data generation.  Here's how it
currently looks:

   -> buildinstall
       * process command line options
       * write temporary yum.conf to point to correct repo
       * find anaconda release RPM
       * unpack RPM, pull in those versions of upd-instroot, mk-images,
         maketreeinfo.py, makestamp.py, and buildinstall

       -> call upd-instroot

       -> call maketreeinfo.py

       -> call mk-images (which figures out which mk-images.ARCH to call)

       -> call makestamp.py

       * clean up


PROBLEMS:

The existing workflow presents some problems with maintaining the scripts.
First, almost all knowledge of what goes in to the stage 1 and stage 2
images lives in upd-instroot.  The mk-images* scripts copy things from the
root created by upd-instroot in order to build the stage 1 image, though
it's not completely clear from reading the scripts.


NEW IDEAS:

Create a new central driver with all information living in Python modules.
Configuration files will provide the knowledge previously contained in the
upd-instroot and mk-images* scripts.


-- 
David Cantrell <dcantrell@redhat.com>