Provided by: supermin_4.1.6-1_amd64 bug

NAME

       supermin - Tool for creating supermin appliances

SYNOPSIS

        supermin [-o OUTPUTDIR] --names LIST OF PKGS ...
        supermin [-o OUTPUTDIR] PKG FILE NAMES ...

DESCRIPTION

       Supermin is a tool for building supermin appliances.  These are tiny appliances (similar
       to virtual machines), usually around 100KB in size, which get fully instantiated on-the-
       fly in a fraction of a second when you need to boot one of them.

       Originally "fe" in "febootstrap" stood for "Fedora", but this tool is now distro-
       independent and can build supermin appliances for several popular Linux distros, and
       adding support for others is reasonably easy.  For this reason, starting with version 4,
       we have renamed the tool "supermin".

       Note that this manual page documents supermin 4.x which is a complete rewrite and quite
       different from febootstrap 2.x.  If you are looking for the febootstrap 2.x tools, then
       this is not the right place.

   BASIC OPERATION
       There are two modes for using supermin.  With the --names parameter, supermin takes a list
       of package names and creates a supermin appliance containing those packages and all
       dependencies that those packages require.  In this mode supermin usually needs network
       access because it may need to consult package repositories in order to work out
       dependencies and download packages.

       Without --names, supermin takes a list of packages (ie.  filenames of locally available
       packages).  This package set must be complete and consistent with no dependencies outside
       the set of packages you provide.  In this mode supermin does not require any network
       access.  It works by looking at the package files themselves.

       By "package" we mean the RPM, DEB, (etc.) package.  A package name might be the fully
       qualified name (eg. "coreutils-8.5-7.fc14.x86_64") or some abbreviation (eg. "coreutils").
       The precise format of the name and what abbreviations are allowed depends on the package
       manager.

       The supermin appliance that supermin writes consists of two files called "hostfiles" and
       "base.img" (see "SUPERMIN APPLIANCES" below).  By default these are written to the current
       directory.  If you specify the -o OUTPUTDIR option then these files are written to the
       named directory instead (traditionally this directory is named "supermin.d" but you can
       call it whatever you want).

       In all cases supermin can only build a supermin appliance which is identical in distro,
       version and architecture to the host.  It does not do cross-builds.

OPTIONS

       --help
           Display brief command line usage, and exit.

       --exclude REGEXP
           After doing dependency resolution, exclude packages which match the regular
           expression.

           This option is only used with --names, and it can be given multiple times on the
           command line.

       --names
           Provide a list of package names, instead of providing packages directly.  In this mode
           supermin may require network access.  See "BASIC OPERATION" above.

       --no-warnings
           Don't print warnings about packaging problems.

       -o outputdir
           Select the output directory where the two supermin appliance files are written
           ("hostfiles" and "base.img").  The default directory is the current directory.  Note
           that if this files exist already in the output directory then they will be
           overwritten.

       --packager-config CONFIGFILE
           Set the configuration file for the package manager.  This allows you to specify
           alternate software repositories.

           For ArchLinux, this sets the pacman configuration file (default "/etc/pacman.conf").
           See pacman.conf(5).

           For Yum/RPM distributions, this sets the yum configuration file (default
           "/etc/yum.conf").  See yum.conf(5).

       --save-temps
           Don't remove temporary files and directories on exit.  This is useful for debugging.

       --use-installed
           If packages are already installed, use the contents (from the local filesystem)
           instead of downloading them.

           Note that this can cause malformed appliances if local files have been changed from
           what was originally in the package.  This is particularly a problem for configuration
           files.

           However this option is useful in some controlled situations: for example when using
           supermin inside a freshly installed chroot.

       -v
       --verbose
           Enable verbose messages.

       -V
       --version
           Print the package name and version number, and exit.

       --yum-config CONFIGFILE
           This is a deprecated alias for --packager-config CONFIGFILE.

