Provided by:
multistrap_2.1.6ubuntu3_all 
Nom
multistrap - multiple repository bootstraps
Synopsis
multistrap [-a ARCH] [-d REPERTOIRE] -f FICHIER_CONFIG multistrap
[--simulate] -f FICHIER_CONFIG multistrap -?|-h|--help|--version
Options
-?|-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.
Description
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:
[General]
arch=armel
directory=/opt/multistrap/
# same as --tidy-up option if set to true
cleanup=true
# same as --no-auth option if set to true
# keyring packages listed in each bootstrap will
# still be installed.
noauth=false
# extract all downloaded archives (default is true)
unpack=true
# whether to add the /suite to be explicit about where apt
# needs to look for packages. Default is false.
explicitsuite=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
aptsources=Debian
# 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.
bootstrap=Debian
[Debian]
packages=
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=lenny
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.
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.
Repositories
"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
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 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
[Debian]
packages=
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=lenny
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
appropriately.
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.
'Etat
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:
/etc/inittab
/etc/fstab
/etc/hosts
/etc/securetty
/etc/modules
/etc/hostname
/etc/network/interfaces
/etc/init.d
/etc/dhcp3
Any device-specific device nodes will also need to be created using
MAKEDEV or "device-table.pl" - a helper script that can work around
some of the issues with MAKEDEV. device-table.pl 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: http://wiki.debian.org/Multistrap
Environnement
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:
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
Il est necessaire de signaler a Perl qu'aucune locales n'est disponible
l'interieur du chroot et de ne pas se plaindre:
LC_ALL=C LANGUAGE=C LANG=C
Puis, dpkg peut configurer les paquets:
methode chroot (PATH = le repertoire de base du chroot):
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true \
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
premier.)
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
multistrap.
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:
/usr/share/multistrap/crosschroot.conf
Variations:
/usr/share/multistrap/armel.conf
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
fichier.
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,
config.sh et setup.sh
Once "multistrap" has unpacked the downloaded packages, the "setup.sh"
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,
"config.sh" 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):
[General]
include=/path/to/general.conf
setupscript=/path/to/setup.sh
configscript=/path/to/config.sh
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.
[Baked]
packages=
source=http://www.emdebian.org/baked
keyring=emdebian-archive-keyring
suite=testing
omitdebsrc=true
fakeroot
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.