Provided by: multistrap_2.1.6ubuntu3_all bug


       multistrap - multiple repository bootstraps


       multistrap [-a ARCH] [-d REPERTOIRE] -f FICHIER_CONFIG multistrap
       [--simulate] -f FICHIER_CONFIG multistrap -?|-h|--help|--version


       -?|-h|--help|--version - output the help text and exit successfully.

       --dry-run - examine tous les parametres de configuration et genere un
       bref sommaire.

       --simulate - identique a --dry-run

       (Les options suivantes peuvent egalement etre definies dans le fichier
       de configuration.)

       -a|--arch - architecture of the packages to put into the multistrap.

       -d|--dir - directory into which the bootstrap will be installed.

       -f|--file - configuration file for multistrap [required]

       --tidy-up - supprimer les donnees du cache d'apt, les fichiers Packages
       telecharges et le cache des paquets apt. Identique a cleanup=true.

       --no-auth - autoriser l'utilisation de depots non authentifies.
       Identique a noauth=true

       --source-dir DIR - move the contents of var/cache/apt/archives/ from
       inside the chroot to the specified external directory, then add the
       Debian source packages for each used binary. Same as retainsources=DIR
       If the specified directory does not exist, nothing is done. Requires
       --tidy-up in order to calculate the full list of source packages,
       including dependencies.


       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.

       Le but est de creer un systeme de fichiers racine / bootstrap complet
       avec tous les paquets installes et configures, plutot que de creer
       uniquement le systeme de base.

       Exemple de 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

       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.

       La casse des lettres n'est pas importante dans les noms de section.

       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" liste les sections qui devraient etre utilisees pour creer
       le /etc/apt/sources.list.d/multistrap.list apt sources du systeme
       final. Tous les "aptsources" ne doivent pas obligatoirement apparaitre
       dans la section "bootstrap" s'il y a des sources internes ou locales
       inaccessible par le systeme de fichiers racine installe.

       "bootstrap" liste les sections qui seront utilisees pour creer le
       multistrap lui-meme. Seul les paquets listes dans "bootstrap" seront
       telecharges et depaquetes par multistrap.

       Il faut s'assurer que "bootstrap" liste toutes les sections necessaires
       afin que apt puisse trouver tous les paquets devant etre depaquete pour
       le 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.