SUPERMIN APPLIANCES

       Supermin appliances consist of just enough information to be able to build an appliance
       containing the same operating system (Linux version, distro, release etc) as the host OS.
       Since the host and appliance share many common files such as "/bin/bash" and
       "/lib/libc.so" there is no reason to ship these files in the appliance.  They can simply
       be read from the host on demand when the appliance is launched.  Therefore to save space
       we just store the names of the host files that we want.

       There are some files which cannot just be copied from the host in this way.  These include
       configuration files which the host admin might have edited.  So along with the list of
       host files, we also store a skeleton base image which contains these files and the outline
       directory structure.

       Therefore the supermin appliance normally consists of at least two control files:

       hostfiles
           The list of files that are to be copied from the host.  This is a plain text file with
           one pathname per line.  Directories are included in this file.

           Paths can contain wildcards, which are expanded when the appliance is created, eg:

            /etc/yum.repos.d/*.repo

           would copy all of the "*.repo" files into the appliance.

           Each pathname in the file should start with a "/" character.  (In older versions of
           febootstrap, paths started with "./" and were relative to the root directory, but you
           should not do that in new files).

       base.img
           This uncompressed cpio file contains the skeleton filesystem.  Mostly it contains
           directories and a few configuration files.

           All paths in the cpio file should be relative to the root directory of the appliance.

           Note that unlike "hostfiles", paths and directories in the base image don't need to
           have any relationship to the host filesystem.

       base.img.gz
           Since supermin ≥ 4.1.4, any cpio image files may be gzip-compressed to save disk
           space.  "hostfiles" cannot be compressed.  The supermin program won't create these
           files.  You need to compress the output yourself, eg by doing:

            gzip -9 supermin.d/*.img

   RECONSTRUCTING THE APPLIANCE
       The separate tool supermin-helper(1) is used to reconstruct an appliance from the
       hostfiles and base image files.

       This program in fact iterates recursively over the files and directories passed to it.  A
       common layout is:

        supermin.d/
        supermin.d/base.img
        supermin.d/extra.img
        supermin.d/hostfiles

       and then invoking supermin-helper with just the "supermin.d" directory path as an
       argument.

       In this way extra files can be added to the appliance just by creating another cpio file
       ("extra.img" in the example above) and dropping it into the directory.  When the appliance
       is constructed, the extra files will appear in the appliance.

       DIRECTORIES BEFORE FILES

       In order for supermin-helper to run quickly, it does not know how to create directories
       automatically.  Inside hostfiles and the cpio files, directories must be specified before
       any files that they contain.  For example:

        /usr
        /usr/sbin
        /usr/sbin/serviced

       It is fine to list the same directory name multiple times.

       LEXICOGRAPHICAL ORDER

       supermin-helper visits the supermin control files in lexicographical order.  Thus in the
       example above, in the order "base.img" -> "extra.img" -> "hostfiles".

       This has an important effect: files contained in later cpio files overwrite earlier files,
       and directories do not need to be specified if they have already been created in earlier
       control files.

       EXAMPLE OF CREATING EXTRA CPIO FILE

       You can create a file like "extra.img" very easily using a shell snippet similar to this
       one:

        cd $tmpdir
        mkdir -p usr/sbin
        cp /path/to/serviced usr/sbin/
        echo -e "usr\nusr/sbin\nusr/sbin/serviced" |
          cpio --quiet -o -H newc > extra.img
        rm -rf usr

       Notice how we instruct cpio to create intermediate directories.

   MINIMIZING THE SUPERMIN APPLIANCE
       You may want to "minimize" the supermin appliance in order to save time and space when it
       is instantiated.  Typically you might want to remove documentation, info files, man pages
       and locales.  We used to provide a separate tool called "febootstrap-minimize" for this
       purpose, but it is no longer provided.  Instead you can post-process "hostfiles" yourself
       to remove any files or directories that you don't want (by removing lines from the file).
       Be careful what you remove because files may be necessary for correct operation of the
       appliance.

       For example:

        < supermin.d/hostfiles \
        grep -v '^/usr/share/man/' |
        grep -v '^/usr/share/doc/' |
        grep -v '^/usr/share/info/' > supermin.d/hostfiles-t
        mv supermin.d/hostfiles-t supermin.d/hostfiles

   KERNEL AND KERNEL MODULES
       Usually the kernel and kernel modules are not included in the supermin appliance.  When
       the appliance is instantiated, the kernel modules from the host kernel are copied in, and
       it is booted using the host kernel.

       supermin-helper is able to choose the best host kernel available to boot the appliance.
       Users can override this by setting environment variables (see supermin-helper(1)).

   BOOTING AND CACHING THE SUPERMIN APPLIANCE
       For fastest boot times you should cache the output of supermin-helper.  See the libguestfs
       source file "src/appliance.c" for an example of how this is done.

   ENFORCING AVAILABILITY OF HOSTFILES
       supermin-helper builds the appliance by copying in host files as listed in "hostfiles".
       For this to work those host files must be available.  We usually enforce this by adding
       requirements (eg. RPM "Requires:" lines) on the package that uses the supermin appliance,
       so that package cannot be installed without pulling in the dependent packages and thus
       making sure the host files are available.

SEE ALSO

       supermin-helper(1), <http://people.redhat.com/~rjones/supermin/>, guestfs(3),
       <http://libguestfs.org/>.

AUTHORS

       •   Richard W.M. Jones <http://people.redhat.com/~rjones/>

       •   Matthew Booth mbooth@redhat.com

COPYRIGHT

       Copyright (C) 2009-2011 Red Hat Inc.

       This program is free software; you can redistribute it and/or modify it under the terms of
       the GNU General Public License as published by the Free Software Foundation; either
       version 2 of the License, or (at your option) any later version.

       This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
       without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
       See the GNU General Public License for more details.

       You should have received a copy of the GNU General Public License along with this program;
       if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
       USA.