Lorax is a set of tools used to create bootable images.
5155ff65ac
I originally added --add-template to support doing something similar to pungi, which injects content into the system to be used by default. However, this causes the content to be part of the squashfs, which means PXE installations have to download significantly more data that they may not need (if they actually want to pull the tree data from the network, which is not an unusual case). What I actually need is to be able to modify *both* the runtime image and the arch-specific content. For the runtime, I need to change /usr/share/anaconda/interactive-defaults.ks to point to the new content. (Although, potentially we could patch Anaconda itself to auto-detect an ostree repository configured in disk image, similar to what it does for yum repositories) For the arch-specfic image, I want to drop my content into the ISO root. So this patch adds --add-arch-template and --add-arch-template-var in order to do the latter, while preserving the --add-template to affect the runtime image. Further, the templates will automatically graft in a directory named "iso-graft/" from the working directory (if it exists). (I suggest that external templates create a subdirectory named "content" to avoid clashes with any future lorax work) Thus, this will be used by the Atomic Host lorax templates to inject content/repo, but could be used by e.g. pungi to add content/rpms as well. I tried to avoid code deduplication by creating a new template for the product.img bits and this, but that broke because the parent boot.iso code needs access to the `${imggraft}` variable. I think a real fix here would involve turning the product.img, content/, *and* boot.iso into a new template. Conflicts: src/sbin/lorax |
||
---|---|---|
docs | ||
etc | ||
rel-eng | ||
share | ||
src | ||
tests | ||
utils | ||
.gitignore | ||
ANNOUNCE | ||
AUTHORS | ||
COPYING | ||
lorax.spec | ||
Makefile | ||
POLICY | ||
README | ||
README.livemedia-creator | ||
README.product | ||
setup.py | ||
TODO |
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>