Rights: Copyright ©  2006-2012 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


Manuel Debian Live

À 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 modifications
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 des paquets inchangés de Debian «main»
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 À partir du dépôt Debian
3.2.2 À partir du code source
3.2.3 À partir des instantanés
3.3 Installation de live-boot et live-config
3.3.1 À partir du dépôt Debian
3.3.2 À partir du code source
3.3.3 À partir des instantanés

4. Les bases

4.1 Qu'est-ce c'est 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'une 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 HDD
4.6 Utiliser une image HDD
4.6.1 Test d'une image 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 Le paquet 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 Traiter les modifications de configuration
6.1.1 Pourquoi utiliser des scripts auto? Que font-ils?
6.2 Utilisez scripts auto d'exemple
6.3 Cloner une configuration publiée via Git

7. Vue d'ensemble de la personnalisation

7.1 Configuration pendant la construction vs. l'amorçage
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 Dépôts additionnels
8.2 Choisir les paquets à installer
8.2.1 Listes de paquets
8.2.2 Using metapackages
8.2.3 Listes de paquets locaux
8.2.4 Listes locaux de paquets binaires
8.2.5 Générer listes de paquets
8.2.6 Utilisant des conditionnels dans les listes de paquets
8.2.7 Tâches de bureau et de la langue
8.3 Installation des paquets modifiés ou de tiers
8.3.1 Utilisant packages.chroot pour installer paquets personnalisés
8.3.2 Utiliser un dépôt 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 Tweaking APT to save space
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.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 de la langue
10.3 Persistance
10.3.1 Le fichier live-persistence.conf
10.3.2 Utilisation de plusieurs dispositifs de persistance

11. Personnalisation de l'image binaire

11.1 Chargeur d'amorçage
11.2 Métadonnées ISO

12. Personnalisation de l'installateur Debian

12.1 Types de l'installateur Debian
12.2 Personnalisation de l'installateur Debian par préconfiguration
12.3 Personnalisation de contenu pour l'Installateur Debian

Projet

13. Rapporter des bogues

13.1 Problèmes connus
13.2 Reconstruire à partir de zéro
13.3 Utilisez paquets mis à jour
13.4 Recueillir l'information
13.5 Isoler le cas qui échoue, si possible
13.6 Utilisez le paquet adéquat pour rapporter le bogue
13.6.1 Au moment de la construction tandis l'amorçage
13.6.2 Au moment de la construction tandis l'installation de paquets
13.6.3 Au moment du démarrage
13.6.4 Au moment de l'exécution
13.7 Faire les recherches
13.8 Où rapporter les bogues

14. Style du code

14.1 Compatibilité
14.2 Indentation
14.3 Adaptateur
14.4 Variables
14.5 Autres

15. Procédures

15.1 Télécharger Udebs
15.2 Évolutions majeures
15.3 Èvolutions mineures
15.3.1 Dernière évolution mineure d'une version Debian
15.3.2 Modèle pour l'annonce d'une évolution mineure

Exemples

16. Exemples

16.1 En utilisant les exemples
16.2 Tutorial 1: Une image standard
16.3 Tutoriel 2: Un utilitaire de navigateur Web
16.4 Tutoriel 3: Une image personnalisée
16.4.1 Première révision
16.4.2 Deuxième révision
16.5 Un client Kiosk VNC
16.6 Une image de base pour une clé USB de 128M
16.7 Un bureau KDE localisé et installateur

Appendix

17. Style guide

17.1 Guidelines for authors
17.1.1 Linguistic features
17.1.2 Procedures
17.2 Guidelines for translators
17.2.1 Translation hints

Manuel Debian Live

À 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 et particulièrement aux logiciels produits par le projet pour Debian 7.0 "wheezy". Une version mise à jour peut toujours être trouvée à ‹http://live.debian.net/

Tandis ce manuel 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 sur les supports ou sur 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 persistance.

Certaines commandes mentionnées dans le texte doivent être exécutées avec les privilèges de super-utilisateur, qui peuvent être obtenus en devenant super-utilisateur à 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 de 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 vouloir expérimenter avant d'entrer dans les détails. Par conséquent, nous vous suggérons de lire dans l'ordre suivant.

