[Libguestfs] working on docker images and image building... what can we learn from supermin?

Richard W.M. Jones rjones at redhat.com
Tue Mar 25 15:47:17 UTC 2014


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/




More information about the Libguestfs mailing list