This adds the 'squashfs' compression type, which builds runtime images
that stay compressed in RAM. It accomplishes this by building the images
almost exactly like the Live images are built:
1) Create an empty ext4 filesystem on a large sparse file
2) Copy the runtime files into the ext4 filesystem
3) Place the ext4 image at "LiveOS/rootfs.img"
4) Create a squashfs.img which contains LiveOS/rootfs.img
To make this bootable, we need dracut's startup scripts. So before
creating the runtime image, we make a dracut initramfs.img by chrooting
into the runtime and running dracut.
Finally, we add squashfs.img to initramfs.img, along with an extra file
(/etc/cmdline) which directs dracut to use /squashfs.img as its root
device. And there we go! Easy, right?!
This makes the compression code slightly more generic:
- [compression] "speed" config item renamed to "args"
- default changed from "9" to "-9"
- "cspeed" variables renamed "cargs"
- pass "args.split()" on compress cmdline instead of "-%s" % speed
If you're doing e.g. an i386 build an an x86_64 build at the same time,
you wind up deadlocking the dmsetup processes in sys_semtimedop()
because they have the same name between the two codepaths. This is
probbaly a dmsetup bug, but even if it weren't, you'd still have two
composes trying to use the same dm devices, and that's bad. Instead,
stick the pid in the names.
We're already using find and cpio subprocesses, so using
one more subprocess is not a problem. With this approach
we can pipe cpio to the xz/gzip command, which should
help with the memory issues.
A python lib we use (python-value_key) depends on this. If it fails to
import the module we see weird problems importing python modules backed up
by .so libraries, for instance:
ImportError: /lib64/libcryptsetup.so.1: undefined symbol: uuid_generate
Related: rhbz#684742