Tout d'abord, lisez ce chapitre À propos de ce manuel dès le début et finissant avec la section Terminologie. Ensuite, sautez aux trois tutoriels à l'avant de 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 soyez 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 un 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 des supports tels que des CD, DVD, ou des clés USB. Certains systèmes peuvent également être démarrés sur 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 démarré sur CD, DVD, clé USB, sur le 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 cible: L'environnement utilisé pour faire fonctionner 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 pendant le processus d'amorçage. 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 d'amorçage: Les paramètres qui peuvent être entrés à l'invite de démarrage afin de modifier le noyau ou live-config.
  • chroot: Le logiciel chroot, chroot(8), nous permet d'exécuter 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 cible: La distribution sur laquelle votre système live sera basée. Ceci peut être diffèrent de la distribution de votre système hôte.
  • stable/testing/unstable: La distribution stable contient la dernière version officielle de Debian. La distribution testing est la prochaine version stable où seulement 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. Tout au long du manuel, nous avons tendance à utiliser les noms de code pour les évolutions majeures, tels que wheezy ou sid, car c'est ce qui est soutenu par les outils eux-mêmes.
  • 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 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 dans le répertoire de niveau supérieur de votre Git checkout 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

    Il est également possible de construire par type de document, par exemple,

    $ make build FORMATS=pdf

    Ou combiner les deux, par exemple:

    $ make build LANGUAGES=it FORMATS=html

    1.4.1 Appliquer des modifications

    Les contributions au dépôt sont possibles pour tout le monde. Cependant, nous vous demandons d'envoyer les changements importants sur la liste de diffusion au préalable. Afin de faire un push au dépôt, 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 les changements sur la branche debian-next, pas sur la branche debian.
  • Ne pas utiliser make commit à moins que vous mettez à jour les traductions dans le commit, et dans ce cas, ne pas mélanger les modifications apportées au manuel en anglais et les traductions dans la même livraison, mais utiliser commits séparés. Voir la section Traduction pour plus de détails.
  • Veuillez écrire les commentaires du commit à l'aide de phrases complètes, en commençant par une majuscule et en terminant par un point, et avec la forme '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 commencer la traduction d'une nouvelle langue, suivez ces é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 .po traduits à la liste de diffusion afin que l'équipe de traduction puisse vérifier leur intégrité.
  • Pour activer une nouvelle langue dans l'autobuild il suffit d'ajouter les premiers fichiers traduits à manual/po/${LANGUAGE}/ et lancer make commit. Et alors modifier manual/_sisu/home/index.html.
  • Une fois la nouvelle langue est ajoutée, vous pouvez continuer avec la traduction des fichiers po dans manual/po/ de façon aléatoire.
  • N'oubliez pas que vous devez faire un make commit pour assurer que la traduction des manuels est mise à jour à partir des fichiers po, alors vous pouvez réviser vos modifications avec make build avant git add ., git commit -a -m "Translating..." et git push.
  • Remarque: Vous pouvez utiliser make clean pour nettoyer votre arbre git avant de faire un push. Cette étape n'est pas obligatoire grâce au fichier .gitignore mais c'est une bonne pratique pour éviter d'envoyer certains fichiers involontairement.

    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 était 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:

  • Ils ne sont pas des projets de Debian, et donc ils manquent de soutien au sein de Debian.
  • Ils mélangent des distributions différentes p. ex testing et unstable.
  • Ils soutiennent seulement i386.
  • Ils modifient le comportement et/ou l'apparence des paquets en les dépouillant pour économiser de l'espace.
  • Ils comprennent des paquets provenant en dehors de l'archive Debian.
  • Ils offrent noyaus personnalisés avec des correctifs 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 live pour montrer autour et pour représenter le vrai, seul et unique système Debian avec les principaux avantages suivants:

  • Il est un sous-projet de 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 qui ne sont pas dans l'archive Debian.
  • Il utilise un noyau Debian inchangé sans correctifs supplémentaires.
  • 2.2 Philosophie
    2.2.1 Seulement des paquets inchangés de Debian «main»

    Nous seulement utiliserons les paquets du dépôt Debian dans la section «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 dépôt 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érente, nous le ferons en coordination avec le responsable du paquet dans Debian.

    Un système de configuration des paquets est fourni avec debconf permettant la personnalisation des paquets installés sur votre image Debian Live, mais pour les images officielles seulement une configuration par défaut sera utilisée . 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. Ces changements essentiels doivent être maintenus aussi minimes que possible et devraient être fusionnés au sein du dépôt 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 de 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 bogues rapportés par les utilisateurs et les développeurs. Chaque bogue reçoit un numéro, et il est conservé jusqu'à ce qu'il est marqué comme traité. Pour plus d'informations, s'il vous plaît voir Rapporter des bogues.
  • 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 ou 3.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 dans un certain nombre de façons différentes:

  • À partir du dépôt Debian
  • À partir du code source
  • À partir des instantanés
  • Si vous utilisez Debian, la méthode recommandée consiste à installer live-build à partir du dépôt Debian.

    3.2.1 À partir du dépôt 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 À partir du 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 les 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 à partir des sources, vous pouvez utiliser des instantanés. Ils sont construits automatiquement à partir de la dernière version du dépôt Git et ils sont disponibles à ‹http://live.debian.net/debian/›.

    3.3 Installation de 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. Si vous voulez seulement la documentation, vous pouvez maintenant installer les paquets live-boot-doc et live-config-doc séparément.

    3.3.1 À partir du dépôt Debian

    Tous deux live-boot et live-config sont disponibles dans le dépôt Debian comme expliqué dans Installation de live-build.

    3.3.2 À partir du 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 à partir des sources.

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

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

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

  • Utilisez les fichiers .deb générés nécessaires.
  • Comme live-boot and live-config sont installés par le système de construction live-build, l'installation de ces paquets dans le système hôte ne suffit pas: vous devez traiter les fichiers .deb générés comme d'autres paquets personnalisés. Comme votre objectif pour la construction à partir du code source est tester nouvelles choses à court terme avant la publication officielle, suivez Installation de paquets modifiés ou de tiers pour inclure temporairement les pertinents dans votre configuration. En particulier, remarquez que les deux paquets sont divisés en une partie générique, une partie de documentation et un ou plusieurs back-ends. Inclure la partie générique, un seul back-end et éventuellement la documentation. En supposant que vous construisez une image live dans le répertoire courant et avez généré tous les fichiers .deb pour une version unique de deux paquets dans le répertoire ci-dessus, ces commandes bash seraient pour copier tous les paquets concernés, y compris par défaut les back-ends:

    $ cp ../live-boot{_,-initramfs-tools,-doc}*.deb  config/packages.chroot/
    $ cp ../live-config{_,-sysvinit,-doc}*.deb  config/packages.chroot/

    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 dépôt de tiers dans votre répertoire de configuration de live-build. En supposant que vous avez déjà créé un arbre de configuration dans le répertoire courant avec lb config:

    $ lb config --archives 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 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é pour tous ceux qui ne connaissent pas déjà le démarrage sur 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 c'est 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, une clé USB ou d'un réseau, prêt à l'emploi sans aucune installation sur le disque habituel, 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:

  • Image du noyau Linux, d'habitude appelé vmlinuz*
  • Image du RAM-disque initial (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.
  • Image du système: 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» soit utilisée (voir Persistance).
  • Chargeur d'amorçage: 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/configurations. Il charge le noyau 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 un disque dur ou une clé USB à partir d'une partition VFAT, extlinux pour partitions ext2/3/4 et btrfs, pxelinux pour netboot PXE, GRUB pour partitions ext2/3/4, etc.
  • Vous pouvez utiliser live-build pour construire l'image du système à partir de vos spécifications, configurer un noyau Linux, son initrd, et un chargeur d'amorçage pour les exécuter, tout dans un format en fonction du support (image ISO9660, image disque, 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 sur ‹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'une 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 logiciel équivalent. Brancher une clé USB avec une capacité suffisamment grande pour votre fichier image et déterminez quel dispositif elle 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 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 la 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 du démarrage par PXE, une certaine configuration dans le BIOS de votre ordinateur peut être d'abord nécessaire. Puisque 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 touche 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 rescue des images précompilées, 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 y a 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 y a 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, vous 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 soutient. 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.

    $ echo virtualbox-ose-guest-x11 >> config/package-lists/my.list.chroot

    4.5 Construction d'une image HDD

    La construction d'une image HDD est similaire à une ISO hybride à tous les régards, sauf que vous spécifiez -b 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ée à cette fin au lieu, mais si vous avez un BIOS qui ne gère pas correctement les 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 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 HDD:

    $ lb config -b 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 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 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 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 que votre système hôte a besoin, 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 tel 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 quelle partition, mais la première. Certaines solutions à ce problème ont été discutées 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ée par le contenu de l'image, vous devez sauvegarder votre partition supplémentaire d'abord la restaurer à nouveau après la mise à jour de l'image live.

    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 peut être démarrée sur le réseau.

    Remarque: Si vous avez réalisé quelque des 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 HDD le démarrage sur le réseau 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 du système de fichiers sera située au moment du démarrage. Assurez-vous que ceux-ci sont fixées à 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 d'amorçage 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.netboot.tar.xz dans le répertoire /srv/debian-live, vous trouverez l'image du système de fichiers dans live/filesystem.squashfs et le noyau, initrd et le chargeur d'amorçage pxelinux dans tftpboot/debian-live/i386.

    Nous devons maintenant configurer trois services sur le serveur pour activer le démarrage sur le réseau: 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 client du système du démarrage sur le réseau, et pour annoncer l'emplacement du chargeur d'amorçage 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 noyau 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 noyau 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 indiquer au serveur NFS sur cette exportation avec la commande suivante:

    # exportfs -rv

    La configuation de ces trois services peut être un peu dificile. 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 y a 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 Le paquet 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 à ceux dans 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 une arborescence de configuration, 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 une arborescence de configuration.

    Exécuter lb config sans aucun argument crée un sous-répertoire config/ dont il remplit avec certains paramètres, et un sous-répertoire auto/ avec une arborescence de fichiers.

    $ lb config
    [2012-08-03 22:59:17] lb_config
    P: Considering defaults defined in /etc/live/build.conf
    P: Creating config tree for a debian/i386 system

    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 spécifier la distribution que vous voulez construire en utilisant son nom de code:

    $ lb config --distribution sid

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

    $ lb config --binary-images net --bootappend-live "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/. Elle 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 étapes chroot, binary et source sont nettoyées, mais le cache est laissé intact. En outre, les étapes peuvent être nettoyées individuellement. Par exemple, si vous avez effectué des changements qui affectent uniquement la phase binaire, utilisez lb clean --binary avant de construire un nouveau binary. 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 pour clés 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 du système de fichiers compressée 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 initial ramfs 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 elle-même.

    6.1 Traiter les modifications de configuration

    Les configurations live sont rarement parfaites du premier coup. Il peut être bon de passer des options lb config à partir de la ligne de commande pour effectuer une construction unique, mais il est plus typique de réviser ces options et de construire à nouveau jusqu'à ce que vous êtes satisfait. Afin de soutenir ces changements, vous aurez besoin des scripts automatiques qui assurent que votre configuration est maintenue dans un état cohérent.

    6.1.1 Pourquoi utiliser des scripts auto? Que font-ils?

    La commande lb config enregistre les options que vous lui passez dans les fichiers dans config/* avec beaucoup d'autres options aux valeurs par défaut. Si vous exécutez lb config à nouveau, il ne réinitialisera pas l'option qui a été faite défaut en fonction de vos options initiales. Ainsi, par exemple, si vous exécutez lb config à nouveau avec une nouvelle valeur pour --distribution, toutes les options qui ont été dépendantes par défaut pour l'ancienne distribution ne peuvent plus fonctionner avec les nouveaux. Ces fichiers ne sont pas destinés à être lus ou édités. Ils enregistrent des valeurs pour plus d'une centaine d'options, afin que personne puisse voir dans ces options que vous avez réellement précisée.

    Pour toutes ces raisons, les scripts auto/* vous rendront la vie plus facile. Ils sont simples emballages pour les commandes lb config, lb build et lb clean qui sont conçus pour vous aider à gérer votre configuration. Le script auto/config enregistre votre commande lb config avec toutes les options désirées, le script auto/clean supprime les fichiers contenant les valeurs des variables de configuration, et le script auto/build crée un build.log de chaque construction. Et chaque fois que vous lancez la commande lb correspondante, ces fichiers seront exécutés automatiquement. En utilisant ces scripts, votre configuration est plus facile à lire et a une cohérence interne d'une révision à l'autre. En outre, il sera plus facile pour vous identifier et corriger les options qui doivent changer lorsque vous mettez à niveau live-build après avoir lu la documentation mise à jour.

    6.2 Utilisez scripts auto d'exemple

    Pour votre commodité, live-build est fourni avec shell scripts d'exemple, pour copier et modifier. Lancer une nouvelle configuration par défaut, puis copier les exemples:

    $ mkdir mylive && cd mylive && lb config
    $ cp /usr/share/doc/live-build/examples/auto/* auto/

    Modifier auto/config, ajouter des options comme bon vous semble. Par exemple:

    #!/bin/sh
    lb config noauto \
         --architectures i386 \
         --linux-flavours 686-pae \
         --binary-images hdd \
         --mirror-bootstrap http://ftp.es.debian.org/debian/ \
         --mirror-binary http://ftp.es.debian.org/debian/ \
         "${@}"

    Maintenant, chaque fois que vous utilisez lb config, auto/config réinitialisera la configuration basée sur ces options. Lorsque vous souhaitez effectuer des modifications, modifier les options dans ce fichier au lieu de les passer à lb config. Lorsque vous utilisez lb clean, auto/clean va nettoyer les fichiers ainsi que tous les autres produits de construction. Et enfin, lorsque vous utilisez lb build , un journal de la construction sera écrit par auto/build dans build.log.

    Remarque: Un paramètre spécial noauto est utilisé ici pour en éliminer un autre appel à auto/config, évitant ainsi une récursion infinie. Assurez-vous que vous ne l'avez pas accidentellement supprimé modifiant le fichier. Aussi, prenez soin d'assurer quand vous divisez la commande lb config sur plusieurs lignes pour une meilleure lisibilité, comme le montre l'exemple ci-dessus, que vous n'oubliez pas la barre oblique inverse (\) de sorte que chaque ligne continue à l'autre.

    6.3 Cloner une configuration publiée via Git

    Utilisez l'option lb config --config pour cloner un dépôt Git qui contient une configuration de Debian Live. Si vous souhaitez baser votre configuration sur une maintenue par le projet Debian Live, voir les dépôts avec le préfixe config- sur ‹http://live.debian.net/gitweb

    Par exemple, pour construire une image de récupération, utiliser le dépôt config-rescue comme suit:

    $ mkdir live-rescue && cd live-rescue
    $ lb config --config git://live.debian.net/git/config-rescue.git

    Modifier auto/config et toutes les autres choses dont vous avez besoin dans l'arbre config en fonction de vos besoins.

    Vous pouvez éventuellement définir un raccourci dans votre configuration Git en ajoutant la ligne suivante à votre ${HOME}/.gitconfig:

    [url "git://live.debian.net/git/"]
         insteadOf = ldn:

    Cela vous permet d'utiliser # {ldn:} # partout où vous devez spécifier l'adresse d'un dépôt live.debian.net Si vous supprimez le suffixe optionnel .git, démarrer une nouvelle image en utilisant cette configuration est aussi simple que:

    $ lb config --config ldn:config-rescue

    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. l'amorçage

    Les options de configuration d'un système live sont divisés en options au moment de la construction, ces options sont appliquées pendant la création et des options au moment du démarrage, qui sont appliquées 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 d'amorçage 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 noyau par défaut pour le système live, comme la persistance, les claviers, ou le 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 la personnalisation du 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, il comprend l'installateur et tout autre matériel supplémentaire sur les supports cibles en dehors du système de fichiers du système live. Après l'image live est construite, s'il est activé, le tarball des sources 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. Ceux-ci 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, les preseeds sont appliqués avant tous les paquets sont installés, les paquets sont installés avant tous les fichiers locaux inclus ou les correctifs soient 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 arborescence de configuration 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érentes options dans certains moments de la construction pour personnaliser l'installation des paquets avec 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 les sections (archive areas). Afin de garantir des vitesses de téléchargement décentes, vous devez choisir un miroir de distribution proche. Vous pouvez également ajouter vos propres dépôts pour les backports, paquets expérimentaux ou personnalisés, ou inclure des paquets directement en tant que fichiers. Vous pouvez définir des listes de paquets, incluant les métapaquets qui installent nombreux paquets liés à la fois, telles que les paquets pour un ordinateur de bureau ou langue particulière. 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 wheezy pour la version de live-build dans wheezy. 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 soutenue. 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"

    Soutien expérimental est disponible pour certains dérivés de Debian grâce à 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 areas des archives pour les dérivés spécifiés sont soutenues 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 d'aider les utilisateurs de ces options. Le projet Debian Live, à son tour, fournit un soutien 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 soutenu nous-mêmes.

    8.1.2 Miroirs de distribution

    L'archive Debian est répliqué sur un grand réseau de miroirs autour du monde pour que les habitants dans chaque région puissent choisir un miroir proche avec la meilleur vitesse de téléchargement. Chacune des options --mirror-* régissent quel miroir de distribution est utilisée à différentes étapes de la construction. Rappelez-vous de Étapes 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 l'étape binary 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 , --mirror-chroot-security et --mirror-chroot-backports comme suit.

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

    Le miroir chroot, spécifié 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ée 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 Dépôts additionnels

    Vous pouvez ajouter d'autres dépôts, élargissant votre choix de paquets au-delà ceux disponibles dans votre distribution cible. Il peut être, par exemple, pour backports, expérimentaux ou des paquets personnalisés. Pour configurer des dépôts supplémentaires, créer les fichiers config/archives/your-repository.list.chroot, et/ou config/archives/your-repository.list.binary. Comme avec les options --mirror-*, elles gouvernent les dépôts utilisés dans l'étape chroot lors de la construction de l'image, et dans l'étape binary, c'est à dire pour les utiliser au moment de l'exécution du système live.

    Par exemple, config/archives/live.list.chroot vous permet d'installer les paquets du dépôt 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/archives/live.list.binary, le dépôt sera ajouté au 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 dépôt dans fichiers config/archives/your-repository.key.{binary,chroot}

    Remarque: certains dépôts de paquets préconfigurés sont disponibles pour une sélection facile grâce à l'option --archives, par exemple pour activer les instantanés live, il suffit une simple commande:

    $ lb config --archives live.debian.net

    8.2 Choisir les paquets à installer

    Il y a un certain nombre de façons pour choisir quels paquets live-build installera dans votre image, couvrant une variété de besoins différentes. Vous pouvez tout simplement nommer les paquets individuels à installer dans une liste de paquets. Vous pouvez également choisir métapaquets dans ces listes, ou sélectionner-les en utilisant des champs de paquets de contrôle de fichiers. 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 sur un dépôt.

    8.2.1 Listes de paquets

    Les listes de paquets sont un excellent moyen d'exprimer quels paquets doivent être installés. La syntaxe de la liste soutient les fichiers inclus et sections conditionnelles qui les rend faciles de construire à partir d'autres listes et de les adapter pour une utilisation dans configurations multiples. Les noms des paquets peuvent également être injectés dans la liste en utilisant assistants de shell au moment de la construction.

    Remarque: 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.

    8.2.2 Using metapackages

    La façon la plus simple pour remplir votre liste de paquets consiste à utiliser une tâche métapaquet maintenue par votre distribution. Par exemple:

    $ lb config
    $ echo task-gnome-desktop > config/package-lists/gnome-desktop.list.chroot

    Ceci remplace l'ancienne méthode des listes prédéfinies soutenue dans live-build 2.x. Contrairement aux listes prédéfinies, les métapaquets ne sont pas spécifiques du projet Debian Live. Au lieu de cela, ils sont maintenus par des groupes de travail spécialisés dans la distribution et reflètent donc le consensus de chaque groupe sur les paquets pour mieux servir les besoins des utilisateurs. Ils couvrent également une gamme beaucoup plus large des cas d'utilisation que les listes prédéfinies qu'ils remplacent.

    Tous les métapaquets de tâches sont préfixés avec task-, donc un moyen rapide pour déterminer lesquels sont disponibles (même si elle peut contenir une poignée de faux résultats qui correspondent avec le nom, mais ne sont pas métapaquets) est de faire correspondre le nom du paquet avec:

    $ apt-cache search --names-only ^task-

    En plus, vous trouverez d'autres métapaquets à des fins diverses. Certains sont sous-ensembles de paquets de tâches plus larges, comme gnome-core, tandis que d'autres sont pièces individuelles spécialisées d'un Debian Pure Blend, comme les métapaquets education-*. Pour lister tous les métapaquets dans l'archive, installer le paquet debtags et lister tous les paquets avec le tag role::metapackage comme suit:

    $ debtags search role::metapackage

    8.2.3 Listes de paquets locaux

    Si vous ajoutez métapaquets dans une liste, des paquets individuels ou une combinaison des deux, toutes les listes de paquets locaux sont stockées dans config/package-lists/. Comme plus d'une liste peut être utilisée, cela se prête bien à une conception modulaire. Par exemple, vous pouvez décider de consacrer une liste à un choix particulier de bureau, l'autre à une collection de packages connexes qui pourraient aussi bien être utilisés au-dessus d'un bureau différent. Cela vous permet d'expérimenter avec différentes combinaisons d'ensembles de paquets avec un minimum de tracas en utilisant des listes communes entre les différents projets d'images live.

    Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un suffixe .list pour être traitées, puis un suffixe d'étape supplémentaire .chroot ou .binary pour indiquer à quelle étape la liste est destinée.

    Remarque: Si vous ne spécifiez pas le suffixe de l'étape, la liste sera utilisée pour les deux étapes. Normalement, vous voulez spécifier .list.chroot de sorte que les paquets seront seulement installés dans le système de fichiers live et ne pas avoir une copie supplémentaire des .deb placée sur le support.

    8.2.4 Listes locaux de paquets binaires

    Pour faire une liste pour l'étape binary, placez un fichier avec le suffixe .list.binary dans config/package-lists/. Ces paquets ne sont pas installés dans le système de fichiers live, mais sont inclus sur les supports live sous pool/. Vous utiliserez généralement cette liste avec une des variantes d'installation non-live. Comme mentionné ci-dessus, si vous voulez que cette liste soit la même que votre liste pour l'étape chroot, utilisez simplement le suffixe .list.

    8.2.5 Générer listes de paquets

    Il arrive parfois que la meilleure façon de composer une liste est de la générer avec un script. Toute ligne commençant par un point d'exclamation indique une commande à exécuter dans le chroot lorsque l'image est construite. Par exemple, on pourrait inclure la ligne ! grep-aptavail -n -sPackage -FPriority standard | sort dans une liste de paquets qui permet de produire une liste triée des paquets disponibles avec

    En fait, la sélection des paquets avec la commande grep-aptavail (du paquet dctrl-tools) est si utile que live-build fournit un script Packages à titre de commodité. Ce script accepte deux arguments: field et pattern. Ainsi, vous pouvez créer une liste avec le contenu suivant:

    $ lb config
    $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

    8.2.6 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ées dans instructions conditionnelles dans les listes de paquets. Généralement, cela signifie une option lb config majuscule et avec tirets changés en caractères de soulignement. Mais en pratique, c'est seulement ceux qui influencent la sélection des paquets qui font sens, comme DISTRIBUTION, ARCHITECTURES ou ARCHIVE_AREAS.

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

    #if ARCHITECTURES amd64
    ia32-libs
    #endif

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

    #if ARCHITECTURES 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 ARCHITECTURES amd64
    #include <gnome-full>
    #endif

    L'imbrication des conditionnels n'est pas soutenu.

    8.2.7 Tâches de bureau et de la langue

    Les tâches de bureau et de la langue sont des cas particuliers qui ont besoin d'une certaine planification et de configuration supplémentaire . Dans l'installateur Debian, si le support a été préparé pour un environnement de bureau particulier, la tâche correspondante sera automatiquement installée. Ainsi, il y a tâches internes 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 éléments de menu pour les tâches des langues, mais le choix de la langue de l'utilisateur lors de l'installation influence le choix des tâches de la langue correspondante.

    Lors du développement d'une image de bureau live, l'image généralement amorce directement à un bureau de travail, le choix du environnement de bureau et la langue par défaut ayant été fait au moment de la construction, non pas au moment de l'exécution comme dans le cas de l'installateur de Debian. Cela ne veut pas dire qu'une image live ne pourrait être construite pour soutenir plusieurs environnements de bureau ou de plusieurs langues et offrir à l'utilisateur un choix, mais ce n'est pas le comportement par défaut de live-build.

    Because there is no provision made automatically for language tasks, which include such things as language-specific fonts and input-method packages, if you want them, you need to specify them in your configuration. For example, a GNOME desktop image containing support for Japanese might include these task metapackages:

    $ lb config
    $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
    $ echo "task-japanese task-japanese-desktop task-japanese-gnome-desktop" >> config/package-lists/my.list.chroot

    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 dépôt Debian. C'est peut-être pour modifier ou soutenir des fonctionnalités supplémentaires, des langues et branding, ou même pour supprimer des éléments dans les 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 est traité 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:

  • packages.chroot
  • Utiliser un dépôt APT personnalisé
  • Utilisant packages.chroot est plus simple à réaliser et utile pour les personnalisations ponctuels mais a un certain nombre d'inconvénients, tout en utilisant un dépôt personnalisé APT est plus fastidieux à mettre en place.

    8.3.1 Utilisant packages.chroot pour installer paquets personnalisés

    Pour installer un paquet personnalisé, il suffit de le copier dans le répertoire config/packages.chroot/. 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 packages.chroot 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/packages.chroot/.
  • Il ne se prête pas au stockage de configurations Debian Live dans le contrôle de révision.
  • 8.3.2 Utiliser un dépôt APT pour installer des paquets personnalisés.

    Contrairement à l'utilisation de packages.chroot, lorsque vous utilisez un dépôt 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 dépôt APT pour installer des paquets 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 les comportements de ce logiciel. Un exemple pertinent est que (en supposant une configuration par défaut), s'il y a un paquet disponible dans deux dépôts 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 dépôts officiels Debian. Cela peut aussi être atteint en modifiant les préférences d'APT pinning 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 dans config/includes.chroot/.) 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és.

  • apt: Avec cette méthode, si un paquet manquant est spécifié, l'installation va échouer. C'est le réglage 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 Tweaking APT to save space

    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 d'APT dans l'image, vous les pouvez omettre avec:

    $ lb config --apt-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 ou apt-get install, par exemple, l'utilisateur doit faire apt-get update pour créer ces indices.

    If you find the installation of recommended packages bloats your image too much, provided you are prepared to deal with the consequences discussed below, you may disable that default option of APT with:

    $ lb config --apt-recommends false

    The most important consequence of turning off recommends is that live-boot and live-config themselves recommend some packages that provide important functionality used by most Live configurations, such as user-setup which live-config recommends and is used to create the live user. In all but the most exceptional circumstances you need to add back at least some of these recommends to your package lists or else your image will not work as expected, if at all. Look at the recommended packages for each of the live-* packages included in your build and if you are not certain you can omit them, add them back into your package lists.

    The more general consequence is that if you don't install recommended packages for any given package, that is, "packages that would be found together with this one in all but unusual installations" (Debian Policy Manual, section 7.2), some packages that users of your Live system actually need may be omitted. Therefore, we suggest you review the difference turning off recommends makes to your packages list (see the binary.packages file generated by lb build) and re-include in your list any missing packages that you still want installed. Alternatively, if you find you only want a small number of recommended packages left out, leave recommends enabled and set a negative APT pin priority on selected packages to prevent them from being installed, as explained in 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 à 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 au temps de construction, ou encore pendant l'exécution. Pour le premier, créez config/chroot_apt/preferences. Pour ce dernier, créez config/includes.chroot/etc/apt/preferences.

    Imaginons que vous voulez construire un système live wheezy mais il faut installer tous les paquets live qui finissent dans l'image binaire de 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, wheezy. Ce qui suit devrait accomplir ça:

    $ echo "deb http://mirror/debian sid main" > config/archives/sid.list.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 task-lxde-desktop dans config/package-lists/lxde-desktop.list.chroot mais ne veulez pas que l'utilisateur soit invité à stocker les mots de passe wifi dans le trousseau de clés. Cette liste comprend lxde-core, qui recommande gksu, que à son tour recommande 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 des contenus du système live delà du simple choix des paquets à inclure. Les includes vous permettent d'ajouter ou de remplacer des fichiers arbitraires dans votre image Debian Live, les hooks vous permettent d'exécuter des commandes arbitraires dans 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 des 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 dans votre image live de Debian. live-build prévoit deux mécanismes pour 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.
  • S'il vous plaît voir Termes pour plus d'informations sur la distinction entre les images "Live" et "binary".

    9.1.1 Live/chroot local includes

    Les 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 l'arborescence du répertoir 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/includes.chroot. 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/includes.chroot/var/www
    $ cp /path/to/my/index.html config/includes.chroot/var/www

    Votre configuration aura alors le schéma suivant:

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

    Les chroot local includes sont installés après l'installation de paquets de sorte que les fichiers installés par les paquets sont remplacé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'ils soient accessibles dès l'insertion du support sans 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écrits par et liés par une page d'index HTML. Copiez simplement le matériel dans config/includes.binary/ comme suit:

    $ cp ~/video_demo.* config/includes.binary/

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

    9.2 Hooks

    Les hooks permettent à les commandes être exécutées dans les étapes de la construction chroot et binary 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 avec le suffixe .chroot contenant les commandes dans le répertoire config/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écédé d'un numéro de séquence appropriée, soit comme un chroot local include dans config/includes.chroot/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 avec le suffixe .binary contenant les commandes dans le répertoire config/hooks/. Le hook sera exécuté après toutes les autres commandes binaires soient exécutées, mais avant binary_checksums, la dernière commande binaire. 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 binary hook scripts 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/preseed/ avec le suffixe .preseed suivi de l'étape (.chroot or .binary) 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 faite pendant l'exécution est faite 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 pendant l'étape chroot, ajoutez la ligne suivante à un fichier dans le répertoire config/chroot_local-preseed:

    $ lb config
    $ echo user-setup passwd/user-default-groups string audio cdrom \
       dip floppy video plugdev netdev powerdev scanner bluetooth fuse \
       >> config/preseed/my.preseed.chroot

    Il est également possible de changer le nom de l'utilisateur par défaut «user» et du mot de passe par défaut "live". Si vous voulez pour quelque raison, vous pouvez facilement faire ça comme suit:

    Pour modifier le nom de l'utilisateur par défaut, vous pouvez simplement le spécifier dans votre config:

    $ lb config --bootappend-live "username=live-user"

    Une façon possible de changer le mot de passe par défaut est au moyen d'un hook comme décrit dans Hooks au moment du démarrage. Pour ce faire vous pouvez utiliser le hook "passwd" de /usr/share/doc/live-config/examples/hooks, ajouter un préfixe correct (par exemple 2000-passwd) et l'ajouter à config/includes.chroot/lib/live/config/

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

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

  • la génération des paramètres régionaux
  • le réglage de la disposition du clavier
  • 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, utiliser le paramètre locales dans l'option --bootappend-live de lb config, par exemple

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

    Multiples paramètres régionaux peuvent être spécifiés en une liste séparée par des virgules.

    Ce paramètre, ainsi que les paramètres de configuration du clavier indiqués ci-dessous, peut également être utilisé sur la ligne de commande du noyau. On peut spécifier des paramètres régionaux avec language_country (dans ce cas le codage par défaut est utilisé) ou l'expression complete language_country.encoding. Une liste des paramètres régionaux et le codage pour chacun peuvent être trouvés dans /usr/share/i18n/SUPPORTED.

    La configuration du clavier pour la console et pour X est faite par live-config en utilisant le paquet console-setup. Pour les configurer, utiliser les paramètres de démarrage keyboard-layouts, keyboard-variants, keyboard-options et keyboard-model avec l'option --bootappend-live. On peut trouver options valides dans /usr/share/X11/xkb/rules/base.lst. Pour trouver les dispositions el les variantes correspondantes à une langue essayez de rechercher le nom anglais de la nation où la langue est parlée, par exemple:

    $ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst
    ! model
    ! layout
       ch              German (Switzerland)
    ! variant
       legacy          ch: German (Switzerland, legacy)
       de_nodeadkeys   ch: German (Switzerland, eliminate dead keys)
       de_sundeadkeys  ch: German (Switzerland, Sun dead keys)
       de_mac          ch: German (Switzerland, Macintosh)
    ! option

    Chaque variante présente une description de la disposition appliquée.

    Souvent, seulement la disposition doit être configurée. Par exemple, pour obtenir les fichiers des paramètres régionaux de l'allemand et la disposition du clavier suisse allemand dans X utiliser:

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

    Toutefois, pour les cas d'utilisation très spécifiques, on peut inclure d'autres paramètres. Par exemple, pour mettre en place un système français avec une disposition French-Dvorak (Bepo) avec un clavier USB TypeMatrix EZ-Reach 2030, utiliser:

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

    Plusieurs valeurs peuvent être spécifiées séparées par des virgules pour chacune des options keyboard-*, à l'exception de keyboard-model, qui accepte une seule valeur. S'il vous plaît voir la page de manuel keyboard(5) pour plus de détails et des exemples des variables XKBMODEL, XKBLAYOUT, XKBVARIANT et XKBOPTIONS. Si plusieurs valeurs keyboard-variants sont données, elles seront jumelées tête à tête avec les valeurs keyboard-layouts voir setxkbmap(1) option -variant). On peut utiliser des valeurs vides; par exemple pour regler deux dispositions, une par défaut US QWERTY et l'autre US Dvorak, utiliser:

    $ lb config --bootappend-live \
         "keyboard-layouts=us,us keyboard-variants=,dvorak"

    10.3 Persistance

    Un paradigme d'un Live CD est être un système pré-installé qui amorce sur un 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 pendant l'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 fonctionne il peut ê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 supports de stockage locaux, 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, moins le dernier, nécessitent un paramètre d'amorçage spéciale à préciser au moment du démarrage: persistence.

    Si le paramètre de démarrage persistence est réglé (et nopersistence n'est pas utilisé), les supports de stockage locaux (par exemple les disques durs, clés USB) seront examinés pour trouver des volumes persistants pendant le démarrage. Il est possible de limiter les types de volumes persistants à utiliser en spécifiant certains paramètres de démarrage décrits dans la page de manuel live-boot(7). Un volume persistant est un des éléments suivants:

  • une partition, identifiée par son nom GPT.
  • un système de fichiers, identifié par son étiquette de système de fichiers.
  • un fichier image situé sur la racine d'un système de fichiers en lecture (même une partition NTFS d'un système d'exploitation étranger), identifié par son nom de fichier. Dans ce cas, le nom du fichier doit contenir le nom du système de fichiers comme extension, par exemple, "persistence.ext4".
  • L'étiquette du volume pour les couches de persistence doit être persistence. Et afin de personnaliser entièrement la persistance du volume il doit y avoir un fichier nommé live-persistence.conf. Voir Le fichier live-persistence.conf

    Voici quelques exemples de comment préparer un volume à utiliser pour la persistance. Il peut être, par exemple, une partition ext4 sur un disque dur ou sur une clé usb créée avec, par exemple:

    # mkfs.ext4 -L persistence /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 persistence /dev/sdb1 # for ext2,3,4 filesystems

    Voici un exemple de comment créer un fichier image ext4 utilisé pour la persistance:

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

    Ensuite, copiez le fichier persistence à la racine d'une partition accessible en écriture.

    10.3.1 Le fichier live-persistence.conf

    Un volume avec l'étiquette persistence peut être configuré pour créer des répertoires persistants arbitraires. Le fichier live-persistence.conf, situé sur le système de fichiers racine du volume, contrôle quels répertoires il fait persistants, et de quelle manière.

    Comment on configure monter des couches personnalisées est décrit en détail dans la page de manuel live-persistence.conf(5), mais un simple exemple devrait être suffisant pour la plupart des utilisations. Imaginons que nous voulons faire notre répertoire personnel et APT cache persistants dans un système de fichiers ext4 sur la partition /dev/sdb1:

    # mkfs.ext4 -L persistence /dev/sdb1
    # mount -t ext4 /dev/sdb1 /mnt
    # echo "/home" >> /mnt/live-persistence.conf
    # echo "/var/cache/apt" >> /mnt/live-persistence.conf

    Alors nous redémarrons. Lors du premier démarrage les contenus du /home et /var/cache/apt seront copiés dans le volume persistant, et à partir de ce moment tous les changements dans ces répertoires seront stockés dans le volume persistant. S'il vous plaît souligner que les chemins d'accès aux répertoriés dans le fichier live-persistence.conf ne peuvent pas contenir des espaces blancs ou les éléments spéciaux . et ... En outre, ni /live (ou un de ses sous-répertoires), ni / peuvent être rendus persistants en utilisant montages personnalisés.

    Plusieurs volumes de couches personnalisées différents (avec leurs propres fichiers live-persistence.conf) peuvent être utilisés au même temps, mais si plusieurs volumes font le même répertoire persistant, un seul d'entre eux sera utilisé. Si les deux sont «imbriqués» (un est un sous-répertoire de l'autre) le premier sera monté avant que le secondaire de sorte que aucun sera caché par l'autre. Monter des éléments personnalisés imbriqués est problématique s'ils sont énumérés dans le même fichier live-persistence.conf. Voir la page de manuel live-persistence.conf(5) pour savoir comment gérer ce cas, si vous avez vraiment besoin (remarque: vous n'avez généralement pas).

    10.3.2 Utilisation de plusieurs dispositifs de persistance

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

    11. Personnalisation de l'image binaire

    11.1 Chargeur d'amorçage

    live-build utilise syslinux et certains de ses dérivés (selon le type d'image) comme chargeurs d'amorçage par défaut. Vous pouvez facilement les personnaliser de différentes façons qui vont de fournir un thème complet à changer le délai de démarrage ou tout simplement ajouter une image splash personnalisée. Certains des exemples de personnalisation suivants utilisent méthodes différentes, comme includes ou hooks.

    Si vous souhaitez utiliser un thème complet, vous pouvez spécifier l'option --syslinux-theme (voir man lb_config). live-build téléchargera le thème du miroir et l'installera.

    Imaginez que vous voulez construire un client progress, mais vous voulez inclure le thème du serveur parce que vous voulez avoir le menu d'aide. Ensuite, vous devez lancer lb config comme suit:

    $ lb config --mode progress --syslinux-theme progress-server

    Vous pouvez également créer votre propre thème ou modifier un déjà existant et si vous n'avez pas un miroir, vous pouvez ajouter le paquet à config/packages.chroot. Dans ce cas, il n'est pas nécessaire de spécifier une autre option.

    Il y a aussi la possibilité de faire des petits changements. Par exemple, les dérivés de syslinux sont configurés par défaut avec un timeout de 0 (zéro) qui signifie qu'ils se mettront en pause indéfiniment à leur écran de démarrage jusqu'à ce que vous pressez une touche.

    Pour modifier le délai de démarrage d'une image iso-hybrid, vous pouvez éditer un fichier isolinux.cfg précisant le timeout dans les unités de secondes et l'ajouter à config/includes.binary/isolinux/

    Un isolinux.cfg modifié pour démarrer après cinq secondes ressemblerait à ceci:

    include menu.cfg
    default vesamenu.c32
    prompt 0
    timeout 50

    Une autre façon d'atteindre le même objectif pourrait être écrire un hook et l'ajouter à config/hooks/ N'oubliez pas d'ajouter le suffixe .binary pour l'exécuter dans l'étape binaire. Un exemple proposé:

    #!/bin/sh

    sed -i 's|timeout 0|timeout 50|' binary/isolinux/isolinux.cfg

    Également, si vous souhaitez utiliser une splash.png personnalisée, vous pouvez ajouter une image de 640x480 pixels à config/includes.binary/isolinux/

    11.2 Métadonnées ISO

    En créant une image binaire ISO9660, vous pouvez utiliser les options suivantes pour ajouter différentes métadonnées textuelles pour votre image. Cela peut vous aider à facilement identifier la version ou la configuration d'une image sans la démarrer.

  • LB_ISO_APPLICATION/--iso-application NAME: Cela devrait décrire l'application qui sera sur l'image. Le nombre maximum de caractères pour ce champ est 128.
  • LB_ISO_PREPARER/--iso-preparer NAME: Cela devrait décrire le préparateur de l'image, généralement avec certains détails de contact. Le défaut de cette option est la version de live-build que vous utilisez, ce qui peut faciliter le débogage plus tard. Le nombre maximum de caractères pour ce champ est 128.
  • LB_ISO_PUBLISHER/--iso-publisher NAME: Ce doit décrire l'éditeur de l'image, généralement avec certains détails de contact. Le nombre maximum de caractères pour ce champ est 128.
  • LB_ISO_VOLUME/--iso-volume NAME: Cela devrait spécifier l'ID de volume de l'image. Il est utilisé comme une étiquette visible par l'utilisateur sur certaines plateformes comme Windows et Apple Mac OS. Le nombre maximum de caractères pour ce champ est 128.
  • 12. Personnalisation de l'installateur Debian

    Les images du système Debian Live peuvent être intégrées avec l'installateur Debian. Il y a un certain nombre de types d'installation différents, variant en ce qui est inclus et comment fonctionne l'installateur.

    S'il vous plaît noter l'utilisation prudente des lettres majuscules pour désigner «l'Installateur Debian» dans cette section - lorsqu'il est utilisé comme cela, nous faisons explicitement référence à l'installateur officiel pour le système Debian, pas autre chose. On le voit souvent abrégé en «d-i».

    12.1 Types de l'installateur Debian

    Les trois principaux types de programme d'installation sont:

    Installateur Debian «Régulière»: C'est une image de Debian Live normale avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancen dans une instance d'installateur Debian standard, exactement comme si vous aviez téléchargé une image CD de Debian et la auriez démarrée. Les images contenant un système live et un installateur indépendant sont souvent appelées «images combinées».

    Sur ces images, Debian est installé par l'extraction et l'installation de paquets .deb à l'aide de debootstrap ou cdebootstrap, à partir des supports locaux ou sur le réseau, résultant en un système Debian standard en cours d'installation sur le disque dur.

    Tout ce processus peut être préconfiguré et personnalisé dans un certain nombre de façons, voir les pages correspondantes dans le manuel de l'Installateur Debian pour plus d'informations. Une fois que vous avez un fichier de préconfiguration qui fonctionne live-build peut automatiquement le mettre à l'image et l'activer pour vous.

    Installateur Debian "Live" : C'est une image de Debian Live avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancen dans une instance de l'installateur Debian.

    L'installation continue de manière identique à l'installation «Régulière» décrite ci-dessus, mais à l'étape de l'installation des paquets, au lieu d'utiliser debootstrap pour aller chercher et installer des paquets, l'image du système de fichiers live est copiée vers la cible. Ce résultat est obtenu avec un udeb spécial appelé live-installer.

    Après cette étape, l'installateur Debian continue normalement, en installant et configurant des éléments tels que les chargeurs d'amorçage et les utilisateurs locaux, etc

    Remarque: Pour soutenir les deux options: installateur normal et live dans le chargeur d'amorçage du même support live, vous devez désactiver live-installer en utilisant la préconfiguration live-installer/enable=false.

    Installateur Debian "de bureau": Indépendamment du type d'installateur Debian inclus, d-i peut être lancé à partir du Bureau en cliquant sur une icône. C'est facile à utiliser dans certaines situations. Afin de faire usage de cela, le paquet debian-installer-launcher doit être inclus.

    Notez que par défaut, live-build n'inclut pas les images de l'installateur Debian dans les images, il doit être spécifiquement activé avec lb config. Aussi, s'il vous plaît noter que pour que l'installateur "de bureau" fonctionne le noyau du système live doit correspondre au noyau que d-i utilise pour l'architecture spécifiée. Par exemple:

    $ lb config --architectures i386 --linux-flavours 486 \
         --debian-installer live
    $ echo debian-installer-launcher >> config/package-lists/my.list.chroot

    12.2 Personnalisation de l'installateur Debian par préconfiguration

    Comme décrit dans le Debian Installer Manual, Appendix B at ‹http://www.debian.org/releases/stable/i386/apb.html›, «La préconfiguration est une façon de donner des réponses aux questions posées pendant le processus d'installation, sans avoir à entrer manuellement les réponses alors que l'installation est en marche. Cela permet d'automatiser entièrement la plupart des types d'installation et elle offre certaines fonctionnalités que ne sont pas disponibles pendant les installations normales ». Ce type de personnalisation se fait mieux avec live-build en plaçant la configuration dans un fichier preseed.cfg inclus dans config/binary_debian-installer/. Par exemple, pour préconfigurer les paramètres régionaux pour en_US:

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

    12.3 Personnalisation de contenu pour l'Installateur Debian

    Pour des fins expérimentales ou de débogage, vous pouvez inclure paquets udeb d-i construits localement. Et les placer dans config/packages.binary/ pour les inclure dans l'image. Plusieurs fichiers supplémentaires ou de remplacement et plusieurs répertoires peuvent être inclus dans l'initrd de l'installateur ainsi, d'une manière similaire à Live/chroot local includes en plaçant le matériau dans config/includes.binary_debian-installer/.

    Projet

    13. Rapporter des bogues

    Debian Live est loin d'être parfait, mais nous voulons le rendre aussi proche que possible de parfait - avec votre aide. N'hésitez pas à signaler un bogue. Il est préférable de remplir un rapport deux fois plus que jamais. Toutefois, ce chapitre contient des recommandations pour présenter des rapports de bogues.

    Pour les impatients:

  • Commencez toujours par vérifier les mises à jour de la situation de l'image sur notre page d'accueil ‹http://live.debian.net/› pour voir les problèmes connus.
  • Toujours essayer de reproduire le bogue avec les versions les plus récentes de live-build, live-boot, live-config et live-tools avant de présenter un rapport de bogue.
  • Essayez de donner des informations aussi précises que possible sur le bogue. Cela comprend (au moins) la version de live-build, live-boot, live-config et live-tools, de la distribution utilisée et du système live que vous construisez.
  • 13.1 Problèmes connus

    Parce que les distributions Debian testing et Debian unstable sont une cible mouvante, quand vous les spécifiez comme les distributions du système cible, une construction avec succès n'est pas toujours possible.

    Si cela provoque trop de difficulté pour vous, ne pas construire un système basé sur testing or unstable, mais plutôt utiliser stable. live-build fait toujours défaut à la version stable.

    Les problèmes connus sont énumérés sous la section "status" sur notre page à ‹http://live.debian.net/›.

    Il est hors cadre de ce manuel vous former correctement à identifier et corriger les problèmes dans les paquets des distributions de développement, cependant, il y a deux choses que vous pouvez toujours essayer: Si une construction échoue lorsque la distribution cible est testing, essayez unstable. Si unstable ne fonctionne pas non plus, revenir à testing et fixer la nouvelle version du paquet qui échoue de unstable (voir APT pinning pour plus de détails).

    13.2 Reconstruire à partir de zéro

    Afin de s'assurer que un bogue en particulier n'est pas causé par un système construit malpropre, s'il vous plaît toujours reconstruire l'ensemble du système live à partir de zéro pour voir si le bogue est reproductible.

    13.3 Utilisez paquets mis à jour

    L'utilisation de paquets obsolètes peut causer des problèmes importants en essayant de reproduire (et finalement régler) votre problème. Assurez-vous que votre système de construction est mis à jour et tous les paquets inclus dans votre image sont mis à jour aussi.

    13.4 Recueillir l'information

    S'il vous plaît fournir assez d'informations avec votre rapport. Inclure au moins la version exacte de live-build où le bogue est rencontré et les mesures pour le reproduire. S'il vous plaît utilisez votre bon sens et incluez d'autres renseignements pertinents, si vous pensez que cela pourrait aider à résoudre le problème.

    Pour tirer le meilleur parti de votre rapport de bogue, nous avons besoin d'au moins les informations suivantes:

  • L'architecture du système hôte
  • Version de live-build sur le système hôte
  • Version de live-boot sur le système live
  • Version de live-config sur le système live
  • Version de live-tools sur le système live
  • Version de debootstrap et/ou cdebootstrap sur le système hôte
  • L'architecture du système live
  • Répartition du système live
  • Version du noyau sur le système live
  • Vous pouvez générer un journal du processus de construction en utilisant la commande tee. Nous recommandons de faire cela automatiquement avec un script auto/build (voir Gestion d'une configuration pour les détails).

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

    Au démarrage, live-boot stocke un journal dans /var/log/live-boot.log.

    Par ailleurs, pour écarter d'autres erreurs, c'est toujours une bonne idée faire un tar de votre répertoire config/ et de le télécharger quelque part (ne pas l'envoyer en pièce jointe à la liste de diffusion), de sorte que nous pouvons essayer de reproduire les erreurs que vous rencontrez. Si cela est difficile (en raison par exemple de la taille) vous pouvez utiliser la sortie de lb config --dump qui produit un résumé de votre arbre de config (c'est-à-dire les listes des fichiers dans les sous-répertoires de config/ mais ne les inclut pas).

    N'oubliez pas d'envoyer tous les journaux qui ont été produits avec le paramètre régionaux anglais, par exemple exécuter vos commandes live-build précédées par LC_ALL=C ou LC_ALL=en_US.

    13.5 Isoler le cas qui échoue, si possible

    Si possible, isoler le cas qui échoue au plus petit changement possible. Il n'est pas toujours facile de faire cela, donc si vous ne pouvez pas le gérer pour votre rapport, ne vous inquiétez pas. Toutefois, si vous planifiez votre cycle de développement bien, en utilisant petits ensembles de changements par itération, vous pourriez être capable d'isoler le problème en construisant une configuration simple «base» qui correspond étroitement à la configuration réelle avec seulement le changement cassé ajouté. Si il est difficile de trier vos modifications qui cassent, il est possible que vous y compris trop dans chaque ensemble de modifications et vous devriez developper en petits incréments.

    13.6 Utilisez le paquet adéquat pour rapporter le bogue

    Si vous ne savez pas quel composant est responsable du bogue ou si le bogue est un bogue général concernant les systèmes live, vous pouvez remplir un bogue sur le pseudo-paquet debian-live.

    Toutefois, nous apprécierons si vous essayez de le réduire en fonction de l'endroit où le bogue apparaît.

    13.6.1 Au moment de la construction tandis l'amorçage

    live-build amorce d'abord un système Debian de base avec debootstrap ou cdebootstrap. Selon l'outil d'amorçage utilisé et de la distribution Debian il peut échouer. Si un bogue apparaît ici, vérifiez si l'erreur est liée à un paquet Debian spécifique (plus probable), ou si elle est liée à l'outil d'amorçage lui-même.

    Dans les deux cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans Debian lui-même que probablement nous ne pouvons pas le résoudre directement. S'il vous plaît rapportez un bogue sur l'outil d'amorçage ou du paquet défaillant.

    13.6.2 Au moment de la construction tandis l'installation de paquets

    live-build installe des paquets supplémentaires de l'archive Debian et en fonction de la distribution Debian utilisée et l'état quotidienne de l'archive, il peut échouer. Si un bogue apparaît ici, vérifiez si l'erreur est également reproductible sur un système normal.

    Si c'est le cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans Debian - s'il vous plaît faire le rapport sur le paquet défaillant. L'exécution de debootstrap séparément du système de construction ou l'exécution de lb bootstrap --debug vous donnera plus d'informations.

    Aussi, si vous utilisez un miroir local et/ou un proxy et vous rencontrez un problème, s'il vous plaît toujours le reproduire d'abord bootstrapping sur un miroir officiel.

    13.6.3 Au moment du démarrage

    Si votre image ne démarre pas, s'il vous plaît le signaler à la liste de diffusion avec les informations demandées dans Recueillir l'information. Ne pas oublier de mentionner, comment/quand l'image a échoué, soit dans Qemu, VirtualBox, VMWare ou matériel réel. Si vous utilisez une technologie de virtualisation d'aucune sorte, s'il vous plaît toujours tester sur matériel réel avant de rapporter un bogue. Fournir une copie d'écran de l'échec est également très utile.

    13.6.4 Au moment de l'exécution

    Si un paquet a été installé avec succès, mais il échoue tout en exécutant le système Live, c'est probablement un bogue dans Debian Live. Cependant:

    13.7 Faire les recherches

    Avant de présenter le bogue, s'il vous plaît recherchez sur le web le message d'erreur ou un symptôme particulier que vous obtenez. Comme il est hautement improbable que vous êtes la seule personne qui expérience un problème particulier, il y a toujours une chance qu'il a été discuté ailleurs, et une solution possible, un correctif, ou une solution de contournement a été proposée.

    Vous devez prêter une attention particulière à la liste de diffusion de Debian Live, ainsi que à la page d'accueil, car elles sont susceptibles de contenir des informations à jour. Si ces informations existent, toujours inclure les références au sein de vos rapport de bogues.

    En outre, vous devriez vérifier les listes de bogues en cours de live-build, live-boot, live-config et live-tools pour voir si quelque chose de semblable n'a été déjà signalée.

    13.8 Où rapporter les bogues

    Le projet Debian Live conserve la trace de tous les bogues dans le système Debian Bug Tracking System (BTS). Pour plus d'informations sur la façon d'utiliser le système, s'il vous plaît voir ‹http://bugs.debian.org/›. Vous pouvez également soumettre les bogues en utilisant la commande reportbug du paquet du même nom.

    En général, vous devez signaler les erreurs de construction contre le paquet live-build, les erreurs en temps de démarrage contre live-boot, et les erreurs d'exécution contre live-config. Si vous n'êtes pas sûr de quel paquet est approprié ou avez besoin d'aide avant de soumettre un rapport de bogue, s'il vous plaît signalez le rapport contre le pseudo-paquet debian-live. Nous le réattribuerons s'il y a lieu.

    S'il vous plaît notez que les bogues trouvés dans les distributions dérivées de Debian (comme Ubuntu et autres) ne doivent pas être rapportés au BTS de Debian, sauf qu'ils peuvent être également reproduits sur un système Debian en utilisant les paquets Debian officiels.

    14. Style du code

    Ce chapitre documente le style du code utilisé en live-boot et autres.

    14.1 Compatibilité
  • Ne pas utiliser une syntaxe ou sémantique qui soit unique à le shell Bash. Par exemple, l'utilisation d'arrays.
  • N'utiliser que le sous-ensemble POSIX - par exemple, utiliser $(foo) au lieu de `foo`.
  • Vous pouvez vérifier vos scripts avec 'sh -n' et 'checkbashisms'.
  • Assurez-vous que tout le code fonctionne avec 'set-e '.
  • 14.2 Indentation
  • Toujours utiliser des tabulations en lieu des espaces.
  • 14.3 Adaptateur
  • Généralement, les lignes sont de 80 caractères au maximum.
  • Utilisez le «style Linux» des sauts de ligne:
  • Mal:

    if foo; then
             bar
    fi

    Bien:

    if foo
    then
             bar
    fi

  • La même chose vaut pour les fonctions:
  • Mal:

    Foo () {
             bar
    }

    Bien:

    Foo ()
    {
             bar
    }

    14.4 Variables
  • Les variables sont toujours en lettres majuscules.
  • Les variables utilisées dans lb config commencent toujours par le préfixe LB_.
  • Les variables temporaires internes dans live-build devraient commencer avec le préfixe _LB_.
  • Les variables locales commencent avec le préfixe __LB_.
  • Les variables en relation avec un paramètre de démarrage dans live-config commencent par LIVE_.
  • Toutes les autres variables dans live-config commencent par le préfixe _.
  • Utilisez des accolades autour des variables; par exemple écrire ${FOO} au lieu de $FOO.
  • Toujours protéger les variables avec guillemets pour respecter les espaces potentiels: écrire "${FOO}" en lieu de ${FOO}.
  • Pour des raisons de cohérence, toujours utiliser les guillemets lors de l'attribution des valeurs aux variables:
  • Mal:

    FOO=bar

    Bien:

    FOO="bar"

  • Si plusieurs variables sont utilisées, utiliser les guillemets pour l'expression complète:
  • Mal:

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

    Bien:

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

    14.5 Autres
  • Utilisez "|" (sans les guillemets autour) comme séparateur dans les appels à sed, par exemple "sed -e 's|foo|bar|'" (sans" ").
  • Ne pas utiliser la commande test pour des comparaisons ou des tests, utilisez "[" "]" (sans ""); par exemple "if [ -x /bin/foo ]; ..." et non pas "if test -x /bin/foo; ...".
  • Utiliser case dans la mesure du possible en lieu de test, parce qu'il est plus facile à lire et plus rapide en l'exécution.
  • Utilisez noms en majuscule pour les fonctions pour éviter toute interférence avec l'environnement des utilisateurs.
  • 15. Procédures

    Ce chapitre documente les procédures au sein du projet Debian Live pour différentes tâches qui ont besoin de coopération avec d'autres équipes dans Debian.

    15.1 Télécharger Udebs

    Avant d'envoyer une version d'un udeb au d-i svn, on doit faire:

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

    15.2 Évolutions majeures

    La libération d'une nouvelle version stable majeur de Debian inclut beaucoup de équipes différentes travaillant ensemble. À un certain point, l'équipe Live arrive et construit images des systèmes live. Les conditions pour ce faire sont les suivantes:

  • Un miroir contenant les versions publiées des dépôts Debian, debian-security et debian-volatile auxquels le debian-live buildd peut avoir accès.
  • Les noms de l'image doivent être connus (par exemple debian-live-VERSION-ARCH-FLAVOUR.iso).
  • Les listes de paquets doivent être mises à jour.
  • Les données qui proviennent de debian-cd doivent être synchronisées (udeb exclude lists).
  • Les includes de debian-cd doivent être synchronisées (README.*, doc/*, etc.).
  • Les images sont construites et mises en miroir sur cdimage.debian.org.
  • 15.3 Èvolutions mineures
  • Encore une fois, nous avons besoin de miroirs mis à jour de Debian, Debian-security et debian-volatile.
  • Les images sont construites et mises en miroir sur cdimage.debian.org.
  • Envoyer un courriel d'annonce.
  • 15.3.1 Dernière évolution mineure d'une version Debian

    N'oubliez pas de régler à la fois les miroirs pour chroot et binary lors de la construction de la dernière série d'images pour une version de Debian après qu'elle a été déplacé de ftp.debian.org à archive.debian.org. De cette façon, les vieilles images live précompilées sont encore utiles, sans modifications des utilisateurs.

    15.3.2 Modèle pour l'annonce d'une évolution mineure

    Un courriel pour l'annonce d'une évolutioun mineure peut être généré en utilisant le modèle ci-dessous et la commande suivante:

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

    S'il vous plaît vérifiez le courriel avant l'envoi et le passer à d'autres pour la relecture.

    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/>

    Debian Live project 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. Exemples

    Ce chapitre s'occupe d'exemples de constructions pour des cas d'utilisation spécifiques avec Debian Live. Si vous êtes nouveau avec la construction de vos propres images Debian Live, nous vous recommandons d'abord regarder les trois tutoriels en séquence, parce que chacun enseigne nouvelles techniques qui vous aideront à utiliser et à comprendre les exemples restants.

    16.1 En utilisant les exemples

    Pour utiliser ces exemples vous avez besoin d'un système pour les construire, lequel répond aux exigences énumérées dans Exigences et qui a live-build installé comme décrit à Installation de live-build.

    Notez que, pour des raisons de concision, dans ces exemples, nous ne spécifions pas un miroir local à utiliser pour la construction. Vous pouvez accélérer considérablement les téléchargements si vous utilisez un miroir local. Vous pouvez spécifier les options lorsque vous utilisez lb config, tel que décrit dans Miroirs de distribution utilisés au temps de construction, ou pour plus de commodité, fixez par défaut votre système de construction dans /etc/live/build.conf. Il suffit de créer ce fichier et de définir les variables LB_MIRROR_* correspondantes à votre miroir préféré. Tous les autres miroirs utilisés dans la construction seront par défaut à partir de ces valeurs. Par exemple:

    LB_MIRROR_BOOTSTRAP="http://mirror/debian"
    LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
    LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates"

    16.2 Tutorial 1: Une image standard

    Cas d'utilisation: Créer une image simple d'abord, apprenant les bases de live-build.

    Dans ce tutoriel, nous construirons une image Debian Live ISO hybride par défaut contenant uniquement paquets de base (pas de Xorg) et quelques paquets Debian de soutien live, comme un premier exercice en utilisant live-build.

    Vous ne pouvez pas obtenir rien plus simple que cela:

    $ mkdir tutorial1 ; cd tutorial1 ; lb config

    Examinez le contenu du répertoire config/ si vous le souhaitez. Vous verrez stockés ici une arborescence de configuration, pour être personnalisee ou, dans ce cas, utiliser immédiatement pour construire une image par défaut.

    Maintenant, en tant que superutilisateur, construire l'image en enregistrant un journal avec tee.

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

    En supposant que tout se passe bien, après un certain temps, le répertoire courant contiendra binary.hybrid.iso. Cette image ISO hybride peut être démarrée directement dans une machine virtuelle comme décrit dans Test d'une image ISO avec QEMU et Test d'une image ISO avec virtualbox-ose, ou bien copiée sur un support optique ou un périphérique USB comme décrit dans Graver une image ISO sur un support physique et Copie d'un image ISO hybride sur une clé USB, respectivement.

    16.3 Tutoriel 2: Un utilitaire de navigateur Web

    Cas d'utilisation: Créer une image d'un utilitaire de navigateur Web, en apprenant à appliquer des personnalisations.

    Dans ce tutoriel, nous allons créer une image utilisable comme un utilitaire de navigateur Web, en servant d'introduction à la personnalisation d'images Debian Live.

    $ mkdir tutorial2
    $ cd tutorial2
    $ echo "task-lxde-desktop iceweasel" >> config/package-lists/my.list.chroot

    Notre choix de LXDE pour cet exemple reflète notre volonté de fournir un environnement de bureau minime, puisque le point de l'image est l'utilisation unique que nous avons à l'esprit, le navigateur web. On pourrait aller encore plus loin et offrir une configuration par défaut pour le navigateur web dans config/includes.chroot/etc/iceweasel/profile/, ou des paquets de soutien supplémentaires pour visualiser différents types de contenu web, mais nous laissons cela comme un exercice pour le lecteur.

    Construire l'image, encore une fois en tant que superutilisateur, garder un journal comme dans Tutoriel 1:

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

    Encore une fois, vérifiez que l'image est OK et faire un test, comme dans Tutoriel 1:

    16.4 Tutoriel 3: Une image personnalisée

    Cas d'utilisation: Créer un projet pour construire une image personnalisée, contenant vos logiciels préférés à emporter avec vous sur une clé USB où que vous alliez, et évoluant dans des révisions successives selon vos besoins et vos préférences changent.

    Puisque nous allons changer notre image personnalisée pendant un certain nombre de révisions, et nous voulons suivre ces changements, d'essayer des choses expérimentalement et éventuellement de les revenir si les choses ne fonctionnent pas, nous garderons notre configuration dans le populaire système de contrôle de version git. Nous allons également utiliser les meilleures pratiques d'autoconfiguration via auto scripts tel que décrit dans Gestion d'une configuration.

    16.4.1 Première révision

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

    Éditer auto/config pour lire comme suit:

    #!/bin/sh

    lb config noauto \
         --architectures i386 \
         --linux-flavours 686-pae \
         "${@}"

    Exécutez lb config pour générer l'arbre de configuration, en utilisant le script auto/config que vous avez crée:

    $ lb config

    Maintenant remplir votre liste de paquets locaux:

    $ echo "task-lxde-desktop iceweasel xchat" >> config/package-lists/my.list.chroot

    Tout d'abord, --architectures i386 assure que sur notre système de construction amd64, nous construisons une version de 32 bits qui peut être utilisée sur la plupart des machines. En seconde place, nous utilisons --linux-flavours 686-pae parce que nous ne prévoyons pas utiliser cette image sur des systèmes beaucoup plus anciens. En troisième lieu, nous avons choisi la tâche métapaquet lxde pour nous donner un bureau minimal. Et enfin, nous avons ajouté deux premiers paquets préférés: iceweasel et xchat.

    Maintenant, construire l'image:

    # lb build

    Notez que contrairement aux deux premiers tutoriels, nous n'avons plus besoin de taper 2>&1 | tee build.log parce que cela est maintenant inclus dans auto/build.

    Une fois que vous avez testé l'image (comme dans Tutoriel 1) et vous êtes satisfait avec son fonctionnement, il est temps pour initialiser notre dépôt git, ajoutant que les scripts d'auto que nous avons juste créé, et ensuite faire le premier commit:

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

    16.4.2 Deuxième révision

    Dans cette révision, nous allons nettoyer à partir de la première construction, ajouter le paquet vlc à notre configuration, reconstruire, tester et faire le commit.

    La commande lb clean va nettoyer tous les fichiers générés par la construction précédente à l'exception du cache, ça évite d'avoir à re-télécharger les paquets. Cela garantit que la lb build suivante ré-exécutera toutes les étapes pour régénérer les fichiers de notre nouvelle configuration.

    # lb clean

    Maintenant ajouter le paquet vlc à votre liste de paquets locaux dans config/package-lists/my.list.chroot:

    $ echo vlc >> config/package-lists/my.list.chroot

    Construire à nouveau:

    # lb build

    Tester, et quand vous soyez satisfaits, commit la prochaine révision:

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

    Bien sûr, des changements plus compliqués à la configuration sont possibles, peut-être l'ajout de fichiers dans les sous-répertoires de config/. Quand vous livrez des nouvelles révisions, on doit prendre soin de ne pas modifier à la main ou envoyer au dépôt les fichiers de niveau supérieur dans config contenant variables LB_*, car ce sont aussi des produits de creation et sont toujours nettoyés par lb clean et re-créés avec lb config via leur respectives auto scripts.

    Nous sommes arrivés à la fin de notre série de tutoriels. Alors que de nombreux types de personnalisations sont possibles, même juste en utilisant les fonctionnalités explorées dans ces exemples simples, une variété presque infinie d'images différentes peuvent être crées. Les autres exemples de cette section couvrent plusieurs autres cas d'utilisation tirés des expériences recueillies des utilisateurs de Debian Live.

    16.5 Un client Kiosk VNC

    Cas d'utilisation: Créer une image avec live-build pour démarrer directement à un serveur VNC.

    Make a build directory and create an skeletal configuration inside it, disabling recommends to make a minimal system. And then create two initial package lists: the first one generated with a script provided by live-build named Packages (see Generated package lists), and the second one including xorg, gdm3, metacity and xvnc4viewer.

    $ mkdir vnc_kiosk_client
    $ cd vnc_kiosk_client
    $ lb config -a i386 -k 686-pae --apt-recommends false
    $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
    $ echo "xorg gdm3 metacity xvnc4viewer" > config/package-lists/my.list.chroot

    As explained in Tweaking APT to save space you may need to re-add some recommended packages to make your image work properly.

    An easy way to list recommends is using apt-cache. For example:

    $ apt-cache depends live-config live-boot

    In this example we found out that we had to re-include several packages recommended by live-config and live-boot: user-setup to make autologin work and sudo as an essential program to shutdown the system. Besides, it could be handy to add live-tools to be able to copy the image to RAM and eject to eventually eject the live media, So:

    $ echo "live-tools user-setup sudo eject" >
    config/package-lists/recommends.list.chroot

    Créez le répertoire /etc/skel dans config/includes.chroot avec un fichier .xsession personnalisée pour l'utilisateur par défaut qui va lancer metacity et commencer xvncviewer, en reliant le port 5901 sur un serveur à 192.168.1.2:

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

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

    exit
    END

    Construire l'image:

    # lb build

    Amusez-vous bien!

    16.6 Une image de base pour une clé USB de 128M

    Cas d'utilisation: Créer une image standard avec certains composants éliminés afin de l'adapter sur une clé USB de 128M avec un peu d'espace laissé pour l'utiliser à votre convenance.

    Pour l'optimisation d'une image adaptée à la dimension de certains supports, vous avez besoin de comprendre le compromis que vous faites entre la taille et la fonctionnalité. Dans cet exemple, nous réduisons la taille uniquement que pour faire place au matériel supplémentaire au sein d'une taille de 128M, mais sans faire rien pour détruire l'intégrité des paquets contenus, telle que la purge des données de localisation via le paquet localepurge, ou d'autres optimisations "intrusives". Afin de comprendre ce que le hook minimal.chroot fait, voir /usr/share/doc/live-build/examples/hooks

    $ lb config -k 486 --apt-indices false --apt-recommends false --memtest none
    $ cp /usr/share/doc/live-build/examples/hooks/minimal.chroot config/hooks

    To make the image work properly, we must re-add, at least, two recommended packages which are left out by the --apt-recommends false option. See Tweaking APT to save space

    $ echo "user-setup sudo" > config/package-lists/recommends.list.chroot

    Maintenant, construire l'image de la manière habituelle:

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

    Sur le système de l'auteur au moment de l'écriture, la configuration ci-dessus produisait une image de 95Mbyte. Cela se compare favorablement avec l'image de 182Mbyte produite par la configuration par défaut dans Tutoriel 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-pae". Leaving off APT's indices with --apt-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. 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. --memtest none prevents the installation of a memory tester. And finally, the execution of the minimal.chroot hook removes some unused packages and files.

    En utilisant d'autres hooks comme par exemple le hook stripped.chroot dans /usr/share/doc/live-build/examples/hooks, peut gagner de petites quantités supplémentaires d'espace et produire une image de 76MB. Mais c'est à vous de décider si la fonctionnalité qui est sacrifié à chaque optimisation de la taille vaut la perte de fonctionnalité.

    16.7 Un bureau KDE localisé et installateur

    Cas d'utilisation: Créer une image de bureau KDE, localisée pour le portugais brésilien et incluant un installateur.

    Nous voulons faire une image iso-hybrid pour l'architecture i386 en utilisant notre bureau préféré, dans ce cas, KDE, contenant tous les paquets qui seraient installés par l'installateur Debian standard pour KDE.

    Notre premier problème est la découverte des noms des tâches appropriées. Actuellement, live-build ne peut pas aider à faire ça. Alors que nous pourrions être chanceux et trouver ce par essais et erreurs, il y a un outil, grep-dctrl, qui peut être utilisé pour découvrir les descriptions des tâches dans tasksel-data, de sorte à préparer, assurez-vous que vous avez ces deux choses:

    # apt-get install dctrl-tools tasksel-data

    Maintenant, nous pouvons rechercher les tâches appropriées, d'abord avec:

    $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese

    Par cette commande, nous découvrons que la tâche est appelée, assez clairement, brazilian-portuguese. Maintenant, pour trouver les tâches liées:

    $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese-desktop
    Task: brazilian-portuguese-kde-desktop

    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. Recalling from Using metapackages that task metapackages are prefixed task-, we just specify these language boot parameters, then add standard priority packages and all our discovered task metapackages to our package list as follows:

    $ mkdir live-pt_BR-kde
    $ cd live-pt_BR-kde
    $ lb config \
         -a i386 \
         -k 486 \
         --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
         --debian-installer live
    $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
    $ echo task-kde-desktop task-brazilian-portuguese task-brazilian-portuguese-desktop \
         task-brazilian-portuguese-kde-desktop >> config/package-lists/desktop.list.chroot
    $ echo debian-installer-launcher >> config/package-lists/installer.list.chroot

    Notez que nous avons inclus le paquet debian-installer-launcher pour lancer l'installateur à partir du bureau live, nous avons également précisé le noyau 486, parce qu'il est actuellement nécessaire faire que l'installateur et le noyau du systéme live coïncident pour que le lanceur fonctionne correctement.

    Appendix

    17. Style guide

    17.1 Guidelines for authors

    This section deals with some general considerations to be taken into account when writing technical documentation for live-manual. They are divided into linguistic features and recommended procedures.

    Note: Authors should first read Contributing to this document

    17.1.1 Linguistic features
  • Use plain English
  • Keep in mind that a high percentage of your readers are not native speakers. So as a general rule try to use short, meaningful sentences, followed by a full stop.

    This does not mean that you have to use a simplistic, naive style. It is a suggestion to try to avoid, as much as possible, complex subordinate sentences that make the text difficult to understand for non-native speakers.

  • Variety of English
  • The most widely spread varieties of English are British and American so it is very likely that most authors will use either one or the other. In a collaborative environment, the ideal variety would be "International English" but it is very difficult, not to say impossible, to decide on which variety among all the existing ones, is the best to use.

    We expect that different varieties may mix without creating misunderstandings but in general terms you should try to be coherent and before deciding on using British, American or any other English flavour at your discretion, please take a look at how other people write and try to imitate them.

  • Be balanced
  • Do not be biased. Avoid including references to ideologies completely unrelated to live-manual. Technical writing should be as neutral as possible. It is in the very nature of scientific writing.

  • Be politically correct
  • Try to avoid sexist language as much as possible. If you need to make references to the third person singular preferably use "they" rather than "he" or "she" or awkward inventions such as "s/he", "s(he)" and the like.

  • Be concise
  • Go straight to the point and do not wander around aimlessly. Give as much information as necessary but do not give more information than necessary, this is to say, do not explain unnecessary details. Your readers are intelligent. Presume some previous knowledge on their part.

  • Minimize translation work
  • Keep in mind that whatever you write will have to be translated into several other languages. This implies that a number of people will have to do an extra work if you add useless or redundant information.

  • Be coherent
  • As suggested before, it is almost impossible to standardize a collaborative document into a perfectly unified whole. However, every effort on your side to write in a coherent way with the rest of the authors will be appreciated.

  • Be cohesive
  • Use as many text-forming devices as necessary to make your text cohesive and unambiguous. (Text-forming devices are linguistic markers such as connectors).

  • Be descriptive
  • It is preferable to describe the point in one or several paragraphs than merely using a number of sentences in a typical "changelog" style. Describe it! Your readers will appreciate it.

  • Dictionary
  • Look up the meaning of words in a dictionary or encyclopedia if you do not know how to express certain concepts in English. But keep in mind that a dictionary can either be your best friend or can turn into your worst enemy if you do not know how to use it correctly.

    English has the largest vocabulary that exists (With over one million words). Many of these words are borrowings from other languages. When looking up the meaning of words in a bilingual dictionary the tendency of a non-native speaker is to choose the one that sounds more similar in their mother tongue. This often turns into an excessively formal discourse which does not sound quite natural in English.

    As a general rule, if a concept can be expressed using different synonyms, it is a good advice to choose the first word proposed by the dictionary. If in doubt, choosing words of Germanic origin (Usually monosyllabic words) is often the right thing to do. Be warned that these two techniques might produce a rather informal discourse but at least your choice of words will be of wide use and generally accepted.

    Using a dictionary of collocations is recommended. They are extremely helpful when it comes to know which words usually occur together.

    Again it is a good practice to learn from the work of others. Using a search engine to check how other authors use certain expressions may help a lot.

  • False friends, idioms and other idiomatic expressions
  • Watch out for false friends. No matter how proficient you are in a foreign language you cannot help falling from time to time in the trap of the so called "false friends", words that look similar in two languages but whose meanings or uses might be completely different.

    Try to avoid idioms as much as possible. "Idioms" are expressions that may convey a completely different meaning from what their individual words seem to mean. Sometimes, idioms are difficult to understand even for native speakers!

  • Avoid slang, abbreviations, contractions...
  • Even though you are encouraged to use plain, everyday English, technical writing belongs to the formal register of the language.

    Try to avoid slang, unusual abbreviations that are difficult to understand and above all contractions that try to imitate the spoken language. Not to mention typical irc and family friendly expressions.

    17.1.2 Procedures
  • Test before write
  • It is important that authors test their examples before adding them to live-manual to ensure that everything works as described. Testing on a clean chroot or VM can be a good starting point. Besides, it would be ideal if the tests were then carried out on different machines with different hardware to spot possible problems that may arise.

  • Examples
  • When providing an example try to be as specific as you can. An example is, after all, just an example.

    It is often better to use a line that only applies to an specific case than using abstractions that may confuse your readers. In this case you can provide a brief explanation of the effects of the proposed example.

    There may be some exceptions when the example suggests using some potentially dangerous commands that, if misused, may cause data loss or other similar undesirable effects. In this case you should provide a thorough explanation of the possible side effects.

  • External links
  • Links to external sites should only be used when the information on those sites is crucial when it comes to understanding a special point. Even so, try to use links to external sites as sparsely as possible. Internet links are likely to change from time to time resulting in broken links and leaving your arguments in an incomplete state.

    Besides, people who read the manual offline will not have the chance to follow those links.

  • Avoid branding and things that violate the license under which the manual is published
  • Try to avoid branding as much as possible. Keep in mind that other downstream projects might make use of the documentation you write. So you are complicating things for them if you add certain specific material.

    live-manual is licensed under the GNU GPL. This has a number of implications that apply to the distribution of the material (of any kind, including copyrighted graphics or logos) that is published with it.

  • Write a first draft, revise, edit, improve, redo if necessary
  • - Brainstorm!. You need to organize your ideas first in a logical sequence of events.

    - Once you have somehow organized those ideas in your mind write a first draft.

    - Revise grammar, syntax and spelling.

    - Improve your statements and redo any part if necessary.

  • Chapters
  • Use the conventional numbering system for chapters and subtitles. e.g. 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... and so on. See markup below.

    If you have to enumerate a series of steps or stages in your description, you can also use ordinal numbers: First, second, third ... or First, Then, After that, Finally ... Alternatively you can use bulleted items.

  • Markup
  • And last but not least, live-manual uses SiSU to process the text files and produce a multiple format output. It is recommended to take a look at SiSU's manual to get familiar with its markup, or else type:

    $ sisu --help markup

    Here are some markup examples that may prove useful:

    - For emphasis/bold text:

    *{foo}* or !{foo}!

    produces: foo or foo. Use it to emphasize certain key words.

    - For italics:

    /{foo}/

    produces: foo. Use them e.g. for the names of debian packages.

    - For monospace:

    #{foo}#

    produces: foo. Use it e.g. for the names of commands. And also to highlight some key words or things like paths.

    - For code blocks:

    code{

      $ foo
      # bar

    }code

    produces:

    $ foo
    # bar

    Use code{ to open and }code to close the tags. It is important to remember to leave a space at the beginning of each line of code.

    17.2 Guidelines for translators

    This section deals with some general considerations to be taken into account when translating the contents of live-manual.

    As a general recommendation, translators should have read and understood the translation rules that apply to their specific languages. Usually, translation groups and mailing lists provide information on how to produce translated work that complies with Debian quality standards.

    Note: Translators should also read Contributing to this document. In particular the section Translation

    17.2.1 Translation hints
  • Comments
  • The role of the translator is to convey as faithfully as possible the meaning of words, sentences, paragraphs and texts as written by the original authors into their target language.

    So they should refrain from adding personal comments or extra bits of information of their own. If they want to add a comment for other translators working on the same documents, they can leave it in the space reserved for that. That is, the header of the strings in the po files preceded by a number sign #. Most graphical translation programs can automatically handle those types of comments.

  • TN, Translator's Note
  • It is perfectly acceptable however, to include a word or an expression in brackets in the translated text if, and only if, that makes the meaning of a difficult word or expression clearer to the reader. Inside the brackets the translator should make evident that the addition was theirs using the abbreviation "TN" or "Translator's Note".

  • Impersonal sentences
  • Documents written in English make an extensive use of the impersonal form "you". In some other languages that do not share this characteristic, this might give the false impression that the original texts are directly addressing the reader when they are actually not doing so. Translators must be aware of that fact and reflect it in their language as accurately as possible.

  • False friends
  • The trap of "false friends" explained before especially applies to translators. Double check the meaning of suspicious false friends if in doubt.

  • Markup
  • Translators working initially with pot files and later on with po files will find many markup features in the strings. They can translate the text anyway, as long as it is translatable, but it is extremely important that they use exactly the same markup as the original English version.

  • Code blocks
  • Even though the code blocks are usually untranslatable, including them in the translation is the only way to score a 100% complete translation. And even though it means more work at first because it requires the intervention of the translators if the code changes, it is the best way, in the long run, to identify what has already been translated and what has not when checking the integrity of the .po files.

  • Newlines
  • The translated texts need to have the exact same newlines as the original texts. Be careful to press the "Enter" key or type \n if they appear in the original files. These newlines often appear, for instance, in the code blocks.

    Make no mistake, this does not mean that the translated text needs to have the same length as the English version. That is nearly impossible.

  • Untranslatable strings
  • Translators should never translate:

    - The code names of releases

    - The names of programs

    - The commands given as examples

    - Metadata (often between colons :metadata:)

    - Links

    - Paths