Lorax is a set of tools used to create bootable images.
81ce55a1e5
If systemd's tmpfiles.d timer is executed while lorax is running it will remove any files and directories older than 30 days. This is what has been causing the occasional error where /proc/ would seem to vanish during the install. Upstream has proposed this solution, https://github.com/systemd/systemd/pull/11482 but until that is released we need a work-around to protect the lorax files. This commit does several things: * Move the default tmpdir from /var/tmp/ to /var/tmp/lorax/ * Add a lorax.conf tmpfiles.d file that prevents systemd-tmpfiles from removing anything under /var/tmp/lorax/ * Add an exit handler to lorax so that temporary directories are removed on exit or on a python traceback. * Use flock to lock access to the tempdir while lorax is running. * Remove any unlocked tempdirs named /var/tmp/lorax/lorax.* at startup Note that the exit handler will not remove the tempdir if lorax is killed with a signal -- those are being caught by dnf and prevent the exit handler from running. systemd-tmpfiles cannot clean up the tempdirs at boot time because they contain files labeled as shadow_t, so we have to remove those when lorax runs. It uses the flock to prevent removing any directories created by parallel instances of lorax and only removes ones that are unlocked. Worst case they will be around until the first run of lorax after a reboot. If you want to keep the working directory around for debugging purposes use --workdir /var/tmp/lorax/my-workdir and it won't be removed by lorax. Resolves: rhbz#1668520 |
||
|---|---|---|
| docs | ||
| etc | ||
| rel-eng | ||
| share | ||
| src | ||
| systemd | ||
| tests | ||
| utils | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .travis.yml | ||
| ANNOUNCE | ||
| AUTHORS | ||
| COPYING | ||
| Dockerfile.test | ||
| epel.repo | ||
| 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>