On Tue, Mar 25, 2014 at 10:57:35AM -0400, Matthew Miller wrote:

$SUBJECT, basically. :)

Chroots, my favorite subject! Debian has a great tool called debootstrap. You use it like this: (1) Stick a disk / SD card into another Debian machine. (2) Create a filesystem on the external disk. (3) Run `debootstrap /mnt'. And presto you have a second Debian system on the external disk. It would be nice if such a thing existed for Fedora too, and to that end, about 5 years ago, I wrote a tool called 'febootstrap' which did essentially that. Mind you, there were a few problems with febootstrap. It was just a wrapper around 'yum --installroot', and like yum, it required you to run it as root. However running it as root has several unexpected issues: - It stops you from running it in places where root is not permitted (eg. 'make', Koji). - Because 'yum --installroot' and rpm isn't really tested in this configuration, rpm %post scripts could do dazzling things to your host system, like killing daemons. As there is no reason why yum or rpm really has to run as root, we tried to make 'yum' work without root. We ran yum/rpm under 'fakeroot' + 'fakechroot'. [If you check out the source for febootstrap 2.x (ships in RHEL 6) this is what you're getting.] Unfortunately fake{,ch}root don't work very well. They are LD_PRELOAD hacks which means they fail on static binaries, of which (we found out the hard way) several exist and are run by %post scripts. Also they are kind of buggy. So we abandoned this approach, and also renamed febootstrap as supermin (because a lot of people thought that febootstrap should work like debootstrap and/or was something to do with how Fedora "bootstraps" itself -- neither is true). Supermin works completely differently, but supermin 5 still lets you build chroots. If you have supermin 5 installed, try doing this (as NON-root): cd /tmp supermin -v --prepare bash coreutils -o appliance.d supermin -v --build -f chroot appliance.d -o root ls -l /tmp/root/ Wow, a Fedora chroot! How does that work? - It takes the list of packages you specify on the command line (which must also be installed on the host). - It use rpm commands to resolve the dependencies. - It looks up the files used by those RPMs. - It copies those files into the chroot (or into an ext4 disk image if you're building a libguestfs appliance). - Configuration files are handled a bit differently. See the supermin(1) man page for an explanation. - Neither step requires the network (but you have to add the --use-installed option). Actually this works on Debian too (and other distros), since supermin has a package manager abstraction. One caveat: supermin ignores %post scripts. I happen to believe that we should be minimizing the use of scripts in RPMs, because they essentially do magic which is outside the control of RPM. However if you don't like that argument, you can do: rpm -q --scripts [list of packages] and then examine what changes are actually being done by your packages, and emulate them in your guest. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/