multistrap [-a ARCH] [-d DIR] -f CONFIG_FILE
     multistrap [--simulate] -f CONFIG_FILE
     multistrap -?|-h|--help|--version



multistrap provides a debootstrap-like method based on apt and extended to provide support for multiple repositories, using a configuration file to specify the relevant suites, architecture, extra packages and the mirror to use for each bootstrap.

The aim is to create a complete bootstrap / root filesystem with all packages installed and configured, instead of just the base system.

Example configuration:

     # same as --tidy-up option if set to true
     # same as --no-auth option if set to true
     # keyring packages listed in each bootstrap will
     # still be installed.
     # extract all downloaded archives (default is true)
     # whether to add the /suite to be explicit about where apt
     # needs to look for packages. Default is false.
     # aptsources is a list of sections to be used
     # the /etc/apt/sources.list.d/multistrap.sources.list
     # of the target. Order is not important
     # the bootstrap option determines which repository
     # is used to calculate the list of Priority: required packages
     # and which packages go into the rootfs.
     # The order of sections is not important.

This will result in a completely normal debootstrap of Debian lenny from the specified mirror, for armel in '/opt/multistrap/'. (This configuration is retained in the package as /usr/share/multistrap/lenny.conf)

Specify a package to extend the multistrap to include that package and all dependencies of that package.

Specify more repositories for the bootstrap by adding new sections. Section names need to be listed in the bootstrap general option for the packages to be included in the bootstrap.

Specify which repositories will be available to the final system at boot by listing the section names in the aptsources general option, e.g. to exclude some internal sources or when using a local mirror when building the rootfs.

Section names are case-insensitive.

All dependencies are resolved only by apt, using all bootstrap repositories, to use only the most recent and most suitable dependencies. Note that multistrap turns off Install-Recommends so if the multistrap needs a package that is only a Recommended dependency, the recommended package needs to be specified in the packages line explicitly. See "Explicit suite specification" for more information on getting specific packages from specific suites.

'Architecture' and 'directory' can be overridden on the command line. Some other general options also have command line options.


"aptsources" lists the sections which should be used to create the /etc/apt/sources.list.d/multistrap.list apt sources in the final system. Not all "aptsources" have to appear in the "bootstrap" section if you have some internal or local sources which are not accessible to the installed root filesystem.

"bootstrap" lists the sections which will be used to create the multistrap itself. Only packages listed in "bootstrap" will be downloaded and unpacked by multistrap.

Make sure "bootstrap" lists all sections you need for apt to be able to find all the packages to be unpacked for the multistrap.