Param`etres g'en'eraux:

       '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

       '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 implemente egalement le support pour les variantes machines
       utilise initialement dans Emdebian Crush, bien que pour une
       implementation differente.  Using the cascading configuration support,
       particular machine:variant combinations can be supported by simple
       changes on the command line.

       Definir "tarballname" a vraie empaquette egalement le systeme de
       fichiers final dans un 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.

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".

       '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.

Apt s'ecuris'e

       To use authenticated apt repositories, multistrap either needs to be
       able to install an appropriate keyring package from the existing apt
       sources outside the multistrap environment or have the relevant keys
       already configured using apt-key on the host system.

       Si ces paquets existent, specifiez-les dans l'option 'keyring' pour
       chaque depot. multistrap verifiera alors que apt a deja installe ce
       paquet:  ainsi le depot pourra etre authentifie avant de telecharger
       des paquets.

       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.
       Not all packages need keyring packages, if you configure apt-key

       Les paquets de trousseau de cles seront egalement installes a
       l'interieur de l'environnement du multistrap pour correspondre avec les
       sources apt installes du multistrap.

       Toute configuration de apt-key doit etre faite pour la machine
       executant multistrap.


       multistrap est sans-etat - si le repertoire existe, il procedera tout
       simplement de maniere ordinaire et apt essaiera de reprendre la ou il
       s'etait arrete.

Root Filesystem Configuration

       multistrap decompresse les paquets telecharges, mais d'autres etapes de
       la configuration du systeme ne sont pas tentees. Les exemples incluent:


       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

       Une fois que multistrap a reussi a creer la structure de base pour les
       fichiers et les repertoires, d'autres scripts specifiques aux
       peripheriques sont necessaires avant que le systeme de fichiers puisse
       etre installe sur le peripherique cible.

       Une fois installes, les paquets doivent eux-memes etre configures en
       utilisant les scripts du responsable du paquet et "dpkg --configure
       -a", a moins qu'il ne s'agisse d'un multistrap natif.

       Pour que "dpkg" puisse fonctionner, /proc et /sysfs doivent etre montes
       (ou etre montables), /dev/pts est egalement recommande.

       Voir aussi:


       Pour configurer les paquets depaquetes (que ce soit en mode croise ou
       natif), certaines variables d'environnements sont necessaires:

       Il est necessaire de signaler a Debconf que l'interaction utilisateur
       n'est pas souhaitee:


       Il est necessaire de signaler a Perl qu'aucune locales n'est disponible
       l'interieur du chroot et de ne pas se plaindre:


       Puis, dpkg peut configurer les paquets:

       methode chroot (PATH = le repertoire de base du chroot):

        LC_ALL=C LANGUAGE=C LANG=C chroot /PATH/ dpkg --configure -a

       dans un interpreteur de commandes de connexion:

        # export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
        # export LC_ALL=C LANGUAGE=C LANG=C
        # dpkg --configure -a

       (Comme ci-dessus, dpkg a besoin que /proc et /sysfs soient montes en

mode natif - multistrap

       multistrap n'etait pas prevu pour le mode natif, il fut developpe pour
       la gestion de plusieurs architectures. Pour que de multiples depots
       puissent etre utilises, multistrap depaquette uniquement les paquets
       selectionnes par apt.

       En mode natif, diverses operations post-multistrap que debootstrap
       ferait pour vous sont probablement necessaires:

       1. copiez /etc/hosts dans le chroot
        2. nettoyez l'environnement pour detruire LANGUAGE, LC_ALL and LANG
           pour passer sous silence les nuisances des avertissements cachant
       d'autres erreurs

       (Une alternative pour detruire les variables de localisation est
       d'ajouter locales a votre fichier de configuration multistrap dans
       l'option << packages >>.

       Un multistrap natif peut etre directement utilise avec chroot, ainsi
       "multistrap" execute "dpkg --configure -a" a la fin du processus du

Configuration en cascade

       Pour assurer les multiples variantes d'une configuration de base,
       "multistrap" permet d'inclure des fichiers de configuration (plus
       generaux) dans des fichiers de configuration. C'est-a-dire que le
       fichier de configuration le plus specifique/detaille doit etre specifie
       a la ligne de commande et ce fichier inclut un fichier qui est partage
       avec d'autres configurations.

       Fichier de base:




       En specifiant uniquement le fichier armel.conf, le reste des parametres
       sera obtenu a partir du fichier crosschroot.conf afin que les
       modifications communes ne doivent etre realisees que dans un seul

       Il est fortement recommande pour toutes modifications dans les fichiers
       de configuration impliques dans n'importe quelle cascade de les tester
       avec l'option "--simulate"de multistrap qui produira en sortie un
       resume des options definies une fois la cascade effectuee. Il faut
       noter que multistrap n'avertit pas si un fichier de configuration
       contient une option non reconnue (afin d'assurer la compatibilite
       future avec les configurations retroportees). Ainsi une simple faute de
       frappe peut etre a l'origine d'une option non definie.

Support des variantes de Machines

       Toutes les anciennes variables de packages.conf de emsandbox peuvent
       etre converties en variables de configuration "mulistrap". L'assistance
       des variantes machines dans "multistrap" se concentre sur les scripts, et

       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.

       Un des avantages d'utiliser le support des variantes machines est que
       la totalite du systeme de fichiers racine peut etre gere par un seul
       appel a multistrap - ceci est utile lors de la creation de systemes de
       fichiers racines dans l'espace utilisateur.

       Pour permettre le support des variantes machines, il faut specifier le
       chemin vers les scripts devant etre appeles dans le fichier de
       configuration variant (Section Generale):


Restriction de la s'election des paquets

       "multistrap" inclut les paquets requis par defaut, la liste actuelle
       des paquets peut etre visualisee en utilisant:

        grep-available  -FPriority 'required' -sPackage

       Si l'option OmitRequired est definie a vraie, ces paquets ne seront pas
       ajoutes - bien qu'utile, cette option peut facilement conduire a un
       rootfs inutile. Seuls les paquets specifies manuellement dans les
       fichiers de configuration seront utilises dans les calculs - les
       dependances de ces paquets seront egalement ajoutees mais aucun autres.

       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:

        $ sudo apt-get install apt/stable

       Compare with

        $ sudo apt-get install apt/lenny

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.



       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.