Rights: Copyright ©  2006-2011 Debian Live Project;
License: Ce programme est un logiciel libre; vous pouvez le redistribuer ou le modifier suivant les termes de la Licence Générale Publique GNU telle que publiée par la Free Software Foundation: soit la version 3 de cette licence, soit (à votre gré) toute version ultérieure.

Ce programme est distribué dans l’espoir qu’il vous sera utile, mais SANS AUCUNE GARANTIE: sans même la garantie implicite de COMMERCIALISABILITÉ ni d’ADÉQUATION À UN OBJECTIF PARTICULIER. Consultez la Licence Générale Publique GNU pour plus de détails.

Vous devriez avoir reçu une copie de la Licence Générale Publique GNU avec ce programme ; si ce n’est pas le cas, consultez http://www.gnu.org/licenses/.

Le texte complet de la Licence Générale Publique GNU peut être trouvé dans le fichier / usr/share/common-licenses/GPL-3


Debian Live Manual

À propos

1. À propos de ce manuel

1.1 Pour les impatients
1.2 Terminologie
1.3 Auteurs
1.4 Contribuer à ce document
1.4.1 Appliquer des patches
1.4.2 Traduction

2. À propos du projet Debian Live

2.1 Motivation
2.1.1 Quel est le problème avec les systèmes live actuels
2.1.2 Pourquoi créer notre propre système live?
2.2 Philosophie
2.2.1 Seulement paquets officiels inchangés
2.2.2 Pas de configuration des paquets du système live
2.3 Contact

Utilisateur

3. Installation

3.1 Exigences
3.2 Installation de live-build
3.2.1 Depuis le référentiel Debian
3.2.2 Depuis le code source
3.2.3 À partir des instantanés
3.3 live-boot et live-config
3.3.1 Depuis le référentiel Debian
3.3.2 Depuis le code source
3.3.3 À partir des instantanés

4. Les bases

4.1 Qu'est-ce qu'un système live?
4.2 Premières étapes: la construction d'une image ISO hybride
4.3 Utilisation d'une image ISO hybride live
4.3.1 Graver une image ISO sur un support physique
4.3.2 Copie d'un image ISO hybride sur une clé USB
4.3.3 Démarrer le support live
4.4 Utiliser une machine virtuelle pour les tests
4.4.1 Test d'une image ISO avec QEMU
4.4.2 Test d'une image ISO avec virtualbox-ose
4.5 Construction d'une image USB/HDD
4.6 Utiliser une image USB/HDD
4.6.1 Test d'une image USB/HDD avec Qemu
4.6.2 Utilisation de l'espace disponible sur une clé USB
4.7 Construction d'une image netboot
4.7.1 Serveur DHCP
4.7.2 Serveur TFTP
4.7.3 Serveur NFS
4.7.4 Guide pratique pour expérimenter avec une image Netboot
4.7.5 Qemu
4.7.6 VMWare Player

5. Aperçu des outils

5.1 live-build
5.1.1 La commande lb config
5.1.2 La commande lb build
5.1.3 La commande lb clean
5.2 Le paquet live-boot
5.3 Le paquet live-config

6. Gestion d'une configuration

6.1 Utilisez auto pour gérer les modifications de configuration
6.2 Exemples de scripts auto

7. Vue d'ensemble de la personnalisation

7.1 Configuration pendant la construction vs. le démarrage
7.2 Étapes de la construction
7.3 Supplément lb config avec des fichiers
7.4 Tâches de personnalisation

8. Personnalisation de l'installation de paquets

8.1 Sources des paquets
8.1.1 Distribution, archive areas et mode
8.1.2 Miroirs de distribution
8.1.3 Miroirs de distribution utilisés au temps de construction
8.1.4 Miroirs de distribution utilisés au moment de l'exécution
8.1.5 Référentiels additionnels
8.2 Choisir les paquets à installer
8.2.1 Choisir un certain nombre de paquets
8.2.2 Listes de paquets
8.2.3 Listes de paquets prédéfinies
8.2.4 Listes de paquets locaux
8.2.5 Listes locaux de paquets binaires
8.2.6 Extension d'un liste de paquets fournis à l'aide de «includes»
8.2.7 Utilisant des conditionnels dans les listes de paquets
8.2.8 Tâches
8.2.9 Tâches de bureau et de la langue
8.3 Installation des paquets modifiés ou de tiers
8.3.1 Utilisant chroot_local-packages pour installer paquets personnalisés
8.3.2 Utilisant un référentiel APT pour installer des paquets personnalisés.
8.3.3 Les paquets personnalisés et APT
8.4 Configuration d'APT au moment de la construction
8.4.1 Choisir apt ou aptitude
8.4.2 Utilisation d'un proxy avec APT
8.4.3 Régler APT pour économiser de l'espace
8.4.4 Passer des options à apt ou aptitude
8.4.5 APT pinning

9. Personnalisation des contenus

9.1 Includes
9.1.1 Live/chroot local includes
9.1.2 Binary local includes
9.1.3 Binary includes
9.2 Hooks
9.2.1 Live/chroot local hooks
9.2.2 Hooks au moment du démarrage
9.2.3 Binary local hooks
9.3 Préconfigurer questions de debconf

10. Personnalisation des comportements au moment de l'exécution

10.1 Personnalisation de l'utilisateur Live
10.2 Personnalisation des paramètres régionaux et la langue
10.3 Persistance
10.3.1 Persistance pleine
10.3.2 Montage automatique de Home
10.3.3 Instantanés
10.3.4 SubText persistant
10.3.5 Remasterisation partielle

11. Customizing the binary image

11.1 Bootloader
11.2 ISO metadata

12. Customizing Debian Installer

12.1 Types of Debian Installer
12.2 Customizing Debian Installer by preseeding
12.3 Customizing Debian Installer content

Projet

13. Reporting bugs

13.1 Known issues
13.2 Rebuild from scratch
13.3 Use up-to-date packages
13.4 Collect information
13.5 Isolate the failing case if possible
13.6 Use the correct package to report the bug against
13.6.1 At build time whilst bootstrapping
13.6.2 At build time whilst installing packages
13.6.3 At boot time
13.6.4 At run time
13.7 Do the research
13.8 Where to report bugs

14. Coding Style

14.1 Compatibility
14.2 Indenting
14.3 Wrapping
14.4 Variables
14.5 Miscellaneous

15. Procedures

15.1 Udeb Uploads
15.2 Major Releases
15.3 Point Releases
15.3.1 Point release announcement template

Exemples

16. Examples

16.1 Using the examples
16.2 Tutorial 1: A standard image
16.3 Tutorial 2: A web browser utility
16.4 Tutorial 3: A personalized image
16.4.1 First revision
16.4.2 Second revision
16.5 A VNC Kiosk Client
16.6 A base image for a 128M USB key
16.7 A localized KDE desktop and installer

Debian Live Manual

À propos

1. À propos de ce manuel

L'objectif principal de ce manuel est servir de point d'accès unique à tous les documents liés au projet Debian Live. Tandis qu'il est principalement sur vous aider à construire un système Live et non pas sur des sujets de l'utilisateur final, un utilisateur final peut trouver des informations utiles dans ces sections: Les Bases couvrent la préparation des images pour être démarrées à partir des médias ou depuis le réseau, et Personnalisation des comportements au moment de l'exécution décrit certaines options qui peuvent être spécifiées à l'invite de démarrage, tels que la sélection d'un clavier, des paramètres régionaux, et la utilisation de la persistance.

Certaines commandes mentionnées dans le texte doivent être exécutées avec les privilèges super-utilisateur, qui peuvent être obtenu en devenant root à l'aide de su ou en utilisant sudo. Afin de distinguer les commandes qui peuvent être exécutées par un utilisateur sans privilèges de celles nécessitant les privilèges super-utilisateur, les commandes sont précédées respectivement par $ ou #. Ce symbole ne fait pas partie de la commande.

1.1 Pour les impatients

Même si nous croyons que tout dans ce manuel est important pour au moins certains de nos utilisateurs, nous nous rendons compte qu'il y a beaucoup de matière à couvrir et que vous pouvez expérimenter avant d'entrer dans les détails. Par conséquent, nous avons fourni trois tutoriels dans la section Exemples destinée à vous apprendre la construction de l'image et les bases de la personnalisation. Lire en premier En utilisant les exemples, suivie par Tutoriel 1: Une image standard, Tutoriel 2: Un logiciel de navigateur Web et finalement Tutoriel 3: Une image personnalisée. À la fin de ces tutoriels, vous aurez un avant-goût de ce qui peut être fait avec Debian Live. Nous vous encourageons à revenir à l'étude plus approfondie du manuel, la prochaine lecture peut-être Les bases, passer pour Construire une image netboot, et finissant par la lecture de la Vue d'ensemble de la personnalisation et les autres sections suivantes. En ce point, nous espérons que vous êtes complètement excités par ce que on peut faire avec Debian Live et motivés pour lire le reste du manuel, du début à la fin