(Older versions of multistrap supported the same option under the "debootstrap" name - this spelling is still supported but new configuration files should be "bootstrap" instead.

General settings:

'arch' can be overridden on the command line using the "--arch" option.

'directory' specifies the top level directory where the bootstrap will be created - it is not packed into a .tgz once complete.

'bootstrap' lists the Sections which will be used to specify the packages which will be downloaded (and optionally unpacked) into the bootstrap.

'aptsources' lists the Sections which will be used to specify the apt sources in the final system, e.g. if you need to use a local repository to generate the rootfs which will not be available to the device at runtime, list that section in "bootstrap" but not in "aptsources".

If you want a package to be in the rootfs, it must be specified in the "bootstrap" list under General.

The order of section names in either list is not important.

As with debootstrap, multistrap will continue after errors, as long as the configuration file can be correctly parsed.

multistrap also implements the machine:variant support originally used in Emdebian Crush, although in a different implementation. Using the cascading configuration support, particular machine:variant combinations can be supported by simple changes on the command line.

Setting "tarballname" to true also packs up the final filesystem into a tarball.

Note that multistrap ignores any unrecognised options in the config file - this allows for backwards-compatible behaviour as well as overloading the multistrap config files to support other tools (like pbuilder). Use the "--simulate" option to see the combined configuration settings.

However, if the config file itself cannot be parsed, multistrap will abort. Check that the config file has a key and a value for each line, other than comments. Values must all on the same line as the key.

Section settings


The section name (in [] brackets) needs to be unique for this configuration file and any configuration files which this file includes. Section names are case insensitive (all comparisons happen after conversion to lower case).

'packages' is the list of packages to be added when this Section is listed in "bootstrap" - all package names must be listed on a single line or the file will fail to parse. One alternative is to define your list of packages as multiple groups with packages separated on a functional / dependency basis, e.g. base, Xorg, networking etc. and list each group under 'bootstrap'.

     bootstrap=base networking

     packages=udev mtd-utils

     packages=netbase ifupdown iproute net-tools samba

As a special case, "multistrap" also supports multiple packages keys per section, one line for each. Other keys cannot be repeated in this manner.

     packages=udev mtd-utils netbase ifupdown iproute
     packages=busybox net-tools samba

'source' is the apt source to use for this Section. (To use a local source on the same machine, ensure you use "copy://" not "file://", so that apt is told to copy the packages into the rootfs instead of assuming it can try to download them later - because that "later" will never actually happen.

'keyring' lists the package which contains the key used by the source listed in this Section. If no keyring is specified, the "noauth" option must be set to true. See Secure Apt.

'suite' is the suite to use from this source. Note that this must be the suite, not the codename.

Suites change from time to time: (oldstable, stable, testing, sid) The codename (etch, lenny, squeeze, sid) does not change.

Secure Apt

To use authenticated apt repositories, multistrap needs to be able to install an appropriate keyring package from the existing apt sources outside the multistrap environment into the destination system. Unfortunately, keyring packages cannot be downloaded from the repositories specified in the multistrap configuration - this is because "apt" needs the keyring to be updated before being able to use repositories not previously known.

If relevant packages exist, specify them in the 'keyring' option for each repository. multistrap will then check that apt has already installed this package so that the repository can be authenticated before any packages are downloaded from it.

Note that all repositories to be used with multistrap must be authenticated or apt will fail. Similarly, secure apt can only be disabled for all repositories (by using the --no-auth command line option or setting the general noauth option in the configuration file), even if only one repository does not have a suitable keyring available.

The keyring package(s) will also be installed inside the multistrap environment to match the installed apt sources for the multistrap.


multistrap is stateless - if the directory exists, it will simply proceed as normal and apt will try to pick up where it left off.

Root Filesystem Configuration

multistrap unpacks the downloaded packages but other stages of system configuration are not attempted. Examples include:


Any device-specific device nodes will also need to be created using MAKEDEV or "" - a helper script that can work around some of the issues with MAKEDEV. requires a device table file along the lines of the one in the mtd-utils source package. See /usr/share/doc/multistrap/examples/device_table.txt

Once multistrap has successfully created the basic file and directory layout, other device-specific scripts are needed before the filesystem can be packaged up and installed onto the target device.

Once installed, the packages themselves need to be configured using the package maintainer scripts and "dpkg --configure -a", unless this is a native multistrap.

For "dpkg" to work, /proc and /sysfs must be mounted (or mountable), /dev/pts is also recommended.

See also:


To configure the unpacked packages (whether in native or cross mode), certain environment variables are needed:

Debconf needs to be told to accept that user interaction is not desired:

Perl needs to be told to accept that no locales are available inside the chroot and not to complain:

Then, dpkg can configure the packages:

at a login shell:

     # export LC_ALL=C LANGUAGE=C LANG=C 
     # dpkg --configure -a

(As above, dpkg needs /proc and /sysfs mounted first.)

Native mode - multistrap

multistrap was not intended for native support, it was developed for cross architecture support. In order for multiple repositories to be used, multistrap only unpacks the packages selected by apt.

In native mode, various post-multistrap operations are likely to be needed that debootstrap would do for you:

  1. copy /etc/hosts into the chroot
  2. clean the environment to unset LANGUAGE, LC_ALL and LANG to silence nuisance perl warnings that obscure other errors

(An alternative to unset the localisation variables is to add locales to your multistrap configuration file in the 'packages' option.

A native multistrap can be used directly with chroot, so "multistrap" runs "dpkg --configure -a" at the end of the multistrap process.

Cascading configuration

To support multiple variants of a basic (common) configuration, "multistrap" allows configuration files to include other (more general) configuration files. i.e. the most detailed / specific configuration file is specified on the command line and that file includes another file which is shared by other configurations.

Base file:


Specifying just the armel.conf file will get the rest of the settings from crosschroot.conf so that common changes only need to be made in a single file.

It is strongly recommended that any changes to the configuration files involved in any particular cascade are tested using the "--simulate" option to multistrap which will output a summary of the options that have been set once the cascade is complete. Note that multistrap does not warn you if a configuration file contains an unrecognised option (for future compatibility with backported configurations), so a simple typo can result in an option not being set.

Machine:variant support

The old packages.conf variables from emsandbox can all be converted into "multistrap" configuration variables. The machine:variant support in "multistrap" concentrates on the scripts, and

Once "multistrap" has unpacked the downloaded packages, the "" can be called, passing the location and architecture of the root filesystem, so that other fine tuning can take place. At this stage, any operations inside the rootfs must not try to execute any binaries within the rootfs. As the final stage of the multistrap process, "" is copied into the root directory of the rootfs.

One advantage of using machine:variant support is that the entire rootfilesystem can be managed by a single call to multistrap - this is useful when building root filesystems in userspace.

To enable machine:variant support, specify the path to the scripts to be called in the variant configuration file (General section):


Restricting package selection

"multistrap" includes Required packages by default, the current list of packages can be seen using:

     grep-available  -FPriority 'required' -sPackage

If the OmitRequired option is set to true, these packages will not be added - whilst useful, this option can easily lead to a useless rootfs. Only the packages specified manually in the configuration files will be used in the calculations - dependencies of those packages will be added but no others.

Packages with Priority: important or standard are never included by "multistrap" unless specifically included in a "packages=" option in a section specified in the "bootstrap" general option.

Recommends behaviour

The Debian default behaviour after the Lenny release was to consider recommended packages as extra packages to be installed when any one package is selected. Recommended packages are those which the maintainer considers that would be present on "most" installations of that package and allowing Recommends means allowing Recommends of recommended packages and so on.

The multistrap default is to turn recommends OFF.

Set the allowrecommends option to true in the General section to use typical Debian behaviour.

Explicit suite specification

Sometimes, apt needs to be told to get a particular package from a particular suite, ignoring a more recent version in another suite in the same set of sources.

"multistrap" can operate with and without the explicit suite option, the default is to let apt use the most recent version from the collection of specified bootstrap sources.

Explicit suite specification has no effect on the final installed system - if your aptsources includes a repository which in turn includes a newer version of the package(s) specified explicitly, the next "apt-get upgrade" on the device will bring in the newer version.

Also, when specifying packages to get from a specific suite, apt will also try and ensure that the dependencies for that package are also from the same suite and this can cause apt to be unable to resolve the complete set of dependencies. In this situation, being explicit about one package selection may require being explicit about some (not necessarily all) of the dependencies of that package as well.

When using this support in Lenny, ensure that each section uses the suite (oldstable, stable, testing, sid) and not the codename (etch, lenny, squeeze, sid) in the "suite" configuration item as the version of apt in Lenny and previous cannot use the codename.

To test, on Lenny, try:

Compare with

When using explicitsuite, take care in using stable-proposed-updates or other temporary locations - if the package migrates into another suite and is removed from the temporary suite (as with *-proposed-updates), multistrap will not be able to find the package.

Omitting deb-src listings

Some multistrap environments do not need access to the Debian sources of packages being installed, typically this is required when preparing a build (or cross-build) chroot using multistrap.

To turn off this additional source (and save both download time and apt-cache size), use the omitdebsrc field in each Section.


omitdebsrc is necessary when using packages from debian-ports where packages do not have sources, except "unreleased".


Foreign architecture bootstraps can operate under "fakeroot" ("multistrap" is designed to do as much as it can within a single call to make this easier) but the configuration stage which normally happens with a native architecture bootstrap requires "chroot" and "chroot" itself will not operate under "fakeroot".

Therefore, if "multistrap" detects that "fakeroot" is in use, native mode configuration is skipped with a reminder warning.

The same problem applies to "apt-get install" and therefore the installation of the keyring package on the host system is also skipped if fakeroot is detected.

Handling problematic packages

Sometimes, a particular package will fail to even unpack properly if other packages have not already been unpacked. This can happen if dpkg diversions are not setup correctly or if the package Pre-Depends on an executable in another package.

Multistrap offers two ways to handle these problems. A package can be listed as "reinstall" or as "additional". Each section in the "multistrap" configuration file can have a single "reinstall" or "additional" listing or both.

Reinstall means that the package will be downloaded and unpacked as normal - alongside all the other packages, but will then be reinstalled at the end by running the "preinst" maintainer script with the "upgrade" argument. "dpkg" will then continue the rest of the configuration of that package.

Additional adds a second round of "apt-get install" to the multistrap process - after the initial unpacking. The additional package will then be downloaded and unpacked. If running natively, the additional package is downloaded, unpacked and configured after all the rest of the packages have been downloaded, unpacked and configured.

Neither "reinstall" nor "additional" should be seen as more than just workarounds and wishlist bugs should be filed in Debian against packages which require the use of these mechanisms (or the packages which would prevent the particular package from operating normally).


"multistrap" can produce a lot of output - informational messages appear on STDOUT, errors and warnings on STDERR. Calls to "apt" and "dpkg" respect the same pattern, so it is simple to trim the combined "multistrap" output to just the errors, if desired.


As "multistrap" gets more complex, bugs will creep into the package. Please report all bugs to the Debian BTS using the "reportbug" tool and please attach all configuration files. If your configuration needs to access local or private apt repositories, please check your configuration with the latest version of "multistrap" in Debian using the "--simulate" option and include that report in your bug report.

The "--simulate" option output is regularly expanded to help users debug problems in the configuration files.

Please also check (and update) the Multistrap wiki at and the Multistrap webpage content at before filing bugs. Various people on the debian- mailing list and #emdebian IRC channel on can also help if your config file does not parse correctly. You would need to put the "--simulate" output on a pastebin website and put the URL in your message.