Lorax is a set of tools used to create bootable images.
c9582a0468
The problem this solves is that yum really isn't designed to be part of\ a long running daemon. So when repodata changes upstream, even when you force it to download the new metadata, it doesn't change in memory so you end up with lorax-composer depsolving against old versions, and anaconda depsolving against new versions (because it sets up its own YumBase and cache) and then the kickstart is no longer valid. To solve this I have - Added a 6h timeout to the metadata check (because yum's doesn't work in this situation). - Added a metadata check to the YumLock .lock property, but only when the timeout expires. - Added a new .lock_check property to YumLock that always checks the metadata and resets the timeout. If it has changed it does its best to tear down the existing YumBase, deleting as much as it can in hopes it doesn't leak memory. And then it sets up a totally new YumBase with the new repodata. Resolves: rhbz#1632962 |
||
---|---|---|
docs | ||
etc | ||
rel-eng | ||
share | ||
src | ||
systemd | ||
tests | ||
utils | ||
.coveragerc | ||
.dockerignore | ||
.gitignore | ||
.travis.yml | ||
ANNOUNCE | ||
AUTHORS | ||
COPYING | ||
Dockerfile.test | ||
epel.repo | ||
lorax-composer.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>