1.2 Terminologie
  • Système Live: Un système d'exploitation pouvant être démarré sans installation préalable sur disque dur. Les Systèmes Live ne modifient pas le système d'exploitation local ou les fichiers installés sur le disque dur sans qu'on leur en donne explicitement l'instruction. D'habitude, les systèmes Live sont démarrés à partir de media tels que des CD, DVD, ou des clés USB. Certains peuvent également être démarrés depuis le réseau.
  • Debian Live: Le sous-projet Debian qui maintient les paquets live-boot, live-build, live-config, et live-manual.
  • Système Debian Live: Un système live qui utilise les logiciels du système d'exploitation Debian et qui peut être lancé depuis CD, DVD, clé USB, en réseau (à l'aide des images netboot), et à partir d'Internet (à l'aide du paramètre de démarrage fetch=URL).
  • Système hôte: L'environnement utilisé pour créer le système live.
  • Système de destination: L'environnement utilisé pour faire tourner le système live.
  • live-boot: Une collection de scripts utilisés pour lancer des systèmes live. live-boot faisait initialement partie de live-initramfs.
  • live-build: Une collection de scripts utilisés pour personnaliser les systèmes Debian Live. live-build était initialement nommé live-package, puis live-helper.
  • live-config: Une collection de scripts utilisés pour configurer un système live durant le processus de démarrage. live-config faisait initialement partie de live-initramfs.
  • live-manual: Ce document est maintenu dans un paquet nommé live-manual.
  • Debian Installer (d-i): Le système d'installation officiel pour la distribution Debian.
  • Paramètres de démarrage: Les paramètres pouvant être entrés à l'invite de démarrage afin de modifier le kernel ou live-config.
  • chroot: Le programme chroot, chroot(8), nous permet de faire tourner plusieurs instances concurrentes de l'environnement GNU/Linux sur un système sans redémarrage.
  • Image binaire: Un fichier contenant le système live, tel que binary.iso ou binary.img.
  • Distribution de destination: La distribution sur laquelle votre système live sera basée. Ceci peut varier en fonction de la distribution de votre système hôte.
  • Squeeze/Wheezy/Sid (stable/testing/unstable): Debian noms de code pour les versions. Au moment de la rédaction, Squeeze est le courant version stable et Wheezy est la version actuelle testing. Sid sera toujours synonyme de la version unstable. Tout au long du manuel, nous avons tendance à utiliser des noms de code pour les versions, car c'est ce qui est supporté par les outils eux-mêmes.
  • La distribution stable contient la dernière version officielle de Debian. La distribution testing est la future version stable où seuls les paquets suffisamment matures peuvent entrer. Un avantage de cette distribution est qu'elle contient des logiciels de versions plus récentes que la version stable. La distribution unstable est en constante évolution. En général cette distribution est utilisée par les développeurs et ceux qui aiment le risque.

    1.3 Auteurs

    La liste des auteurs (dans l'ordre alphabétique):

  • Ben Armstrong
  • Brendan Sleight
  • Chris Lamb
  • Daniel Baumann
  • Franklin Piat
  • Jonas Stein
  • Kai Hendry
  • Marco Amadori
  • Mathieu Geli
  • Matthias Kirschner
  • Richard Nelson
  • Trent W. Buck
  • 1.4 Contribuer à ce document

    Ce manuel est conçu comme un projet communautaire et toutes les propositions d'améliorations et de contributions sont bienvenues. La meilleure façon de soumettre une contribution est de l'envoyer à la liste de diffusion. S'il vous plaît voir Contact pour plus d'informations.

    Lorsque vous soumettez une contribution, veuillez indiquer clairement le copyright et inclure la mention légale relative à la licence. Notez que pour être acceptée, la contribution doit être déposée sous la même licence que le reste du document, c'est-à-dire la GPL version 3 ou ultérieure.

    Les sources de ce manuel sont maintenues à l'aide du logiciel de gestion de versions Git. Vous pouvez obtenir la dernière copie en exécutant:

      $ git clone git://live.debian.net/git/live-manual.git

    Avant de soumettre votre contribution, veuillez prévisualiser votre travail. Afin de prévisualiser live-manual, assurez-vous que les paquets nécessaires sont installés en exécutant:

       # apt-get install make po4a sisu-complete libnokogiri-ruby

    Vous pouvez compiler live-manual depuis le répertoire racine de votre checkout git en exécutant:

       $ make build

    Comme il faut un certain temps pour construire le manuel dans toutes les langues disponibles, il peut être pratique construire pour une seule langue, par exemple en exécutant:

       $ make build LANGUAGES=en

    1.4.1 Appliquer des patches

    Les contributions directes au référentiel sont possibles pour tout le monde. Cependant, nous vous demandons d'envoyer les changements conséquents sur la liste de diffusion au préalable. Afin de faire un push sur le référentiel, les étapes suivantes sont nécessaires.

  • Téléchargez la clé publique:
  •    $ mkdir -p ~/.ssh/identity.d
       $ wget http://live.debian.net/other/keys/git@live.debian.net \
           -O ~/.ssh/identity.d/git@live.debian.net
       $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
           -O ~/.ssh/identity.d/git@live.debian.net.pub
       $ chmod 0600 ~/.ssh/identity.d/git@live.debian.net*

  • Ajoutez la section suivante à votre configuration openssh-client:
  •    $ cat >> ~/.ssh/config << EOF
       Host live.debian.net
           Hostname live.debian.net
           User git
           IdentityFile ~/.ssh/identity.d/git@live.debian.net
       EOF

  • Clonez le manuel via ssh:
  •    $ git clone git@live.debian.net:/live-manual.git
       $ cd live-manual && git checkout debian-next

  • Notez que vous devez livrer des changements sur la branche debian-next, pas sur la branche debian.
  • Après édition des fichiers dans manual/en/, veuillez appeler 'commit' dans le dossier racine du répertoire afin de nettoyer les fichier et de mettre à jour les fichiers de traduction:
  •    $ make commit

  • Après nettoyage, soumettre les modifications. Veuillez écrire les commentaires de commit à l'aide de phrases complètes, en commençant par une majuscule et en terminant par un point, et en commençant par 'Fixing/Adding/Removing/Correcting/Translating', par exemple
  •    $ git commit -a -m "Adding a section on applying patches."

  • Envoyez votre commit au serveur:
  •    $ git push

    1.4.2 Traduction

    Pour soumettre une traduction pour une nouvelle langue, suivez ces trois étapes:

  • Traduire les fichiers about_manual.ssi.pot, about_project.ssi.pot et index.html.in.pot à votre langue avec votre éditeur préféré (comme poedit). Envoyer les fichiers traduits à la liste de diffusion. Une fois que nous avons examiné votre livraison, nous allons ajouter une nouvelle langue au manuel (avec les fichiers po) et l'activer dans l'autobuild.
  • Une fois la nouvelle langue est ajoutée, vous pouvez commencer à traduire de façon aléatoire tous les fichiers po dans manual/po/.
  • N'oubliez pas que vous devez make commit pour assurer la traduction des manuels sont mis à jour à partir des fichiers po, avant git commit -a et git push.
  • 2. À propos du projet Debian Live

    2.1 Motivation
    2.1.1 Quel est le problème avec les systèmes live actuels

    Lorsque Debian Live a été lancé, il y avait déjà plusieurs systèmes live basés sur debian et ils faisaient un excellent travail. Du point de vue de Debian la plupart d'entre eux ont un ou plusieurs des inconvénients suivants:

  • Ce sont des projets non officiels, développées en dehors de Debian.
  • Ils mélangent les différentes distributions p. ex testing et unstable.
  • Ils supportent seulement i386.
  • Ils modifient le comportement et/ou l'apparence des paquets en les dépouillant pour économiser l'espace.
  • Ils incluent paquets non officiels.
  • Ils offrent kernels personnalisés avec des patches supplémentaires qui ne font pas partie de Debian.
  • Ils sont grands et lents en raison de leur dimension et donc pas recommandés comme systémes de sauvetage.
  • Ils ne sont pas disponibles en différents formats, p. ex. CDs, DVDs, clés USB et images netboot.
  • 2.1.2 Pourquoi créer notre propre système live?

    Debian est le système d'exploitation universel: Debian a un système officiel live pour afficher autour et pour représenter officiellement le vrai, seul et unique système Debian avec les principaux avantages suivants:

  • Ce serait un sous-projet officiel Debian.
  • Il reflète l'état (actuel) d'une distribution.
  • Il fonctionne sur le plus grand nombre d'architectures possible.
  • Il seulement se compose de paquets Debian inchangés.
  • Il ne contient pas de paquets non officiels.
  • Il utilise un kernel Debian inchangé sans patches supplémentaires.
  • 2.2 Philosophie
    2.2.1 Seulement paquets officiels inchangés

    Nous seulement utiliserons les paquets officiels Debian du référentiel «main ». La section non-free ne fait pas partie de Debian et ne peut donc pas être utilisée pour les images officiels du système live.

    Nous ne changerons pas les paquets. Chaque fois que nous avons besoin de changer quelque chose, nous le ferons en coordination avec le responsable du paquet dans Debian.

    À titre d'exception, nos propres paquets tels que live-boot, live-build ou live-config peuvent être utilisés temporairement à partir de notre propre référentiel pour raisons de développement (par exemple pour créer des instantanés de développement). Ils seront téléchargés sur Debian régulièrement.

    2.2.2 Pas de configuration des paquets du système live

    Dans cette phase, nous n'offerons configurations alternatives. Tous les paquets sont utilisés dans leur configuration par défaut comme ils sont après une installation standard de Debian.

    Chaque fois que nous avons besoin d'une configuration par défaut différent, nous le ferons en coordination avec le responsable du paquet dans Debian.

    Un système de configuration des paquets est fourni avec debconf dans lb config (utiliser --preseed FICHIER) permettant la personnalisation des paquets installés sur votre image Debian Live, mais pour les images officielles seulement sera utilisé une configuration par défaut. Pour plus d'informations, s'il vous plaît voir Vue d'ensemble de la personnalisation.

    Exception: Il y a quelques changements essentiels nécessaires pour mettre un système live en marche (par exemple la configuration de pam pour permettre des mots de passe vide). Ces changements essentiels doivent être maintenus aussi minimes que possible et devraient être fusionnées au sein du référentiel Debian s'il est possible.

    2.3 Contact
  • Liste de diffusion: Le contact principal du projet est la liste de diffusion ‹http://lists.debian.org/debian-live/›. Vous pouvez envoyer un courriel à la liste directement en adressant votre courrier à ‹debian-live@lists.debian.org.› Les archives de la liste sont disponibles à ‹http://lists.debian.org/debian-live/›.
  • IRC: Un certain nombre d'utilisateurs et les développeurs sont présents dans le canal #debian-live sur irc.debian.org (OFTC). Quand vous posez une question sur IRC, s'il vous plaît soyez patient en attendant une réponse. Si aucune réponse n'est donnée, s'il vous plaît envoyez un courriel à la liste de diffusion.
  • BTS : Le Debian Bug Tracking System (BTS) contient les détails des bugs rapportés par les utilisateurs et les développeurs. Chaque bug reçoit un numéro, et il est conservé jusqu'à ce qu'il soit marqué comme traité. Pour plus d'informations, s'il vous plaît voir Rapporter des bugs.
  • Wiki: Le wiki Debian Live à ‹http://wiki.debian.org/DebianLive› est un lieu pour recueillir des informations, discuter des technologies appliquées, et structures des systèmes Debian Live qui vont au-delà de la portée de ce document.
  • Utilisateur

    3. Installation

    3.1 Exigences

    Les exigences pour la création des images Debian Live sont très peu:

  • Super-utilisateur (root) accès
  • Une version mise à jour de live-build
  • Un shell POSIX, tel que bash ou dash.
  • debootstrap ou cdebootstrap
  • Linux 2.6.x
  • Notez que l'utilisation de Debian ou une distribution dérivée de Debian n'est pas nécessaire - live-build fonctionne sur presque toute distribution avec les exigences ci-dessus.

    3.2 Installation de live-build

    Vous pouvez installer live-build en un certain nombre de façons différentes:

  • Depuis le référentiel Debian
  • Depuis le code source
  • À partir des instantanés
  • Si vous utilisez Debian, la méthode recommandée consiste à installer live-build depuis le référentiel Debian.

    3.2.1 Depuis le référentiel Debian

    Il suffit d'installer live-build comme n'importe quel autre paquet:

       # apt-get install live-build

    ou

       # aptitude install live-build

    3.2.2 Depuis le code source

    live-build est développé en utilisant le système de contrôle de version Git. Dans les systèmes basés sur Debian, cela est fourni par le paquet git Pour examiner le dernier code, exécutez:

       $ git clone git://live.debian.net/git/live-build.git

    Vous pouvez compiler et installer votre propre paquet Debian en exécutant:

       $ cd live-build
       $ dpkg-buildpackage -rfakeroot -b -uc -us
       $ cd ..

    Maintenant, installez celui des fichiers récemment construits que vous intéresse, p. ex

       # dpkg -i live-build_2.0.8-1_all.deb

    Vous pouvez également installer live-build directement sur votre système en exécutant:

       # make install

    et le désinstaller avec:

       # make uninstall

    3.2.3 À partir des instantanés

    Si vous ne souhaitez pas de créer ou d'installer live-build depuis les sources, vous pouvez utiliser des instantanés. Ils sont construits automatiquement à partir de la dernière version du Git et ils sont disponibles à ‹http://live.debian.net/debian/›.

    3.3 live-boot et live-config

    Remarque: Vous n'avez pas besoin d'installer live-boot ou live-config sur votre système afin de créer des systèmes Debian Live. Cependant, cela ne fera aucun mal et est utile à des fins de référence.

    3.3.1 Depuis le référentiel Debian

    Tous deux live-boot et live-config sont disponibles dans le référentiel Debian comme Installation de live-build.

    3.3.2 Depuis le code source

    Pour utiliser les dernières sources du git, vous pouvez suivre le procédure ci-dessous. S'il vous plaît assurer que vous êtes familiarisé avec les termes mentionnés dans Termes.

  • Examiner les sources de live-boot et live-config
  •    $ git clone git://live.debian.net/git/live-boot.git
       $ git clone git://live.debian.net/git/live-config.git

    Consultez les pages de manuel de live-boot et live-config pour plus de détails sur la personnalisation si c'est votre raison pour la création de vos paquets depuis les sources.

  • Créer les fichiers .deb de live-boot et live-config
  • Vous devez créer sur votre distribution objectif ou en chroot contenant votre plateforme objectif: cela signifie que si votre objectif est Squeeze alors vous devez créer sur Squeeze.

    Utilisez un système de construction automatique personnel tels que pbuilder ou sbuild si vous avez besoin pour créer live-boot pour une distribution objectif qui diffère de votre système de construction. Par exemple, pour les images live de Squeeze, créez live-boot dans un chroot Squeeze. Si votre distribution objectif correspond à votre distribution vous pouvez créer directement sur le système de construction en utilisant dpkg-buildpackage (fournis par le paquet dpkg-dev) :

       $ cd live-boot
       $ dpkg-buildpackage -b -uc -us
       $ cd ../live-config
       $ dpkg-buildpackage -b -uc -us

  • Utilisez tous les fichiers .deb générés.
  • Comme live-boot et live-config sont installés par le système live-build, l'installation des paquets dans le système hôte ne suffit pas: vous devez traiter les fichiers .deb générés comme aucun autre paquet personnalisé. S'il vous plaît voir Personnalisation de l'installation de paquets pour plus d'informations. Vous devriez prêter une attention particulière à Référentiels supplémentaires.

    3.3.3 À partir des instantanés

    Vous pouvez laisser live-build utiliser automatiquement les derniers instantanés de live-boot et live-config configurant un référentiel de tierce partie dans votre répertoire de configuration de live-build. En supposant que vous avez déjà créé un arbre de configuration avec lb config:

       $ lb config --repository live.debian.net

    4. Les bases

    Ce chapitre contient un bref aperçu du procès de construction et des instructions pour utiliser les trois types d'images les plus couramment utilisées. Le type d'image le plus polyvalent, iso-hybrid, peut être utilisé sur une machine virtuelle, supports optiques ou un périphérique USB de stockage portable. Dans certains cas particuliers, tels que l'utilisation de la persistance, le type usb-hdd peut être plus approprié pour les périphériques USB. Le chapitre se termine avec des instructions pour la construction et l'utilisation d'une image net , qui est un peu plus compliqué en raison de la configuration requise sur le serveur. C'est un sujet un peu avancée pour tous ceux qui ne connaissent pas déjà le démarrage par le réseau, mais est inclus ici car une fois la configuration est terminée, il est un moyen très pratique pour tester et déployer des images pour le démarrage sur le réseau local sans le tracas des supports de l'image.

    Tout au long du chapitre, nous ferons souvent référence à la valeur par défaut des noms de fichiers produits par live-build. Si vous téléchargez une image précompilée les noms de fichiers peuvent varier.

    4.1 Qu'est-ce qu'un système live?

    Un système live signifie généralement un système d'exploitation démarré sur un ordinateur à partir d'un support amovible, tel qu'un CD-ROM ou une clé USB, ou d'un réseau prêt à l'emploi sans aucune installation sur le disque habituel(s), avec auto-configuration fait lors de l'exécution (voir Termes).

    Avec Debian Live, c'est un système Debian GNU/Linux, construit pour une des architectures supportées (actuellement amd64, i386, PowerPC et SPARC). Il est fait à partir des éléments suivants:

  • Linux kernel image, d'habitude appelé vmlinuz*
  • Initial RAM disk image (initrd): Un disque virtuel RAM configuré pour le démarrage de Linux, contenant possiblement des modules nécessaires pour monter l'image du système et certains scripts pour le faire.
  • System image: L'image du système de fichiers du système d'exploitation. Habituellement, un système de fichiers SquashFS comprimé est utilisé pour réduire au minimum la taille de l'image Debian Live. Notez qu'il est en lecture seulement. Ainsi, lors du démarrage du système Debian Live nous allons utiliser un disque RAM et un mécanisme "union" pour permettre l'écriture de fichiers dans le système en marche. Cependant, toutes les modifications seront perdues lors de l'arrêt à moins que l'option persistance est utilisée (voir Persistance).
  • Bootloader: Un petit morceau de code conçu pour démarrer à partir du support choisi, il peut présenter un menu rapide ou permettre la sélection des options/configuration. Il charge le kernel Linux et son initrd pour fonctionner avec un système de fichiers associé. Différentes solutions peuvent être utilisées, selon le support de destination et le format du système de fichiers contenant les composants mentionnés précédemment: isolinux pour démarrer à partir d'un CD ou DVD au format ISO9660, syslinux pour démarrer le disque dur ou clé USB à partir d'une partition VFAT, extlinux pour ext2/3/4 et partitions btrfs, pxelinux pour netboot PXE, GRUB pour ext2/3/4 partitions, etc.
  • Vous pouvez utiliser live-build pour construire l'image du système à partir de vos spécifications, configurer un kernel Linux, son initrd, et un chargeur de démarrage pour les exécuter, tout dans un format en fonction du support (image ISO9660, disque image, etc.)

    4.2 Premières étapes: la construction d'une image ISO hybride

    Quel que soit le type d'image, vous devrez effectuer les mêmes étapes de base pour créer une image chaque fois. Comme premier exemple, exécuter la séquence suivante de commandes live-build pour créer une image ISO hybride de base contenant tout le système Debian standard sans X.org. Elle est appropriée pour être gravée sur CD ou DVD, et également peut être copiée sur une clé USB.

    Tout d'abord, exécutez la commande lb config. Cela va créer une hiérarchie "config /" dans le répertoire courant pour l'utilisation par d'autres commandes:

       $ lb config

    Aucun paramètre n'est passé à lb config, donc défauts seront utilisés pour l'ensemble de ses diverses options. Voir La commande lb config pour plus de détails.

    Maintenant que la hiérarchie "config /" existe, créez l'image avec la commande lb build :

       # lb build

    Ce processus peut prendre un certain temps, en fonction de la vitesse de votre connexion réseau. Quand il est complet, il devrait y avoir un fichier image binary-hybrid.iso prêt à l'emploi, dans le répertoire courant.

    4.3 Utilisation d'une image ISO hybride live

    Après la construction ou le téléchargement d'une image ISO hybride, qui peut être obtenue à ‹http://www.debian.org/CD/live/›, l'étape suivante est d'habitude préparer votre support pour le démarrage, soit sur CD-R(W) ou DVD -R(W) des supports optiques ou une clé USB.

    4.3.1 Graver une image ISO sur un support physique

    Graver une image ISO est facile. Il suffit d'installer wodim et l'utiliser à partir de la ligne de commande pour graver l'image. Par exemple:

       # apt-get install wodim

       $ wodim binary-hybrid.iso

    4.3.2 Copie d'un image ISO hybride sur une clé USB

    Les images ISO préparées avec la commande isohybrid comme les images iso-hybrid produites par défaut, peuvent être simplement copiées sur une clé USB avec dd ou un programme équivalent. Brancher une clé USB avec une capacité suffisamment grande pour votre fichier image et déterminez quel dispositif il est, que nous appellons ci-dessous ${USBSTICK}. C'est le fichier de périphérique de votre clé, tel que /dev/sdb, pas une partition, tel que /dev/sdb1! Vous pouvez trouver le nom du périphérique en regardant dans la sortie de dmesg après avoir branché le dispositif, ou mieux encore, ls -l /dev/disk/by-id.

    Une fois que vous êtes sûr d'avoir le nom correct de l'appareil, utilisez la commande dd pour copier l'image sur le clé. Ceci écrasera tout fichier déjà existant sur votre clé!

       $ dd if=binary-hybrid.iso of=${USBSTICK}

    4.3.3 Démarrer le support live

    La première fois que vous démarrez votre support live, qu'il s'agisse de CD, DVD, clé USB, ou le démarrage PXE, une certaine configuration dans le BIOS de votre ordinateur peut être d'abord nécessaire. Depuis les BIOS varient grandement en fonctionnalités et raccourcis clavier, on ne peut pas pénétrer dans le sujet en profondeur ici. Certains BIOS fournissent une clé pour ouvrir un menu d'amorçage au démarrage, qui est le moyen le plus facile si elle est disponible sur votre système. Sinon, vous avez besoin d'entrer dans le menu de configuration du BIOS et modifier l'ordre de démarrage pour placer le dispositif de démarrage pour le système live devant votre périphérique de démarrage normal.

    Une fois que vous avez démarré le support, vous êtes présenté avec un menu de démarrage. Si vous appuyez simplement sur enter ici, le système va démarrer en utilisant l'entrée par défaut, Live Pour plus d'informations sur les options de démarrage, consultez l'entrée «Help» dans le menu et aussi les pages de manuel de live-boot et live-config dans le système live.

    En supposant que vous avez sélectionné Live et démarré une image de bureau live par défaut, après les messages de démarrage défilent, vous devriez être automatiquement connecté au compte user et voir un bureau, prêt à l'emploi. Si vous avez démarré une image de la console uniquement, tels que saveurs standard ou sauvetage des images prédéfinies, vous devriez être automatiquement connecté à la console pour le compte user et voir une invite du shell, prêt à l'emploi.

    4.4 Utiliser une machine virtuelle pour les tests

    Il peut être un gain de temps important pour le développement des images live les faire fonctionner dans une machine virtuelle (VM). Ce n'est pas sans ses avertissements:

  • L'exécution d'une VM demande assez de RAM pour l'OS client et l'hôte et un CPU avec support matériel pour la virtualisation est recommandée.
  • Il ya quelques limitations inhérentes à l'exécution sur une VM, par exemple performance de vidéo médiocre, ou choix limité de matériel émulé.
  • Lors du développement d'un matériel spécifique, il n'existe aucun substitut pour l'exécution que le matériel lui-même.
  • Parfois il ya des bogues que deviennent visibles uniquement pendant l'exécution dans une VM. En cas de doute, testez votre image directement sur le matériel.
  • À condition que vous pouvez travailler avec ces obstacles, examinez les logiciels VM disponibles et choisissez celui qui convient à vos besoins.

    4.4.1 Test d'une image ISO avec QEMU

    La VM la plus polyvalente de Debian est QEMU. Si votre processeur possède un support matériel pour la virtualisation, vouz pouvez utiliser le paquet qemu-kvm; La description du paquet qemu-kvm énumère brièvement les exigences.

    Tout d'abord, installez qemu-kvm si votre processeur le supporte. Sinon, installez qemu, dans ce cas, le nom du programme est qemu au lieu de kvm dans les exemples suivants. Le paquet qemu-utils est également valuable pour créer des images disque virtuels avec qemu-img.

       # apt-get install qemu-kvm qemu-utils

    Démarrer une image ISO est simple:

       $ kvm -cdrom binary-hybrid.iso

    Voir les pages de manuel pour plus de détails.

    4.4.2 Test d'une image ISO avec virtualbox-ose

    Afin de tester l'ISO avec virtualbox-ose:

       # apt-get install virtualbox-ose virtualbox-ose-dkms

       $ virtualbox

    Créer une nouvelle machine virtuelle, modifiez les paramètres de stockage pour utiliser binary-hybrid.iso comme le périphérique CD/DVD et démarrer la machine.

    Remarque: Pour les systèmes live contenant X.org que vous voulez essayer avec virtualbox-ose, vous pouvez inclure le paquet des pilotes VirtualBox X.org, virtualbox-ose-guest-x11, dans votre configuration de live-build. Sinon, la résolution est limitée à 800x600.

       $ lb config --packages virtualbox-ose-guest-x11

    4.5 Construction d'une image USB/HDD

    La construction d'une image USB/HDD est similaire à une ISO hybride à tous les égards, sauf que vous spécifiez -b usb-hdd et le nom du fichier résultant est binary.img qui ne peut être brûlé sur des supports optiques. Il convient pour le démarrage à partir de clés USB, disques durs USB, et divers autres dispositifs de stockage portables. Normalement, une image ISO hybride peut être utilisé à cette fin au lieu, mais si vous avez un BIOS qui ne gère pas correctement des images hybrides, ou si vous voulez utiliser l'espace disponible sur le support à certaines fins, tel que la persistance d'une partition, vous devez utiliser une image USB/HDD.

    Remarque: si vous avez créé une image ISO hybride avec l'exemple précédent, vous devrez nettoyer votre répertoire de travail avec la commande lb clean (voir La commande lb clean):

       # lb clean --binary

    Exécutez la commande lb config comme avant, sauf que cette fois en spécifiant le type d'image USB/HDD:

       $ lb config -b usb-hdd

    Maintenant construire l'image avec la commande lb build

       # lb build

    Quand la création de l'image est finie, un fichier binary.img doit être présent dans le répertoire courant.

    4.6 Utiliser une image USB/HDD

    L'image binaire générée contient une partition VFAT et le chargeur de démarrage syslinux, prêtes à être écrites directement sur une clé USB. Comme l'utilisation d'une image USB/HDD est juste comme l'utilisation d'une image ISO hybride sur USB, suivez les instructions Utiliser une image live ISO hybride, à l'exception du nom de fichier binary.img en lieu de binary-hybrid.iso.

    4.6.1 Test d'une image USB/HDD avec Qemu

    D'abord, installer QEMU comme décrit ci-dessus dans Test d'une image ISO avec QEMU. Ensuite, exécutez kvm ou qemu, selon la version de vos besoins du système hôte, précisant binary.img comme le premier disque dur.

       $ kvm -hda binary.img

    4.6.2 Utilisation de l'espace disponible sur une clé USB

    Pour utiliser l'espace libre restant après avoir copié binary.img sur une clé USB, utilisez un outil de partitionnement tels que gparted ou parted afin de créer une nouvelle partition sur la clé. La première partition sera utilisée par le système Debian Live.

       # gparted ${USBSTICK}

    Après la partition est créée, où ${PARTITION} est le nom de la partition, tel que /dev/sdb2, vous devez créer un système de fichiers sur elle. Un choix possible serait ext4.

       # mkfs.ext4 ${PARTITION}

    Remarque: Si vous voulez utiliser l'espace supplémentaire avec Windows, apparemment cet OS ne peut normalement pas accéder à n'importe quel partition, mais la première. Certaines solutions à ce problème ont été discutés sur notre liste de diffusion, mais il semble qu'il n'y a pas de réponses faciles.

    Rappelez-vous: Chaque fois que vous installez une nouvelle binary.img sur la clé, toutes les données sur la clé seront perdues parce que la table de partition est écrasé par le contenu de l'image, vous devez sauvegarder votre partition supplémentaire d'abord la restaurer à nouveau après la mise à jour du live image.

    4.7 Construction d'une image netboot

    La séquence de commandes suivante va créer une image NetBoot de base contenant le système Debian standard sans X.org. Elle peur être démarrée sur le réseau.

    Remarque: Si vous avez réalisé tous les exemples précédents, vous aurez besoin de nettoyer votre répertoire de travail avec la commande lb clean:

       # lb clean --binary

    Exécutez la commande comme suit pour configurer votre image pour démarrer sur le réseau:

       $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"

    Contrairement à les images ISO et USB/HDD netbooting ne serve pas l'image du système de fichiers pour le client, afin que les fichiers doivent être servis via NFS. Les options --net-root-path et --net-root-server spécifien l'emplacement et le serveur, respectivement, du serveur NFS sur lequel l'image système de fichiers sera situé au moment du démarrage. Assurez-vous que ce sont mis à des valeurs appropriées pour votre réseau et serveur.

    Maintenant construire l'image avec la commande lb build

       # lb build

    Dans un démarrage réseau, le client exécute un petit morceau de logiciel qui réside habituellement sur l'EPROM de la carte Ethernet. Ce programme envoie une requête DHCP pour obtenir une adresse IP et les informations sur ce qu'il faut faire ensuite. Typiquement, la prochaine étape est obtenir un chargeur de démarrage de niveau supérieur via le protocole TFTP. Cela pourrait être pxelinux, GRUB, ou démarrer directement à un système d'exploitation comme Linux.

    Par exemple, si vous décompressez le fichier généré binary-net.tar.gz dans le répertoire /srv/debian-live, vous trouverez l'image du système de fichiers dans live/filesystem.squashfs et le kernel, initrd et le chargeur de démarrage pxelinux dans tftpboot/debian-live/i386.

    Nous devons maintenant configurer trois services sur le serveur pour activer netboot: le serveur DHCP, serveur TFTP et le serveur NFS.

    4.7.1 Serveur DHCP

    Nous devons configurer le serveur DHCP de notre réseau pour être sûr de donner une adresse IP au système client netboot, et pour annoncer l'emplacement du chargeur de démarrage PXE.

    Voici un exemple source d'inspiration, écrit pour le serveur ISC DHCP isc-dhcp-server dans le fichier de configuration /etc/dhcp/dhcpd.conf:

       # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server

       ddns-update-style none;

       option domain-name "example.org";
       option domain-name-servers ns1.example.org, ns2.example.org;

       default-lease-time 600;
       max-lease-time 7200;

       log-facility local7;

       subnet 192.168.0.0 netmask 255.255.255.0 {
         range 192.168.0.1 192.168.0.254;
         next-server servername;
         filename "pxelinux.0";
      }

    4.7.2 Serveur TFTP

    Cela sert le kernel et le ramdisk initial pour le système au moment de l'exécution.

    Vous devriez installer le paquet tftpd-hpa. Il peut servir tous les fichiers contenus dans un répertoire racine, d'habitude /srv/tftp. Pour le laisser servir des fichiers dans /srv/debian-live/tftpboot, exécuter comme utilisateur root la commande suivante:

       # dpkg-reconfigure -plow tftpd-hpa

    et remplissez le nuveau répertoire du serveur tftp

    4.7.3 Serveur NFS

    Une fois l'ordinateur hôte a téléchargé et démarré un kernel Linux et chargé son initrd, il va essayer de monter l'image du système de fichiers live via un serveur NFS.

    Vous devez installer le paquet nfs-kernel-server.

    Ensuite, rendre l'image du système de fichiers disponible via NFS en ajoutant une ligne comme la suivante /etc/exports:

       /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

    et dire au serveur NFS sur cette exportation avec la commande suivante:

       # exportfs -rv

    Mise en place ces trois services peut être un peu délicat. Vous pourriez avoir besoin de patience pour obtenir que tous travaillent ensemble. Pour plus d'informations, consultez le wiki syslinux à ‹http://syslinux.zytor.com/wiki/index.php/PXELINUX› ou la section Debian Installer Manual's TFTP Net Booting à ‹http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html›. Ils pourraient aider parce que leurs processus sont très semblables.

    4.7.4 Guide pratique pour expérimenter avec une image Netboot

    La création d'images NetBoot est facile avec la magie de live-build, mais les essais des images sur des machines physiques peuvent prendre vraiment beaucoup de temps.

    Afin de rendre notre vie plus facile, nous pouvons utiliser la virtualisation. Il ya deux solutions.

    4.7.5 Qemu
  • Installer qemu, bridge-utils, sudo.
  • Èditer /etc/qemu-ifup:

       #!/bin/sh
       sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
       echo "Executing /etc/qemu-ifup"
       echo "Bringing up $1 for bridged mode..."
       sudo /sbin/ifconfig $1 0.0.0.0 promisc up
       echo "Adding $1 to br0..."
       sudo /usr/sbin/brctl addif br0 $1
       sleep 2

    Obtenir, ou construire un grub-floppy-netboot (dans le svn).

    Lancer qemu avec "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"

    4.7.6 VMWare Player
  • Installer VMWare Player (édition "free as in beer")
  • Créer un répertoire PXETester, et créer un fichier texte appelé pxe.vwx à l'intérieur
  • Collez ce texte à l'intérieur:
  •    #!/usr/bin/vmware
       config.version = "8"
       virtualHW.version = "4"
       memsize = "512"
       MemAllowAutoScaleDown = "FALSE"

       ide0:0.present = "FALSE"
       ide1:0.present = "FALSE"
       floppy0.present = "FALSE"
       sound.present = "FALSE"
       tools.remindInstall = "FALSE"

       ethernet0.present = "TRUE"
       ethernet0.addressType = "generated"

       displayName = "Test Boot PXE"
       guestOS = "other"

       ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
       uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
       uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
       ethernet0.generatedAddressOffset = "0"

  • Vous pouvez jouer avec ce fichier de configuration (par exemple, changer la limite de mémoire à 256)
  • Double-cliquez sur ce fichier (ou exécuter VMware Player et sélectionnez ce fichier).
  • Lors de l'exécution presse l'espace si cette question étrange arrive ...
  • 5. Aperçu des outils

    Ce chapitre contient un aperçu des trois principaux outils utilisés dans les systèmes de construction Debian Live: live-build, live-boot et live-config.

    5.1 live-build

    live-build est une collection de scripts pour construire des systèmes Debian Live. Ces scripts sont aussi appelés "commandes".

    L'idée derrière live-build est de constituer un cadre qui utilise un répertoire de configuration pour automatiser et personnaliser complètement tous les aspects de la construction d'une image Live.

    Plusieurs concepts sont similaires à celles dans les outils de le paquet Debian debhelper écrit par Joey Hess:

  • Les scripts ont un emplacement central pour la configuration de leur fonctionnement. Avec debhelper, c'est le sous-répertoire debian/ d'un arbre de paquets. Par exemple, dh_install cherchera, entre autres, un fichier appelé debian/install pour déterminer quels fichiers doivent exister dans un paquet binaire particulier. De la même manière, live-build enregistre son configuration entièrement sous un sous-répertoire config/.
  • Les scripts sont indépendants - c'est-à-dire, il est toujours sûr d'exécuter chaque commande.
  • Contrairement à debhelper, live-build contient un outil pour générer un répertoire de configuration de squelette, lb config. Cela pourrait être considéré comme similaire à des outils tels que dh-make. Pour plus d'informations à propos de lb config, s'il vous plaît voir La commande lb config.

    Le reste de cette section examine les trois commandes les plus importantes:

  • lb config: Responsable de l'initialisation d'un répertoire de configuration du système Live. Voir La commande lb config pour plus d'informations.
  • lb build: Responsable de démarrer un système de construction Live. Voir La commande lb build pour plus d'informations.
  • lb clean: Responsable pour enlever des parties d'un système de construction Live. Voir La commande lb clean pour plus d'informations.
  • 5.1.1 La commande lb config

    Comme indiqué dans live-build, les scripts qui composent live-build lisent leur configuration avec la commande source à partir d'un seul répertoire nommé config/. Comme la construction de ce répertoire à la main serait fastidieux et source d'erreurs, la commande lb config peut être utilisée pour créer des répertoires de configuration de squelette.

    Exécuter lb config sans aucun argument crée un sous-répertoire config/ dont il remplit avec certains paramètres par défaut:

       $ lb config
       P: Creating config tree

       $ ls -l
       total 8
       drwxr-xr-x  3 user user 4096 Sep  7 13:02 auto
       drwxr-xr-x 22 user user 4096 Sep  7 13:02 config

       $ ls -l config/
       total 104
       -rw-r--r-- 1 user user 4197 Sep  7 13:02 binary
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_debian-installer
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_debian-installer-includes
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_grub
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_local-debs
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_local-hooks
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_local-includes
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_local-packageslists
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_local-udebs
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_rootfs
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 binary_syslinux
       -rw-r--r-- 1 user user 2051 Sep  7 13:02 bootstrap
       -rw-r--r-- 1 user user 1647 Sep  7 13:02 chroot
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_apt
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-hooks
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-includes
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-packages
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-packageslists
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-patches
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_local-preseed
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 chroot_sources
       -rw-r--r-- 1 user user 2954 Sep  7 13:02 common
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 includes
       -rw-r--r-- 1 user user  205 Sep  7 13:02 source
       drwxr-xr-x 2 user user 4096 Sep  7 13:02 templates

    L'utilisation de lb config sans aucun argument serait approprié pour les utilisateurs qui ont besoin d'une image de base, ou qui ont l'intention d'offrir plus tard, une configuration plus complète via auto/config (voir Gestion d'une configuration pour plus de détails).

    Normalement, vous voulez spécifier certaines options. Par exemple, pour inclure la liste du paquet «gnome» dans votre configuration:

       $ lb config -p gnome

    Il est possible de spécifier plusieurs options, telles que:

       $ lb config --binary-images net --hostname live-machine --username live-user ...

    Une liste complète des options est disponible dans la page de manuel de lb_config.

    5.1.2 La commande lb build

    La commande lb build lit dans votre configuration à partir du répertoire config/. Il exécute alors les commandes de niveau inférieur nécessaires pour construire votre système Live.

    5.1.3 La commande lb clean

    Le travail de la commande lb clean est enlever les différentes parties d'une construction afin que autres compilations ultérieures puissent commencer à partir d'un état propre. Par défaut, les stades chroot, binary et source sont nettoyées, mais la cache est laissé intact. En outre, les étapes individuelles peuvent être nettoyées. Par exemple, si vous avez effectué des changements qui affectent uniquement la phase binaire, utilisez lb clean --binary avant de construire un nouveau binaire. Voir la page de manuel de lb_clean pour une liste complète des options.

    5.2 Le paquet live-boot

    live-boot est une collection de scripts fournissant hooks pour initramfs-tools, utilisé pour générer un initramfs capable de démarrer des systèmes live, comme ceux créés par live-build. Cela inclut les ISOs de Debian Live, netboot tarballs, et les images clé USB.

    Au démarrage il va chercher un support en lecture seule qui contient un répertoire «/live» où un système de fichiers racine (souvent une image de système de fichiers compressé comme squashfs) est stocké. S'il est trouvé, il va créer un environnement accessible en écriture, en utilisant aufs, afin que systémes similaires à Debian puissent démarrer à partir de ça.

    Plus d'information sur ramfs initial dans Debian peut être trouvé dans le Debian Linux Kernel Handbook à ‹http://kernel-handbook.alioth.debian.org/› dans le chapitre sur initramfs.

    5.3 Le paquet live-config

    live-config se compose des scripts qui s'exécutent au démarrage après live-boot pour configurer le système live automatiquement. Il gère tâches telles que l'établissement du nom d'hôte, paramètres régionaux et le fuseau horaire, la création de l'utilisateur live, l'inhibition des cron jobs et autologin de l'utilisateur live.

    6. Gestion d'une configuration

    Ce chapitre explique comment gérer une configuration d'un système live à partir d'une création initiale, à travers des révisions successives et des versions successives du logiciel live-build et de l'image live lui-même.

    6.1 Utilisez auto pour gérer les modifications de configuration

    Les configurations live sont rarement parfaites du premier coup. Vous aurez probablement besoin de faire une série de révisions jusqu'à ce que vous êtes satisfait. Cependant, des incohérences peuvent se glisser dans votre configuration d'une révision à la prochaine si vous ne faites pas attention. Le principal problème est, une fois qu'une variable est donné une valeur par défaut, cette valeur ne sera pas recalculé à partir d'autres variables qui peuvent changer dans les révisions ultérieures.

    Par exemple, lorsque la distribution est d'abord définie, nombreuses variables sont assignées des valeurs par défaut qui conviennent à cette distribution. Cependant, si vous décidez ultérieurement de modifier la distribution, ces variables dépendantes conservent les anciennes valeurs qui ne sont plus appropriés.

    Un deuxième problème connexe est que si vous exécutez lb config et ensuite mettez à jour une nouvelle version de live-build qui a changé l'un des noms de variables, vous découvrirez ce que par un examen manuel des variables dans votre config/* fichiers, que vous devrez ensuite utiliser pour définir l'option appropriée à nouveau.

    Tout cela serait une nuisance terrible si ce n'était pas pour les scripts auto/* simples emballages pour les commandes lb config, lb build et lb clean qui sont conçus pour vous aider gérer votre configuration. Il suffit de créer un script auto/config contenant la commande lb config avec toutes les options désirées, et un auto/clean qui supprime les fichiers contenant les valeurs des variables de configuration, et chaque fois que vous lb config et lb clean, ces fichiers seront exécutés. Cela permettra d'assurer que votre configuration a une cohérence interne d'une révision à l'autre et d'une version de live-build à la suivante (même si vous aurez encore de prendre soin et lire la documentation lorsque vous faites un mise à niveau et faites les ajustements nécessaires ).

    6.2 Exemples de scripts auto

    Utiliser des exemples de scripts auto tels que les suivants comme point de départ pour votre nouveau configuration de live-build. Prenez note que lorsque vous appelez la commande lb que votre script auto emballage vous devez spécifier noauto comme paramètre afin de s'assurer que le script automatique n'est pas appelé à nouveau, de façon récursive. Aussi, n'oubliez pas de s'assurer que les scripts sont exécutables (par exemple chmod 755 auto/*).

    auto/config

       #!/bin/sh
       lb config noauto \
           --packages-lists "standard" \
           "${@}"

    auto/clean

       #!/bin/sh
       lb clean noauto "${@}"
       rm -f config/binary config/bootstrap \
           config/chroot config/common config/source
       rm -f binary.log

    auto/build

       #!/bin/sh
       lb build noauto "${@}" 2>&1 | tee binary.log

    Nous expédions maintenant scripts auto d'exemple avec live-build sur la base des exemples ci-dessus. Vous pouvez copier ces comme point de départ.

       $ cp /usr/share/live/build/examples/auto/* auto/

    Editer auto/config, en changeant ou en ajoutant des options comme bon vous semble. Dans l'exemple ci-dessus, --packages-lists standard est fixé à la valeur par défaut. Changez ce à une valeur appropriée pour votre image (ou le supprimer si vous voulez utiliser par défaut) et ajouter des options supplémentaires dans les lignes de continuation qui suivent.

    7. Vue d'ensemble de la personnalisation

    Ce chapitre donne un aperçu des diverses façons dont vous pouvez personnaliser un système Debian Live.

    7.1 Configuration pendant la construction vs. le démarrage

    Les options de configuration d'un système live sont divisés en options au moment de la construction, ces options sont appliqués pendant la création et des options au moment du démarrage, qui sont appliqués au moment du démarrage. Les options au moment du démarrage sont divisées en celles qui surviennent au début, appliquées par le paquet live-boot, et ceux qui arrivent plus tard, appliquées par live-config. Toute option de démarrage peut être modifiée par l'utilisateur en le spécifiant à l'invite de démarrage. L'image peut également être construite avec les paramètres de démarrage par défaut et alors les utilisateurs peuvent normalement démarrer directement au système live sans spécifier aucune option lorsque toutes les valeurs par défaut sont appropriées. En particulier, l'argument lb --bootappend-live se compose de toutes les options de ligne de commande du kernel par défaut pour le système live, comme la persistance, claviers, ou de fuseau horaire. Voir Personnalisation des paramètres régionaux et la langue, par exemple.

    Les options de configuration pendant la construction sont décrites dans les pages de manuel pour live-boot and live-config. Bien que les paquets live-boot et live-config sont installés dans le système live que vous construisez, il est recommandé que vous les installez aussi sur votre système de construction pour référence facile lorsque vous travaillez sur votre configuration. On peut faire ça sans danger, car aucun des scripts contenus dans eux sont exécutés à moins que le système est configuré comme un système live.

    7.2 Étapes de la construction

    Le processus de construction est divisé en étapes, avec des personnalisations différentes appliquées dans l'ordre dans chaque étape. La première étape à exécuter est l'étape bootstrap. C'est la phase initiale de peupler le répertoire chroot avec des paquets pour faire un système Debian de base. Il est suivi par l'étape chroot, qui complète la construction du répertoire chroot, le peuplant de tous les paquets listés dans la configuration, ainsi que tout autre matériel. La plupart de personnalisation de contenu se produit à ce stade. La dernière étape de la préparation de l'image live est l'étape binary, qui construit une image démarrable, en utilisant le contenu du répertoire chroot pour construire le système de fichiers racine pour le système Live, et dont l'installateur et tout autre matériel supplémentaire sur les supports objectif en dehors du système de fichiers du système live. Après l'image live est construite, s'il est activé, l'archive source est construit dans l'étape source.

    Dans chacune de ces étapes, il ya une séquence particulière dans laquelle les commandes sont appliquées. Ce sont disposées de telle manière à assurer que les personnalisations peuvent être superposées de manière raisonnable. Par exemple, dans l'étape chroot, preseeds sont appliqués avant tous les paquets sont installés, les paquets sont installés avant tout les fichiers localement inclus ou les patches sont appliqués, et les hooks sont exécutés plus tard, après que tous les matériaux sont en place.

    7.3 Supplément lb config avec des fichiers

    Bien que lb config crée une configuration du squelette dans le répertoire config/, pour accomplir vos objectifs, vous pourriez avoir besoin de fournir des fichiers supplémentaires dans les sous-répertoires de config/. Selon l'endroit où les fichiers sont stockés dans la configuration, ils peuvent être copiés dans le système de fichiers du système live ou dans le système de fichiers de l'image binaire, ou peut fournir configurations du système au moment de la construction qui serait lourd de passer comme options de la ligne de commande. Vous pouvez inclure des choses telles que des listes personnalisées de paquets, art personnalisé, ou des scripts hook à exécuter, soit au temps de construction ou au moment du démarrage, augmentant la flexibilité déjà considérable de debian-live avec code de votre choix.

    7.4 Tâches de personnalisation

    Les chapitres suivants sont organisés par les types des tâches de personnalisation que les utilisateurs effectuent généralement: Personnalisation de l'installation de paquets, Personnalisation des contenus et Personnalisation des paramètres régionaux et la langue couvrent quelques choses que vous pourriez vouloir faire.

    8. Personnalisation de l'installation de paquets

    La personnalisation la plus fondamentale d'un système Debian Live peut-être la sélection de paquets à inclure dans l'image. Ce chapitre vous guide tout au long des différents options dans certains moments de la construction pour personnaliser l'installation des paquets de live-build. Le plus large choix influençant les paquets qui sont disponibles pour l'installation dans l'image sont les zones de distribution et archive areas. Afin de garantir des vitesses de téléchargement décent, vous devez choisir un miroir de distribution proche. Vous pouvez également ajouter vos propres référentiels pour les backports, paquets expérimentaux ou personnalisés, ou inclure des paquets directement en tant que fichiers. Vous pouvez définir vos propres listes de paquets à inclure, utiliser des listes prédéfinies de live-build, utiliser tâches tasksel, ou une combinaison des trois. Enfin, un certain nombre d'options donnent un certain contrôle sur apt, ou si vous préférez, aptitude, au moment de la construction quand les paquets sont installés. Vous pouvez trouver ces très pratique si vous utilisez un proxy, vous voulez désactiver l'installation des paquets recommandés pour économiser l'espace, ou avez besoin de contrôler quels versions des paquets sont installés via APT pinning, pour n'en nommer quelques possibilités.

    8.1 Sources des paquets
    8.1.1 Distribution, archive areas et mode

    La distribution que vous choisissez a le plus large impact sur les paquets qui sont disponibles à inclure dans votre image live. Indiquez le nom de code, qui est par défaut squeeze pour la version de live-build dans Squeeze. Toute distribution actuelle dans l'archive Debian peut être spécifié par son nom de code ici. (Voir Termes pour plus de détails.) L'option --distribution non seulement influence la source des paquets dans l'archive, mais aussi dit live-build comme it doit construire chaque distribution supportée. Par exemple, pour construire contre *unstable*, Sid, précisez:

       $ lb config --distribution sid

    Dans l'archive de distribution, les «archive areas» sont les principales divisions de l'archive. Dans Debian, ce sont main, contrib et non-free. Seulement main contient des logiciels qui font partie de la distribution Debian, donc qui est la valeur par défaut. Une ou plusieurs valeurs peuvent être spécifiées, par exemple

       $ lb config --archive-areas "main contrib"

    Support expérimental est disponible pour certains dérivés de Debian par l'option --mode. L'option debian est définie par défaut, même si vous êtes en créant sur un système non-Debian. Si vous spécifiez --mode ubuntu ou --mode emdebian, les noms de distribution et des archive areas pour les dérivés spécifiés sont supportés au lieu de ceux de Debian. Le mode modifie également le comportement de live-build en fonction des dérivés.

    Remarque: Les projets pour lesquels ces modes ont été ajoutés sont principalement responsables de aider les utilisateurs de ces options. Le projet Debian Live, à son tour, fournit un support de développement sur une base des meilleurs efforts seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développé ou supporté nous-mêmes.

    8.1.2 Miroirs de distribution

    L'archive Debian est répliqué à travers un large réseau de miroirs autour du monde pour que les gens dans chaque région peuvent choisir un miroir proche avec la meilleur vitesse de téléchargement. Chacune des options --mirror-* qui régit quel miroir de distribution est utilisée à différents stades de la construction. Rappelez-vous de Etapes de la construction que l'étape *bootstrap* c'est quand le chroot est initialement peuplée par debootstrap avec un système minimal, et l'étape *chroot* c'est quand le chroot utilisé pour construire le système de fichiers du système live est construit. Ainsi, les commutateurs des miroirs correspondants sont utilisées pour ces étapes, et plus tard, dans le *binary* stade les valeurs --mirror-binary et --mirror-binary-security sont utilisées, remplaçant tout miroir utilisé dans une étape antérieure.

    8.1.3 Miroirs de distribution utilisés au temps de construction

    Pour définir les miroirs de distribution utilisés au temps de construction pour pointer vers un miroir local, il suffit de fixer --mirror-bootstrap et --mirror-chroot-security comme suit.

       $ lb config --mirror-bootstrap http://localhost/debian/ \
                   --mirror-chroot-security http://localhost/debian-security/

    Le miroir chroot, spécifiée par --mirror-chroot, par défaut, c'est la valeur --mirror-bootstrap.

    8.1.4 Miroirs de distribution utilisés au moment de l'exécution

    Les options --mirror-binary* régissent les miroirs de distribution placés dans l'image binaire. Ils peuvent être utilisés pour installer des paquets supplémentaires lors de l'exécution du système live. Les valeurs par défaut emploient cdn.debian.net, un service qui choisit un miroir géographiquement proche basé sur le numéro IP de l'utilisateur. C'est un choix approprié lorsque vous ne pouvez pas prédire quel miroir sera mieux pour tous vos utilisateurs. Ou vous pouvez spécifier vos propres valeurs, comme indiqué dans l'exemple ci-dessous. Une image construite avec cette configuration seulement serait approprié pour les utilisateurs sur un réseau où "mirror" est accessible.

       $ lb config --mirror-binary http://mirror/debian/ \
                   --mirror-binary-security http://mirror/debian-security/

    8.1.5 Référentiels additionnels

    Vous pouvez ajouter plus de référentiels, élargir vos choix de paquets au-delà ceux disponibles dans votre distribution objectif. Il peut être, par exemple, pour backports, expérimentaux ou des paquets personnalisés. Pour configurer des référentiels supplémentaires, créer les fichiers config/chroot_sources/your-repository.chroot, et/ou config/chroot_sources/your-repository.binary. Comme avec les options --mirror-*, elles gouvernent les référentiels utilisés dans l'étape *chroot* lors de la construction de l'image, et dans l'étape *binaire*, c'est à dire pour une utilisation au moment de l'exécution du système live.

    Par exemple, config/chroot_sources/live.chroot vous permet d'installer des paquets du référentiel des instantanés debian live au moment de la construction du système live.

       deb http://live.debian.net/ sid-snapshots main contrib non-free

    Si vous ajoutez la même ligne à config/chroot_sources/live.binary, le référentiel sera ajouté à le répertoire /etc/apt/sources.list.d/ de votre système live.

    Si ces fichiers existent, ils seront sélectionnés automatiquement.

    Vous devriez également mettre la clé GPG utilisée pour signer le référentiel dans fichiers config/chroot_sources/your-repository.{binary,chroot}.gpg

    Remarque: certains référentiels de paquets préconfigurés sont disponibles pour une sélection facile grâce à l'option --repository, par exemple pour permettre des instantanés live, une simple commande suffit pour l'activer:

       $ lb config --repository live.debian.net

    8.2 Choisir les paquets à installer

    Il y a un certain nombre de façons de choisir quels paquets live-build va installer dans votre image, couvrant une variété de besoins différents. Vous pouvez tout simplement nommer les paquets individuels à installer, que ce soit avec l'option --packages pour quelques paquets, ou dans une liste de paquets pour un grand nombre de paquets. Vous pouvez également choisir grandes listes prédéfinies de paquets, ou utilisez des tâches APT. Et enfin, vous pouvez placer paquets dans votre arbre config/ qui est bien adapté aux essais de nouveaux paquets ou expérimentaux avant qu'ils ne soient disponibles à partir d'un référentiel.

    8.2.1 Choisir un certain nombre de paquets

    Si le nombre de paquets ajoutée est petit il suffit de spécifier --packages. Par exemple:

       $ lb config --packages "package1 package2 package3"

    Le comportement de live-build pour spécifier un paquet qui n'existe pas est déterminé par votre choix de l'utilité APT. Voir Choisir apt ou aptitude pour plus de détails.

    Si vous avez besoin de spécifier un grand nombre de paquets à installer ou vous avez besoin de flexibilité en ce qui concerne les paquets à installer, utilisez des listes de paquets tel que discuté dans la section suivante, Listes de paquets.

    8.2.2 Listes de paquets

    Les listes de paquets sont un excellent moyen d'exprimer quels paquets doivent être installés. La syntaxe de la liste supporte les fichiers inclus et sections conditionnelles qui les rend facile de construire à partir d'autres listes et de les adapter pour une utilisation dans configurations multiples. Vous pouvez utiliser des listes de paquets prédéfinies, offrant une sélection modulaire de paquets provenantes de chacun des environnements de bureau majeurs et certaines listes de but spécial, ainsi que les autres listes standard sont basées sur elles. Vous pouvez également fournir votre propre liste de paquets, ou utiliser une combinaison des deux.

    8.2.3 Listes de paquets prédéfinies

    La façon la plus simple d'utiliser des listes consiste à spécifier une ou plusieurs listes prédéfinies avec la option --packages-lists. Par exemple:

       $ lb config --packages-lists "gnome-core rescue"

    En plus de ces listes, live-build supporte quatre listes de paquets virtuels: gnome-desktop, kde-desktop, lxde-desktop et xfce-desktop, chacun d'entre eux offrent une sélection plus grande de paquets qui correspond à valeurs par défaut de l'installateur Debian pour ces environnements de bureau. Voir Tâches de bureau et de la langue pour plus de détails.

    Remarque: Les images préconstruites GNOME, KDE, LXDE et XFCE disponibles pour téléchargement à ‹http://live.debian.net› sont construites en utilisant les listes virtuels correspondantes *-desktop.

    L'emplacement par défaut pour les fichiers liste sur votre système est /usr/share/live/build/lists/. Pour déterminer les paquets dans une liste donnée, lire le fichier correspondant, en accordant une attention aux fichiers inclus et les conditionnels tels que décrits dans les sections suivantes.

    8.2.4 Listes de paquets locaux

    Vous pouvez compléter ou remplacer entièrement les listes fournies en utilisant listes de paquets locaux stockées dans config/chroot_local-packageslists/.

    Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un suffixe .list pour être traitées. Les listes locaux de paquets ont toujours priorité sur les listes de paquets distribués avec live-build. Cela peut causer des effets indésirables, nous recommandons donc d'utiliser des noms uniques pour listes de paquets locaux.

    8.2.5 Listes locaux de paquets binaires

    Dans le cas où vous voulez inclure certains paquets .deb dans pool/ de votre support live (sans les installer sur l'image live) vous pouvez avoir besoin d'utiliser des listes à l'aide de listes locaux de paquets binaires stockées dans config/binary_local-packageslists/. Ces supports peuvent être utilisés comme une image d'installation de Debian personnalisés pour les installations hors-ligne.

    Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un suffixe .list pour être traitées.

    8.2.6 Extension d'un liste de paquets fournis à l'aide de «includes»

    Les listes de paquets qui sont incluses avec live-build font un grand usage des «includes». Reportez-vous à ceux-ci dans le répertoire /usr/share/live/build/lists/, car ils servent d'exemples pour savoir comment écrire vos propres listes.

    Par exemple, pour faire une liste qui comprend la liste prédéfinie gnome, plus iceweasel, créer config/chroot_local-packageslists/mygnome.list avec le contenu suivant:

       #include <gnome>
       iceweasel

    8.2.7 Utilisant des conditionnels dans les listes de paquets

    Toutes les variables de configuration de live-build stockées dans config/* (sans le préfixe LB_) peuvent être utilisés dans instructions conditionnelles dans les listes de paquets. Généralement, cela signifie une option lb config majuscule et avec tirets changées en caractères de soulignement. Mais en pratique, c'est seulement ceux qui influencent lasélection des paquets qui font sens, comme DISTRIBUTION, ARCHITECTURE ou ARCHIVE_AREAS.

    Par exemple, pour installer ia32-libs si la --architecture amd64 est spécifié:

       #if ARCHITECTURE amd64
       ia32-libs
       #endif

    Vous pouvez tester pour un certain nombre de valeurs, par exemple pour installer memtest86+ si --architecture i386 ou --architecture amd64 est spécifié:

       #if ARCHITECTURE i386 amd64
       memtest86+
       #endif

    Vous pouvez également tester contre des variables qui peuvent contenir plus d'une valeur, par exemple pour installer vrms si contrib ou non-free est spécifié via --archive-areas:

       #if ARCHIVE_AREAS contrib non-free
       vrms
       #endif

    Un conditionnel peut entourer une directive #include:

       #if ARCHITECTURE amd64
       #include <gnome-full>
       #endif

    L'imbrication des conditionnels n'est pas supportée.

    8.2.8 Tâches

    L'installateur Debian offre l'utilisateur le choix d'un certain nombre de listes présélectionnées de paquets, chacun centré sur un type particulier de système ou d'une tâche pour laquelle un système peut être utilisé, comme «environnement de bureau graphique», «serveur de messagerie» ou «portable». Ces listes sont appelés «tâches» et sont supportés par APT à travers l'option «Task:» Vous pouvez spécifier une ou plusieurs tâches en live-build via l'option --tasks, comme dans l'exemple ci-dessous.

       $ lb config --tasks "mail-server file-server"

    Les tâches principales disponibles dans l'installateur Debian peuvent être listés avec tasksel --list-tasks dans le système live. Le contenu de n'importe quelle tâche, y compris ceux non inclus dans cette liste, peuvent être examinées avec tasksel --task-packages.

    8.2.9 Tâches de bureau et de la langue

    Les tâches de bureau et de la langue sont des cas particuliers. Dans l'installateur Debian, si le milieu a été préparé pour un environnement de bureau particulier, la tâche correspondante sera automatiquement installée. Ainsi, il y a tâches gnome-desktop, kde-desktop, lxde-desktop et xfce-desktop, dont aucun n'est offert dans le menu tasksel. De même, il n'y a pas entrées de menu pour les tâches de les langues, mais le choix de la langue de l'utilisateur lors de l'installation influence le choix des tâches de la langue correspondante.

    En live-build, par conséquent, ces cas particuliers sont également d'une attention particulière, mais avec trois différences notables au moment de l'écriture.

    D'abord, il n'existe aucune disposition fait encore automatiquement pour des tâches de la langue, même si un sous-ensemble de ces packages sont inclus si vous spécifiez lb config --language. Si vous avez besoin de ces tâches, qui comprennent des éléments tels que des polices spécifiques de la lange et des paquets de méthodes d'entrée, vous devez les spécifier dans votre configuration. Par exemple:

       $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"

    En second lieu, live-build supporte *-desktop listes de paquets virtuels pour chacune des saveurs de bureau mentionnés ci-dessus, qui sélectionnent la liste prédéfinie de paquets standard-x11, le correspondant *-desktop et trois tâches supplémentaires: desktop, standard et laptop. Ainsi, par exemple, si vous spécifiez --packages-lists gnome-desktop, il est équivalent à spécifier --packages debian-installer-launcher --packages-lists standard-x11 --tasks "gnome-desktop desktop standard laptop".

    En troisième lieu, si une des tâches de bureau pour ces saveurs sont sélectionnés, soit explicitement par --tasks ou implicitement par --packages-lists, live-build préconfigurera la valeur de bureau correspondante pour l'installateur Debian (si elle est incluse) pour s'assurer qu'il suit ses propres règles pour l'installation de saveurs de bureau différents.

    Remarque: Il existe également une option expérimental --language qui a un objectif qui se chevauche avec des tâches des langues. Pour toute langue pour laquelle il est connu qu'il y a des paquets *-l10n, si --language est spécifié, ces paquets seront installés. Par ailleurs, si tous les modèles syslinux correspondants à la langue sont trouvés, ils seront utilisés au lieu des modèles par défaut en anglais. La sélection des paquets fait par --language est une mauvaise approximation aux tâches de langue, car elle exige que la liste des paquets à inclure par langue sera maintenu en interne en live-build, et d'ailleurs, des langues sont plus complets et flexibles. Cependant, l'aspect syslinux est encore utile. Ainsi, si vous utilisez --bootloader syslinux et des modèles pour la langue spécifiée existe, soit dans /usr/share/live/build/templates/syslinux/ ou config/templates/syslinux/, pensez à utiliser cette option, éventuellement en combinaison avec des tâches pour s'assurer que tous les paquets concernés sont installés. Par exemple:

       $ lb config --language es

    Même ainsi, elle est limitée en ce qu'elle ne supporte que d'une seule langue et un chargeur de démarrage unique. Par conséquent, pour toutes ces raisons, l'avenir de cette option est à l'étude, qui pourrait être remplacé par quelque chose d'entièrement différent dans la prochaine version majeure de live-build.

    8.3 Installation des paquets modifiés ou de tiers

    Tandis qu'il est contre la philosophie de Debian Live, il peut parfois être nécessaire de construire un système live avec des versions modifiées des paquets qui sont dans le référentiel Debian. C'est peut-être de modifier ou soutenir des fonctionnalités supplémentaires, des langues et de la marque, ou même de supprimer des éléments de paquets existants qui sont indésirables. De même, les paquets "de tiers" peuvent être utilisés pour ajouter des fonctionnalités sur mesure et/ou propriétaires.

    Cette section ne couvre pas les conseils concernant la construction ou la maintenance des paquets modifiés. La méthode de Joachim Breitner 'How to fork privately' ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› peut, cependant, être d'intérêt. La création de paquets sur mesure sont couverts dans le Debian New Maintainers' Guide at ‹http://www.debian.org/doc/maint-guide/› et ailleurs

    Il y a deux façons d'installer des paquets personnalisés modifiés:

  • chroot_local-packages
  • En utilisant un référentiel APT personnalisé
  • Utilisant chroot_local-packages est plus simple à réaliser et utile pour les personnalisations ponctuels mais a un certain nombre d'inconvénients, tout en utilisant un réferéntiel personnalisé APT est plus fastidieux à mettre en place.

    8.3.1 Utilisant chroot_local-packages pour installer paquets personnalisés

    Pour installer un paquet personnalisé, il suffit de le copier dans le répertoire config/chroot_local-packages/. Les paquets qui sont dans ce répertoire seront automatiquement installés dans le système live pendant la construction du systéme - vous n'avez pas besoin de les spécifier ailleurs.

    Les paquets doivent être nommés de la manière prescrite. Une façon simple de le faire consiste à utiliser dpkg-name.

    L'utilisation de chroot_local-packages pour l'installation de paquets personnalisés a des inconvénients:

  • Il n'est pas possible d'utiliser secure APT.
  • Vous devez installer tous les paquets appropriés dans le répertoire config/chroot_local-packages/.
  • Il ne se prête pas au stockage de configurations Debian Live dans le contrôle de révision.
  • 8.3.2 Utilisant un référentiel APT pour installer des paquets personnalisés.

    Contrairement à l'utilisation de chroot_local-packages, lorsque vous utilisez un réferéntiel personnalisé APT vous devez vous assurer que vous spécifiez les paquets ailleurs. Voir Choisir les paquets à installer pour plus de détails.

    Si créer un référentiel APT pour installer des packages personnalisés peut sembler un effort inutile, l'infrastructure peut être facilement ré-utilisée à une date ultérieure pour offrir les mises à jour des paquets modifiés.

    8.3.3 Les paquets personnalisés et APT

    live-build utilise apt pour installer tous les paquets dans le système live donc il héritera des comportements de ce logiciel. Un exemple pertinent est que (en supposant une configuration par défaut), étant donné un paquet disponible dans deux référentiels différents avec différents numéros de version, APT choisira d'installer le paquet avec la numéro de version supérieur.

    Pour cette raison, vous pouvez incrémenter le numéro de version dans les fichiers debian/changelog de vos paquets personnalisés pour s'assurer que votre version modifiée est installée en lieu d'une dans les référentiels officiels Debian. Cela peut aussi être atteint en modifiant les préférences de pinning d'APT dans le système live - voir APT pinning pour plus d'informations.

    8.4 Configuration d'APT au moment de la construction

    Vous pouvez configurer APT par un certain nombre d'options appliquées uniquement au moment de la construction. (La configuration d'APT utilisé dans le système live en fonctionnement peut être configurée de façon normale pour un système live, qui est, en incluant les configurations appropriées à config/chroot_local_includes/.) Pour une liste complète, regardez les options commençant par apt dans la page de manuel de lb_config.

    8.4.1 Choisir apt ou aptitude

    Vous pouvez choisir d'utiliser soit apt ou aptitude Quel logiciel est utilisé est régi par l'argument --apt de lb config. Choisissez la méthode du comportement préférée pour l'installation de paquets, la différence notable étant la manière dont les paquets manquants sont traitées.

  • apt: Avec cette méthode, si un paquet manquant est spécifié, l'installation va échouer. C'est le paramètre par défaut.
  • aptitude: Avec cette méthode, si un paquet manquant est spécifié, l'installation va réussir.
  • 8.4.2 Utilisation d'un proxy avec APT

    Une configuration communément requis par APT est pour faire face à la construction d'une image derrière un proxy. Vous pouvez spécifier votre proxy APT avec les options --apt-ftp-proxy ou --apt-http-proxy si nécessaire, par exemple

       $ lb config --apt-http-proxy http://proxy/

    8.4.3 Régler APT pour économiser de l'espace

    Vous pouvez avoir besoin d'économiser de l'espace sur les supports d'images, auquel cas l'un ou l'autre ou les deux options suivantes peuvent être d'intérêt.

    Si vous ne voulez pas inclure les indices de l'APT dans l'image, vous les pouvez omettre avec:

       $ lb config --binary-indices false

    Cela ne influencera les entrées dans /etc/apt/sources.list, mais simplement de savoir si /var/lib/apt contient les fichiers indices ou non. La contrepartie est que APT a besoin de ces indices afin d'opérer dans le système live, alors avant de procéder à apt-cache search or apt-get install, par exemple, l'utilisateur doit faire apt-get update pour créer ces indices.

    Si vous trouvez que l'installation des paquets recommandés gonfle votre image trop, vous pouvez désactiver l'option par défaut d'APT avec:

       $ lb config --apt-recommends false

    La contrepartie ici est que si vous n'installez pas les paquets recommandés par un paquet, c'est-à-dire, "paquets qu'on trouverai avec celui-ci dans toute installation standard" (Debian Policy Manual, section 7.2), certains paquets que vous avez vraiment besoin peuvent être omis. Par conséquent, nous vous suggérons d'examiner la différence de désactiver recommends rend à votre liste de paquets (voir le fichier binary.packages généré par lb build) et re-inclure dans votre liste tous les paquets manquants que vous souhaitez toujours installées. Alternativement, si vous trouvez que vous voulez seulement un petit nombre de paquets recommandés exclus, laissez recommends activé et défini une priorité APT pin négative sur les paquets sélectionnés pour éviter les installér, comme expliqué dans APT pinning.

    8.4.4 Passer des options à apt ou aptitude

    S'il n'y a pas une option lb config pour modifier le comportement d'APT dans la façon dont vous avez besoin, utiliser --apt-options ou --aptitude-options pour passer des options grâce à votre outil APT configuré. Voir les pages de manuel apt et aptitude pour plus de détails

    8.4.5 APT pinning

    Pour le contexte, s'il vous plaît lire d'abord la page de manuel apt_preferences(5). APT pinning peut être configuré soit pour le temps de construction, ou encore pendant l'exécution. Pour le premier, créez config/chroot_apt/preferences. Pour ce dernier, créez config/chroot_local-includes/etc/apt/preferences.

    Imaginons que vous voulez construire un système live Squeeze mais il faut installer tous les paquets live qui finissent dans l'image binaire depuis Sid au moment de la construction. Vous devez ajouter Sid à votre APT sources et le fixer de sorte que seulement les paquets que vous voulez sont installés au temps de construction et tous les autres sont de la distribution du système cible, Squeeze. Ce qui suit devrait accomplir ça:

       $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
       $ cat >>config/chroot_apt/preferences <<END
       Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
       Pin: release n=sid
       Pin-Priority: 600

       Package: *
       Pin: release n=sid
       Pin-Priority: 1
       END

    Remarque: Caractères génériques peuvent être utilisés dans les noms des paquets (par exemple Package: live-*) avec la version 0.8.14 ou supérieure d'Apt. Cela signifie qu'il fonctionne avec Wheezy en utilisant:

      $ lb config --distribution wheezy

    Une priorité pin négative évitera installér un paquet, comme dans le cas où vous ne voulez pas un paquet qui est recommandé par un autre paquet. Supposons que vous construisez une image LXDE en utilisant l'option --packages-lists lxde mais ne veulez pas que l'utilisateur soit invité à stocker les mots de passe wifi dans le trousseau de clés. Cette liste comprend gdm, que dépend de gksu, que à son tour recommends gnome-keyring. Donc, vous voulez omettre le paquet recommandé gnome-keyring. Cela peut être fait en ajoutant la strophe suivante à config/chroot_apt/preferences:

       Package: gnome-keyring
       Pin: version *
       Pin-Priority: -1

    9. Personnalisation des contenus

    Ce chapitre aborde affiner la personnalisation du contenu du système live delà du simple choix des paquets à inclure. Les includes vous permettent d'ajouter ou de remplacer des fichiers arbitraires à votre image Debian Live, les hooks vous permettent d'exécuter des commandes arbitraires à différentes étapes de la construction et au démarrage, et la préconfiguration (preseeding) vous permet de configurer les paquets quand ils sont installés en fournissant des réponses aux questions debconf .

    9.1 Includes

    Bien qu'idéalement un système Debian Live comprendrait les fichiers entièrement fournis par les paquets Debian non modifiés, on convient parfois de fournir ou de modifier certains contenus par le biais de fichiers. Avec les includes, il est possible d'ajouter (ou remplacer) des fichiers arbitraires à votre image live de Debian. live-build prévoit trois mécanismes de leur utilisation:

  • Chroot local includes: Ils vous permettent d'ajouter ou remplacer des fichiers sur le système de fichiers chroot/Live. S'il vous plaît voir Live/chroot local includes pour plus d'informations.
  • Binary local includes: Ils vous permettent d'ajouter ou de remplacer des fichiers dans l'image binaire. S'il vous plaît voir Binary local includes pour plus d'informations.
  • Binary includes: Ils vous permettent d'ajouter ou remplacer des fichiers spécifiques de Debian dans l'image binaire, comme les modèles et les répertoires d'outils. S'il vous plaît voir Binary includes pour plus d'informations.
  • S'il vous plaît voir Termes pour plus d'informations sur la distinction entre les images "Live" et "binaire".

    9.1.1 Live/chroot local includes

    Chroot local includes peuvent être utilisés pour ajouter ou remplacer des fichiers dans le système de fichiers chroot/Live afin qu'ils puissent être utilisés dans le système Live. Une utilisation typique est de peupler le répertoire du squelette de l'utilisateur (/etc/skel) utilisé par le système live pour créer le répertoire home de l'utilisateur Live. Une autre est de fournir des fichiers de configuration qui peuvent être simplement ajoutés ou remplacés à l'image sans traitement, voir Live/chroot local hooks si le traitement est nécessaire.

    Pour inclure des fichiers, il suffit de les ajouter à votre répertoire config/chroot_local-includes. Ce répertoire correspond au répertoire racine (/) du système live. Par exemple, pour ajouter un fichier /var/www/index.html dans le système live, utilisez:

       $ mkdir -p config/chroot_local-includes/var/www
       $ cp /path/to/my/index.html config/chroot_local-includes/var/www

    Votre configuration aura alors le schéma suivant:

       -- config
          [...]
           |-- chroot_local-includes
           |   `-- var
           |       `-- www
           |           `-- index.html
          [...]
           `-- templates

    Chroot local includes sont installés après l'installation de paquets de sorte que les fichiers installés par les paquets sont écrasés.

    9.1.2 Binary local includes

    Pour inclure des matériels tels que des documents ou des vidéos sur le système de fichiers des supports, afin qu'il soit accessible dès l'insertion du support sans avoir à démarrer le système live, vous pouvez utiliser binary local includes. Cela fonctionne de façon similaire aux chroot local includes. Par exemple, supposons que les fichiers ~/video_demo.* sont des vidéos de démonstration du système live décrit par et lié par une page d'index HTML. Copiez simplement le matériel à config/binary_local-includes/ comme suit:

       $ cp ~/video_demo.* config/binary_local-includes/

    Ces fichiers apparaissent maintenant dans le répertoire racine du support live.

    9.1.3 Binary includes

    live-build a certains fichiers standard (comme la documentation) qui sera inclus dans la configuration par défaut sur tous les supports live. Ceci peut être désactivé avec:

       $ lb config --includes none

    Sinon, le matériel sera installé par live-build dans /includes/ par défaut sur le système de fichiers du support, ou bien vous pouvez spécifier un autre chemin avec

    9.2 Hooks

    Les hooks permettent à les commandes être exécutées dans les étapes chroot et binaire de la construction afin de personnaliser l'image.

    9.2.1 Live/chroot local hooks

    Pour exécuter des commandes à l'étape chroot, créer un script hook contenant les commandes dans le répertoire config/chroot_local-hooks. Le hook s'exécutera dans le chroot après le reste de votre configuration chroot a été appliquée, donc n'oubliez pas de vous assurer que votre configuration inclut tous les paquets et les fichiers que votre hook a besoin pour fonctionner. Voir les exemples de scripts chroot hook pour diverses tâches courantes de personnalisation chroot fournis dans /usr/share/live/build/examples/hooks que vous pouvez copier ou symlink pour les utiliser dans votre propre configuration.

    9.2.2 Hooks au moment du démarrage

    Pour exécuter des commandes au moment du démarrage, vous pouvez fournir live-config hooks comme expliqué dans la section "Personnalisation" de sa page de manuel. Examiner les hooks de live-config fournis dans /lib/live/config/, en notant les numéros de séquence. Puis fournir votre propre hook préfixée avec un numéro de séquence appropriée, soit comme un chroot local include dans config/chroot_local-includes/lib/live/config/, ou comme un paquet personnalisé tel que discuté dans Installation des paquets modifiés ou de tiers.

    9.2.3 Binary local hooks

    Pour exécuter des commandes à l'étape binaire, créer un script hook contenant les commandes dans config/binary_local-hooks. Le hook sera exécuté après toutes les autres commandes binaires sont exécutées, mais avant binary_checksums, les dernièrs commandes binaires. Les commandes de votre hook ne s'exécutent pas dans le chroot, afin de prendre soin de ne pas modifier les fichiers en dehors de l'arbre de construction, ou vous pourriez endommager votre système de construction! Voir les exemples de scripts hook binaires pour diverses tâches courantes de personnalisation binaires fournis dans /usr/share/live/build/examples/hooks que vous pouvez copier ou symlink pour les utiliser dans votre propre configuration.

    9.3 Préconfigurer questions de debconf

    Les fichiers dans le répertoire config/chroot_local-preseed sont considérés comme des fichiers de préconfiguration debconf et sont installés par live-build en utilisant debconf-set-selections.

    Pour plus d'informations sur debconf, s'il vous plaît voir debconf(7) dans le paquet debconf.

    10. Personnalisation des comportements au moment de l'exécution

    Toute la configuration qui est fait pendant l'exécution est fait par live-config. Voici quelques options les plus courantes de live-config d'intérêt pour les utilisateurs. Une liste complète de toutes les possibilités peut être trouvée dans la page de manuel de live-config.

    10.1 Personnalisation de l'utilisateur Live

    Une considération importante est que l'utilisateur live est créé par live-boot au démarrage, non pas par live-config au moment de la construction. Ça influence non seulement là où les documents relatifs à l'utilisateur live sont introduits dans votre construction, tel que discuté dans Live/chroot local includes, mais aussi tous les groupes et les autorisations associées à l'utilisateur live.

    Vous pouvez spécifier d'autres groupes pour l'utilisateur live en préconfigurant la valeur debconf passwd/user-default-groups. Par exemple, pour ajouter l'utilisateur live au groupe fuse ajoutez la ligne suivante à un fichier dans le répertoire config/chroot_local-preseed:

       user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse

    10.2 Personnalisation des paramètres régionaux et la langue

    Au démarrage du système live, la langue est impliqué dans trois étapes:

  • la génération des paramètres régionaux
  • réglage de la disposition du clavier pour la console
  • réglage de la disposition du clavier pour X
  • Les paramètres régionaux par défaut pendant la construction d'un système Live sont "locales=en_US.UTF-8". Pour définir les paramètres régionaux qui doivent être générés, utilisez le paramètre locales dans l'option --bootappend-live de lb config, par exemple

       $ lb config --bootappend-live "locales=de_CH.UTF-8"

    Ce paramètre peut également être utilisé à la ligne de commande du noyau. Vous pouvez spécifier des paramètres régionaux par language_country.encoding.

    Tant la console et la configuration du clavier X dépendent du paramètre keyboard-layouts de l'option --bootappend-live. Options valides pour les dispositions des claviers X peuvent être trouvés dans /usr/share/X11/xkb/rules/base.xml (plutôt limitées à des codes des pays à deux lettres). Pour trouver la valeur (les deux caractères), correspondant à une langue essayez de rechercher le nom anglais de la nation où la langue est parlée, par exemple:

       $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
       <name>se</name>

    Pour obtenir les fichiers des paramètres régionaux pour les claviers allemand et suisse allemand dans X utiliser:

       $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"

    Une liste des valeurs valides des claviers pour la console peut être figuré avec la commande suivante:

       $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
           do basename $i | head -c -9; echo; done | sort | less

    Alternativement, vous pouvez utiliser le paquet console-setup, un outil pour vous permettre de configurer la disposition de la console en utilisant définitions X (XKB), vous pouvez alors définir votre clavier plus précisément avec variables keyboard-layouts, keyboard-variant, keyboard-options et keyboard-model; live-boot pourra également utiliser ces paramètres pour la configuration de X. Par exemple, pour mettre en place un système français avec une disposition Français Dvorak (appelée Bepo) sur un clavier TypeMatrix, à la fois dans la console et X11, utilisez:

       $ lb config --bootappend-live \
           "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"

    10.3 Persistance

    Un paradigme d'un Live CD est être un système pré-installé qui se démarre du support en lecture seule, comme un cdrom, où les données et les modifications ne survivent pas aux redémarrages du matériel hôte qui l'exécute.

    Un système Debian Live est une généralisation de ce paradigme et soutient ainsi autres supports, en plus de CDs, mais encore, dans son comportement par défaut, il doit être considéré en lecture seule et toutes les évolutions d'exécution du système sont perdus à l'arrêt.

    La persistance est un nom commun pour les différents types de solutions pour sauver, après un redémarrage, certaines ou toutes les données, de cette évolution pendant l'exécution du système. Pour comprendre comment cela pourrait fonctionner il pourrait être utile de savoir que même si le système est démarré et exécuté à partir d'un support en lecture seule, la modification des fichiers et répertoires sont écrits sur des supports inscriptibles, typiquement un disque ram (tmpfs) et aux disques RAM les données ne survivent pas à un redémarrage.

    Les données stockées sur ce disque virtuel doivent être enregistrées sur un support inscriptible persistant comme un disque dur, une clé USB, un partage réseau ou même une séance d'un CD/DVD multisession (ré)inscriptible. Tous ces supports sont pris en charge dans Debian Live de différentes manières, et tous mais le dernier nécessitent un paramètre de démarrage spéciale à préciser au moment du démarrage: persistent.

    10.3.1 Persistance pleine

    Par «persistance pleine» on entend que plutôt que d'utiliser un tmpfs pour le stockage des modifications au support en lecture seule (avec le système copy-on-write, COW) une partition accessible en écriture est utilisée. Pour utiliser cette fonction une partition avec un système de fichiers accessible en écriture avec l'étiquette "live-rw" doit être fixé sur le système au moment du démarrage et le système doit être démarré avec le paramètre de démarrage "persistent". Cette partition peut être une partition ext2 du disque dur ou sur une clé USB créé avec, par exemple:

       # mkfs.ext2 -L live-rw /dev/sdb1

    Voir aussi Utilisation de l'espace disponible sur une clé USB.

    Si vous avez déjà une partition sur votre dispositif, vous pouvez simplement modifier l'étiquette avec l'un des suivants:

       # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems

    Mais puisque les utilisateurs du système live ne peuvent pas toujours utiliser une partition du disque dur, et considérant que la plupart des clés USB ont des vitesses d'écriture pauvres, «pleine» persistance pourrait également être utilisé avec des fichiers image, si vous pouviez créer un fichier qui représente une partition et mettre cette image fichier, même sur une partition NTFS d'un système d'exploitation étranger, avec quelque chose comme:

       $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
       $ /sbin/mkfs.ext2 -F live-rw

    Ensuite, copiez le fichier live-rw sur une partition accessible en écriture et redémarrer avec le paramètre de démarrage "persistent".

    10.3.2 Montage automatique de Home

    Si lors de l'initialisation une partition (système de fichiers) un fichier image ou une partition étiquetée home-rw est découverte, ce système de fichiers sera monté directement comme /home, permettant ainsi la persistance des fichiers qui appartiennent à l'utilisateur par défaut. Elle peut être combinée avec la persistance complète.

    10.3.3 Instantanés

    Les instantanés sont des collections de fichiers et de répertoires qui ne sont pas montés lors de l'exécution, mais qui sont copiés à partir d'un périphérique persistant à le système (tmpfs) au démarrage et qui sont resynchronisés au redémarrage/arrêt du système. Le contenu d'un instantané pourrait résider sur une partition ou un fichier image (comme les types mentionnés ci-dessus) étiquetés live-sn, mais il est par défaut à une archive cpio simple appelé live-sn.cpio.gz. Comme ci-dessus, au moment du démarrage, les périphériques connectés à le système sont examinés pour voir si une partition ou un fichier nommé comme ça pourrait être trouvé. Une coupure de courant pendant l'exécution pourrait conduire à la perte de données, donc un outil appelé live-snapshot --refresh pourrait être appelé à synchroniser des changements importants. Ce type de persistance, car elle n'écrit pas continuellement dans les supports persistants, est le plus respectueux avec les dispositifs flash et le plus rapide de tous les systèmes de persistance.

    Une version instantané de /home existe aussi, et son étiquette est home-sn.*; elle travaille le même que l'instantané principale, mais il est seulement appliquée à /home.

    Les instantanés ne peuvent pas actuellement gérer la suppression de fichiers, mais la persistance pleine et le montage automatique de home si peuvent le faire.

    10.3.4 SubText persistant

    Si un utilisateur a besoin de multiples stockages persistants du même type pour différents endroits ou l'essai, tel que live-rw-nonwork et live-rw-work, le paramètre de démarrage persistent-subtext utilisé en conjonction avec le paramètre de démarrage persistent permettra multiples mais uniques supports persistants. Un exemple serait le cas si un utilisateur voudrait utiliser une partition persistante étiqueté live-sn-subText il utiliserait les paramètres de démarrage: persistent persistent-subtext=subText.

    10.3.5 Remasterisation partielle

    Les modifications de l'exécution du tmpfs pourraient être recueillies à l'aide de live-snapshot dans une squashfs et ajoutés au CD en remasterisant l'ISO dans le cas des CD-R ou en ajoutant une session à un cd/dvd(rw) multisession; live-boot monte tous les systèmes de fichiers /live dans l'ordre ou avec le paramètre de démarrage du module.

    11. Customizing the binary image

    11.1 Bootloader

    live-build uses syslinux as bootloader by default, which is by default configured to pause indefinitely at its splash screen. To adjust this, you can pass --syslinux-timeout TIMEOUT to lb config. The value is specified in units of seconds. A timeout of 0 (zero) disables the timeout completely. For more information please see syslinux(1).

    11.2 ISO metadata

    When creating an ISO9660 binary image, you can use the following options to add various textual metadata for your image. This can help you easily identify the version or configuration of an image without booting it.

  • LB_ISO_APPLICATION/--iso-application NAME: This should describe the application that will be on the image. The maximum length for this field is 128 characters.
  • LB_ISO_PREPARER/--iso-preparer NAME: This should describe the preparer of the image, usually with some contact details. The default for this option is the live-build version you are using, which may help with debugging later. The maximum length for this field is 128 characters.
  • LB_ISO_PUBLISHER/--iso-publisher NAME: This should describe the publisher of the image, usually with some contact details. The maximum length for this field is 128 characters.
  • LB_ISO_VOLUME/--iso-volume NAME: This should specify the volume ID of the image. This is used as a user-visible label on some platforms such as Windows and Apple Mac OS. The maximum length for this field is 32 characters.
  • 12. Customizing Debian Installer

    Debian Live system images can be integrated with Debian Installer. There are a number of different types of installation, varying in what is included and how the installer operates.

    Please note the careful use of capital letters when referring to the "Debian Installer" in this section - when used like this we refer explicitly to the official installer for the Debian system, not anything else. It is often seen abbreviated to "d-i".

    12.1 Types of Debian Installer

    The three main types of installer are:

    "Regular" Debian Installer: This is a normal Debian Live image with a seperate kernel and initrd which (when selected from the appropriate bootloader) launches into a standard Debian Installer instance, just as if you had downloaded a CD image of Debian and booted it. Images containing a live system and such an otherwise independent installer are often referred to as "combined images".

    On such images, Debian is installed by fetching and installing .deb packages using debootstrap or cdebootstrap, from the local media or some network-based network, resulting in a standard Debian system being installed to the hard disk.

    This whole process can be preseeded and customized in a number of ways; see the relevant pages in the Debian Installer manual for more information. Once you have a working preseeding file, live-build can automatically put it in the image and enable it for you.

    "Live" Debian Installer: This is a Debian Live image with a separate kernel and initrd which (when selected from the appropriate bootloader) launches into an instance of the Debian Installer.

    Installation will proceed in an identical fashion to the "Regular" installation described above, but at the actual package installation stage, instead of using debootstrap to fetch and install packages, the live filesystem image is copied to the target. This is achieved with a special udeb called live-installer.

    After this stage, the Debian Installer continues as normal, installing and configuring items such as bootloaders and local users, etc.

    Note: to support both normal and live installer entries in the bootloader of the same live media, you must disable live-installer by preseeding live-installer/enable=false.

    "Desktop" Debian Installer: Regardless of the type of Debian Installer included, d-i can be launched from the Desktop by clicking on an icon. This is user friendlier in some situations. In order to make use of this, the debian-installer-launcher package needs to be included.

    Note that by default, live-build does not include Debian Installer images in the images, it needs to be specifically enabled with lb config. Also, please note that for the "Desktop" installer to work, the kernel of the live system must match the kernel d-i uses for the specified architecture. For example:

       $ lb config --architecture i386 --linux-flavours 486 \
           --debian-installer live --packages debian-installer-launcher

    12.2 Customizing Debian Installer by preseeding

    As described in the Debian Installer Manual, Appendix B at ‹http://www.debian.org/releases/stable/i386/apb.html›, "Preseeding provides a way to set answers to questions asked during the installation process, without having to manually enter the answers while the installation is running. This makes it possible to fully automate most types of installation and even offers some features not available during normal installations." This kind of customization is best accomplished with live-build by placing the configuration in a preseed.cfg file included in config/binary_debian-installer/. For example, to preseed setting the locale to en_US:

       $ echo "d-i debian-installer/locale string en_US" \
           >> config/binary_debian-installer/preseed.cfg

    12.3 Customizing Debian Installer content

    For experimental or debugging purposes, you might want to include locally built d-i component udeb packages. Place these in config/binary_local-udebs/ to include them in the image. Additional or replacement files and directories may be included in the installer initrd as well, in a similar fashion to Live/chroot local includes, by placing the material in config/binary_debian-installer-includes/.

    Projet

    13. Reporting bugs

    Debian Live is far from being perfect, but we want to make it as close as possible to perfect - with your help. Do not hesitate to report a bug: it is better to fill a report twice than never. However, this chapter includes recommendations how to file good bug reports.

    For the impatient:

  • Always check first the image status updates on our homepage at ‹http://live.debian.net/› for known issues.
  • Always try to reproduce the bug with the most recent versions of live-build, live-boot, and live-config before submitting a bug report.
  • Try to give as specific information as possible about the bug. This includes (at least) the version of live-build, live-boot, and live-config used and the distribution of the live system you are building.
  • 13.1 Known issues

    Because Debian testing and Debian unstable distributions are a moving target, when you specify either as the target system distribution, a successful build may not always be possible.

    If this causes too much difficulty for you, do not build a system based on testing or unstable, but rather, use stable. live-build does always default to the stable release.

    Currently known issues are listed under the section 'status' on our homepage at ‹http://live.debian.net/›.

    It is out of the scope of this manual to train you to correctly identify and fix problems in packages of the development distributions, however, there are two things you can always try: If a build fails when the target distribution is testing, try unstable. If unstable does not work either, revert to testing and pin the newer version of the failing package from unstable (see APT pinning for details).

    13.2 Rebuild from scratch

    To ensure that a particular bug is not caused by an uncleanly built system, please always rebuild the whole live system from scratch to see if the bug is reproducible.

    13.3 Use up-to-date packages

    Using outdated packages can cause significant problems when trying to reproduce (and ultimately fix) your problem. Make sure your build system is up-to-date and any packages included in your image are up-to-date as well.

    13.4 Collect information

    Please provide enough information with your report. At least include the exact version of live-build version where the bug is encountered and steps to reproduce it. Please use common sense and include other relevant information if you think that it might help in solving the problem.

    To make the most out of your bug report, we require at least the following information:

  • Architecture of the host system
  • Version of live-build on the host system
  • Version of live-boot on the live system
  • Version of live-config on the live system
  • Version of debootstrap and/or cdebootstrap on the host system
  • Architecture of the live system
  • Distribution of the live system
  • Version of the kernel on the live system
  • You can generate a log of the build process by using the tee command. We recommend doing this automatically with an auto/build script; (see Managing a configuration for details).

       # lb build 2>&1 | tee build.log

    At boot time, live-boot stores a log in /var/log/live.log (or /var/log/live-boot.log).

    Additionally, to rule out other errors, it is always a good idea to tar up your config/ directory and upload it somewhere (do not send it as an attachment to the mailing list), so that we can try to reproduce the errors you encountered. If this is difficult (e.g. due to size) you can use the output of lb config --dump which produces a summary of your config tree (i.e. lists files in subdirectories of config/ but does not include them).

    Remember to send in any logs that were produced with English locale settings, e.g. run your live-build commands with a leading LC_ALL=C or LC_ALL=en_US.

    13.5 Isolate the failing case if possible

    If possible, isolate the failing case to the smallest possible change that breaks. It is not always easy to do this, so if you can't manage it for your report, don't worry. However, if you plan your development cycle well, using small enough change sets per iteration, you may be able to isolate the problem by constructing a simpler 'base' configuration that closely matches your actual configuration plus just the broken change set added to it. If you have a hard time sorting out which of your changes broke, it may be that you are including too much in each change set and should develop in smaller increments.

    13.6 Use the correct package to report the bug against

    Where does the bug appear?

    13.6.1 At build time whilst bootstrapping

    live-build first bootstraps a basic Debian system with debootstrap or cdebootstrap. Depending on the bootstrapping tool used and the Debian distribution it is bootstrapping, it may fail. If a bug appears here, check if the error is related to a specific Debian package (most likely), or if it is related to bootstrapping tool itself.

    In both cases, this is not a bug in Debian Live, but rather in Debian itself which we can not fix this directly. Please report such a bug against the bootstrapping tool or the failing package.

    13.6.2 At build time whilst installing packages

    live-build installs additional packages from the Debian archive and depending on the Debian distribution used and the daily archive state, it can fail. If a bug appears here, check if the error is also reproducible on a normal system.

    If this is the case, this is not a bug in Debian Live, but rather in Debian - please report it against the failing package. Running debootstrap separately from the Live system build or running lb bootstrap --debug will give you more information.

    Also, if you are using a local mirror and/or any of sort of proxy and you are experiencing a problem, please always reproduce it first by bootstrapping from an official mirror.

    13.6.3 At boot time

    If your image does not boot, please report it to the mailing list together with the information requested in Collect information. Do not forget to mention, how/when the image failed, in Qemu, Virtualbox, VMWare or real hardware. If you are using a virtualization technology of any kind, please always run it on real hardware before reporting a bug. Providing a screenshot of the failure is also very helpful.

    13.6.4 At run time

    If a package was successfully installed, but fails while actually running the Live system, this is probably a bug in Debian Live. However,

    13.7 Do the research

    Before filing the bug, please search the web for the particular error message or symptom you are getting. As it is highly unlikely that you are the only person experiencing a particular problem, there is always a chance that it has been discussed elsewhere, and a possible solution, patch, or workaround has been proposed.

    You should pay particular attention to the Debian Live mailing list, as well as the homepage, as these are likely to contain the most up-to-date information. If such information exists, always include the references to it in your bug report.

    In addition, you should check the current bug lists for live-build, live-boot, and live-config to see whether something similar has been reported already.

    13.8 Where to report bugs

    The Debian Live project keeps track of all bugs in the Debian Bug Tracking System (BTS). For information on how to use the system, please see ‹http://bugs.debian.org/›. You can also submit the bugs by using the reportbug command from the package with the same name.

    In general, you should report build time errors against the live-build package, boot time errors against live-boot, and run time errors against live-config. If you are unsure of which package is appropriate or need more help before submitting a bug report, please send a message to the mailing list and we will help you to figure it out.

    Please note that bugs found in distributions derived from Debian (such as Ubuntu and others) should not be reported to the Debian BTS unless they can be also reproduced on a Debian system using official Debian packages.

    14. Coding Style

    This chapter documents the coding style used in live-boot and others.

    14.1 Compatibility
  • Don't use syntax or semantics that are unique to the Bash shell. For example, the use of array constructs.
  • Only use the POSIX subset - for example, use $(foo) over `foo`.
  • You can check your scripts with 'sh -n' and 'checkbashisms'.
  • 14.2 Indenting
  • Always use tabs over spaces.
  • 14.3 Wrapping
  • Generally, lines are 80 chars at maximum.
  • Use the "Linux style" of line breaks:
  • Bad:

       if foo; then
               bar
       fi

    Good:

       if foo
       then
               bar
       fi

  • The same holds for functions:
  • Bad:

       foo () {
               bar
       }

    Good:

       foo ()
       {
               bar
       }

    14.4 Variables
  • Variables are always in capital letters.
  • Variables that used in lb config always start with LB_ prefix.
  • Internal temporary variables in live-build should start with the _LB_ prefix.
  • Local variables start with live-build __LB_ prefix.
  • Variables in connection to a boot parameter in live-config start with LIVE_.
  • All other variables in live-config start with _ prefix.
  • Use braces around variables; e.g. write ${FOO} instead of $FOO.
  • Always protect variables with quotes to respect potential whitespaces: write "${FOO}" not ${FOO}.
  • For consistency reasons, always use quotes when assigning values to variables:
  • Bad:

       FOO=bar

    Good:

       FOO="bar"

  • If multiple variables are used, quote the full expression:
  • Bad:

       if [ -f "${FOO}"/foo/"${BAR}"/bar ]
       then
               foobar
       fi

    Good:

       if [ -f "${FOO}/foo/${BAR}/bar" ]
       then
               foobar
       fi

    14.5 Miscellaneous
  • Use "|" (without the surround quotes) as a seperator in calls to sed, e.g. "sed -e 's|foo|bar|'" (without "").
  • Don't use the test command for comparisons or tests, use "[" "]" (without ""); e.g. "if [ -x /bin/foo ]; ..." and not "if test -x /bin/foo; ...".
  • Use case wherever possible over test, as it's easier to read and faster in execution.
  • 15. Procedures

    This chapter documents the procedures within the Debian Live project for various tasks that need cooperation with other teams in Debian.

    15.1 Udeb Uploads

    Before commiting releases of a udeb in d-i svn, one has to call:

       $ ../../scripts/l10n/output-l10n-changes . -d

    15.2 Major Releases

    Releasing a new stable major version of Debian includes a lot of different teams working together to make it happen. At some point, the Live team comes in and builds live system images. The requirements to do this are:

  • A mirror containing the released versions for the debian, debian-security and debian-volatile archive which the debian-live buildd can access.
  • The names of the image need to be known (e.g. debian-live-VERSION-ARCH-FLAVOUR.iso).
  • The packagelists need to have been updated.
  • The data from debian-cd needs to be synced (udeb exclude lists).
  • The includes from debian-cd needs to be synced (README.*, doc/*, etc.).
  • Images are built and mirrored on cdimage.debian.org.
  • 15.3 Point Releases
  • Again, we need updated mirror of debian, debian-security and debian-volatile.
  • Images are built and mirrored on cdimage.debian.org.
  • Send announcement mail.
  • 15.3.1 Point release announcement template

    An annoucement mail for point releases can be generated using the template below and the following command:

       $ sed \
           -e 's|%major%|5.0|g' \
           -e 's|%minor%|5.0.2|g' \
           -e 's|%codename%|lenny|g' \
           -e 's|%release_mail%|2009/msg00007.html|g'

    Please check the mail carefully before sending and pass it to others for proof-reading.

       Debian Live images for Debian GNU/Linux %major% updated

       The Debian Live project is pleased to announce the availability of
       updated Live images for its stable distribution Debian GNU/Linux %major%
       (codename "%codename%").

       The images are available for download at:

           <http://cdimage.debian.org/cdimage/release/current-live/>

       This update incorporates the changes made in the %minor% point release,
       which adds corrections for security problems to the stable release
       along with a few adjustments for serious problems. A full list of the
       changes may be viewed at:

           <http://lists.debian.org/debian-announce/%release_mail%>

       It also includes the following Live-specific changes:

        * [INSERT LIVE-SPECIFIC CHANGE HERE]
        * [INSERT LIVE-SPECIFIC CHANGE HERE]
        * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]

       URLs
       ----

       Download location of updated images:

         <http://cdimage.debian.org/cdimage/release/current-live/>

       Projet Debian Live Homepage:

         <http://live.debian.net/>

       The current stable distribution:

         <http://ftp.debian.org/debian/dists/stable>

       stable distribution information (release notes, errata etc.):

         <http://www.debian.org/releases/stable/>

       Security announcements and information:

         <http://www.debian.org/security/>

       About Debian
       -------------

       The Debian Project is an association of Free Software developers who
       volunteer their time and effort in order to produce the completely free
       operating system Debian GNU/Linux.

       About Debian Live
       -----------------

       Debian Live is an official sub-project of Debian which produces Debian
       systems that do not require a classical installer. Images are available
       for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
       filesystem images for booting directly from the internet.

       Contact Information
       -------------------

       For further information, please visit the Debian Live web pages at
       <http://live.debian.net/> or alternatively send mail to
       <debian-live@lists.debian.org>.

    Exemples

    16. Examples

    This chapter covers example builds for specific use cases with Debian Live. If you are new to building your own Debian Live images, we recommend you first look at the three tutorials in sequence, as each one teaches new techniques that will help you use and understand the remaining examples.

    16.1 Using the examples

    To use these examples you need a system to build them on that meets the requirements listed in Requirements and has live-build installed as described in Installing live-build.

    Note that, for the sake of brevity, in these examples we do not specify a local mirror to use for the build. You can speed up downloads considerably if you use a local mirror. You may specify the options when you use lb config, as described in Distribution mirrors used at build time, or for more convenience, set the default for your build system in /etc/live/build.conf. Simply create this file and in it, set the corresponding LB_MIRROR_* variables to your preferred mirror. For example:

       LB_MIRROR_BOOTSTRAP="http://mirror/debian"
       LB_MIRROR_CHROOT="http://mirror/debian"
       LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"

    16.2 Tutorial 1: A standard image

    Use case: Create a simple first image, learning the basics of live-build.

    In this tutorial, we will build a default ISO hybrid Debian Live image containing only base packages (no Xorg) and some Debian Live support packages, as a first exercise in using live-build.

    You can't get much simpler than this:

       $ mkdir tutorial1 ; cd tutorial1 ; lb config

    Examine the contents of the config/ directory if you wish. You will see stored here a skeletal configuration, ready to customize or, in this case, use immediately to build a default image.

    Now, as superuser, build the image, saving a log as you build with tee.

       # lb build 2>&1 | tee binary.log

    Assuming all goes well, after a while, the current directory will contain binary-hybrid.iso. This ISO hybrid image can be booted directly in a virtual machine as described in Testing an ISO image with Qemu and Testing an ISO image with virtualbox-ose, or else imaged onto optical media or a USB flash device as described in Burning an ISO image to a physical medium and Copying an ISO hybrid image to a USB stick, respectively.

    16.3 Tutorial 2: A web browser utility

    Use case: Create a web browser utility image, learning how to apply customizations.

    In this tutorial, we will create an image suitable for use as a web browser utility, serving as an introduction to customizing Debian Live images.

       $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel

    Our choice of LXDE for this example reflects our desire to provide a minimal desktop environment, since the focus of the image is the single use we have in mind, the web browser. We could go even further and provide a default configuration for the web browser in config/chroot_local-includes/etc/iceweasel/profile/, or additional support packages for viewing various kinds of web content, but we leave this as an exercise for the reader.

    Build the image, again as superuser, keeping a log as in Tutorial 1:

       # lb build 2>&1 | tee binary.log

    Again, verify the image is OK and test, as in Tutorial 1.

    16.4 Tutorial 3: A personalized image

    Use case: Create a project to build a personalized image, containing your favourite software to take with you on a USB stick wherever you go, and evolving in successive revisions as your needs and preferences change.

    Since we will be changing our personalized image over a number of revisions, and we want to track those changes, trying things experimentally and possibly reverting them if things don't work out, we will keep our configuration in the popular git version control system. We will also use the best practice of autoconfiguration via auto scripts as described in Managing a configuration.

    16.4.1 First revision

       $ mkdir -p tutorial3/auto
       $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
       $ cd tutorial3

    Edit auto/config to read as follows:

       #!/bin/sh

       lb config noauto \
           --architecture i386 \
           --linux-flavours 686 \
           --packages-lists lxde \
           --packages "iceweasel xchat" \
           "${@}"

    First, --architecture i386 ensures that on our amd64 build system, we build a 32-bit version suitable for use on most machines. Second, we use --linux-flavours 686 because we don't anticipate using this image on much older systems. Third, we've chosen the lxde package list to give us a minimal desktop. And finally, we have added two initial favourite packages: iceweasel and xchat.

    Now, build the image:

       # lb build

    Note that unlike in the first two tutorials, we no longer have to type 2>&1 | tee binary.log as that is now included in auto/build.

    Once you've tested the image (as in Tutorial 1) and are satisfied it works, it's time to initialize our git repository, adding only the auto scripts we just created, and then make the first commit:

       $ git init
       $ git add auto
       $ git commit -a -m "Initial import."

    16.4.2 Second revision

    In this revision, we're going to clean up from the first build, add the vlc package to our configuration, rebuild, test and commit.

    The lb clean command will clean up all generated files from the previous build except for the cache, which saves having to re-download packages. This ensures that the subsequent lb build will re-run all stages to regenerate the files from our new configuration.

       # lb clean

    Now edit auto/config to add the vlc package:

       #!/bin/sh

       lb config noauto \
           --architecture i386 \
           --linux-flavours 686 \
           --packages-lists lxde \
           --packages "iceweasel xchat vlc" \
           "${@}"

    Build again:

      # lb build

    Test, and when you're satisfied, commit the next revision:

       $ git commit -a -m "Adding vlc media player."

    Of course, more complicated changes to the configuration are possible, perhaps adding files in subdirectories of config/. When you commit new revisions, just take care not to hand edit or commit the top-level files in config containing LB_* variables, as these are build products, too, and are always cleaned up by lb clean and re-created with lb config via their respective auto scripts.

    We've come to the end of our tutorial series. While many more kinds of customization are possible, even just using the few features explored in these simple examples, an almost infinite variety of different images can be created. The remaining examples in this section cover several other use cases drawn from the collected experiences of users of Debian Live.

    16.5 A VNC Kiosk Client

    Use case: Create an image with live-build to boot directly to a VNC server.

    Make a build directory and create a skeletal configuration in it built around the standard-x11 list, including gdm3, metacity and xtightvncviewer, disabling recommends to make a minimal system:

       $ mkdir vnc_kiosk_client
       $ cd vnc_kiosk_client
       $ lb config -a i386 -k 686 -p standard-x11 \
           --packages "gdm3 metacity xvnc4viewer" \
           --apt-recommends false

    Create the directory /etc/skel and put a custom .xsession in it for the default user that will launch metacity and start xvncviewer, connecting to port 5901 on a server at 192.168.1.2:

       $ mkdir -p config/chroot_local-includes/etc/skel
       $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
       #!/bin/sh

       /usr/bin/metacity &
       /usr/bin/xvncviewer 192.168.1.2:1

       exit
       END

    Build the image:

       # lb build

    Enjoy.

    16.6 A base image for a 128M USB key

    Use case: Create a standard image with some components removed in order to fit on a 128M USB key with space left over to use as you see fit.

    When optimizing an image to fit a certain media size, you need to understand the tradeoffs you are making between size and functionality. In this example, we trim only so much as to make room for additional material within a 128M media size, but without doing anything to destroy integrity of the packages contained within, such as the purging of locale data via the localepurge package, or other such "intrusive" optimizations. Of particular note, you should not use --bootstrap-flavour minimal unless you really know what you're doing, as omitting priority important packages will most likely produce a broken live system.

       $ lb config -k 486 -p minimal --binary-indices false \
           --memtest none --apt-recommends false --includes none

    Now, build the image in the usual way:

       # lb build 2>&1 | tee binary.log

    On the author's system at time of writing, the above configuration produced a 78Mbyte image. This compares favourably with the 166Mbyte image produced by the default configuration in Tutorial 1.

    The biggest space-saver here, compared to building a standard image on an i386 architecture system, is to select only the 486 kernel flavour instead of the default -k "486 686". Leaving off APT's indices with --binary-indices false also saves a fair amount of space, the tradeoff being that you need to apt-get update before using apt in the live system. Choosing the minimal package list leaves out the large locales package and associated utilities. Dropping recommended packages with --apt-recommends false saves some additional space, at the expense of omitting some packages you might otherwise expect to be there, such as firmware-linux-free which may be needed to support certain hardware. The remaining options shave off additional small amounts of space. It's up to you to decide if the functionality that is sacrificed with each optimization is worth the loss in functionality.

    16.7 A localized KDE desktop and installer

    Use case: Create a KDE desktop image, localized for Brazilian Portuguese and including an installer.

    We want to make an iso-hybrid image for i386 architecture using our preferred desktop, in this case KDE, containing all of the same packages that would be installed by the standard Debian installer for KDE.

    Our initial problem is the discovery of the names of the appropriate tasks. Currently, live-build cannot help with this. While we might get lucky and find this by trial-and-error, there is a tool, grep-dctrl, which can be used to dig it out of the task descriptions in tasksel-data, so to prepare, make sure you have both of those things:

       # apt-get install dctrl-tools tasksel-data

    Now we can search for the appropriate tasks, first with:

       $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
       Task: brazilian-portuguese
       Description: Brazilian Portuguese environment
        This task installs programs, data files, and
        documentation that make it easier for Brazilian Portuguese speakers
        to use Debian.

    By this command, we discover the task is called, plainly enough, brazilian-portuguese. Now to find the related tasks:

       $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
       Task: brazilian-portuguese-desktop
       Description: Brazilian Portuguese desktop
        This task localises the desktop in Brasilian Portuguese.

       Task: brazilian-portuguese-kde-desktop
       Description: Brazilian Portuguese KDE desktop
        This task localises the KDE desktop in Brazilian Portuguese.

    We will use the experimental --language option, as live-build happens to include syslinux templates for pt_BR (see Desktop and language tasks for details). And at boot time we will generate the pt_BR.UTF-8 locale and select the pt-latin1 keyboard layout. Now let's put the pieces together:

       $ mkdir live-pt_BR-kde
       $ cd live-pt_BR-kde
       $ lb config \
           -a i386 \
           -k 486 \
           -p kde-desktop \
           --language pt_BR \
           --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
           --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
           --debian-installer live \
           --packages debian-installer-launcher

    Note that we have included the debian-installer-launcher package to launch the installer from the live desktop, and have also specified the 486 flavour kernel, as it is currently necessary to make the installer and live system kernels match for the launcher to work properly.