HOWTO Graver un CD RedHat

Luigi Bitonti

          
        

Morten Kjeldgaard

          
        

Peter von der Ahé

          
        

Guillaume Lelarge - Traduction française

Guillaume Hatt - Relecture de la version française

Première version de la 2.0 de ce HOWTO
Historique des versions
Version v2.02002-10-28Revu par : lb

Ce document décrit comment créer vos propres CDs à partir des différentes releases de la distribution RedHat Linux (jusqu'à la 8.0 et en l'incluant), équivalent à ceux disponibles commercialement auprès de RedHat. La structure de la distribution est décrite, ainsi que la procédure nécessaire pour inclure des RPMs mis à jour dans cette distribution. Quelques conseils et exemples sur la façon de personnaliser l'installation par défaut sont aussi présentés. Des scripts automatisant autant que possible la (re)génération des images CD sont aussi inclus. Les prérequis sont une bonne connexion réseau et un graveur de CD (une connaissance des scripts shells peut aussi être utile).


Table des matières
1. Introduction
1.1. Avertissement et License
2. Anatomie du site FTP de Red Hat
2.1. Organisation des répertoires de la Redhat 8.0
2.2. Le répertoire "RedHat" -- le cœur de la distribution
2.3. Le répertoire "updates"
2.4. Différences avec l'arbre 7.x
2.5. Différences avec l'arbre 6.x
3. Paquets RPM
3.1. Comparer deux versions d'un paquet RPM
4. Obtenir votre copie locale de la distribution
4.1. Utiliser wget et bash
4.2. Utiliser mirror
5. Inclure les mises à jour
5.1. Corriger les modes de protection des fichiers
5.2. Remplacer les RPMs mis à jour
5.3. Reconstruire l'installateur
6. Graver les CD(s)
6.1. Tester l'image ou les images
6.2. Graver le(s) disque(s)
7. Le fichier comps
7.1. Format du fichier comps pour RedHat versions < 6.1
7.2. Format du fichier comps pour RedHat version 6.1
7.3. Format du fichier comps dans RedHat version 6.2
7.4. Format d'un fichier comps dans la RedHat version 7.3
7.5. Format du fichier comps à partir de RedHat version 8.0
8. Installer à partir du CD
8.1. Démarrer d'un CD amorçable
9. Autres distributions Linux
10. Ce document...
10.1. Documents en rapport
10.2. Remerciements
11. Adaptation française
11.1. Traduction
11.2. Relecture

1. Introduction

Il doit exister de nombreuses raisons pour créer vos propres CDs. Peut-être êtes-vous avare et voulez-vous sauver le coût d'une distribution Red Hat. Ou peut-être voulez-vous inclure dans vos CDs la dernière distribution de toutes les mises à jour actuelles. Ceci est très pertinent car après chaque release majeure de la distribution RedHat, il existe des tonnes de mises à jour, plusieurs ayant rapport avec la sécurité. Jetez juste un regard sur la page des erreurs. Ou peut-être voulez-vous personnaliser l'installation par défaut en ajoutant quelques paquets absents de l'arbre par défaut et désélectionner l'installation de quelques paquets qui autrement seraient inclus dans la configuration par défaut.

Voici ce qui vous sera appris dans les sections suivantes (je l'espère). J'utiliserai l'architecture i386 et les releases 7.3 et 8.0 de la distribution dans les exemples. Les notes concernant les releases précédentes (<6.1) ont été incluses lors d'une précédente version de ce document et ont été ajoutées par les auteurs originaux. Les notes en relation avec la release 6.2 sont basées sur des tests que je n'ai pas terminés (et je ne sais pas si je le ferai un jour) et sur quelques documents que vous trouverez dans la section documents en rapport. La procédure donnée dans les sections suivantes pour RedHat 7.3 et 8.0 peut fonctionner sur toutes les plateformes supportées par RedHat (Alpha, PPC, etc...), pour toutes les releases 7.x (et peut-être les 8.x dans un futur pas si lointain), mais je l'ai seulement testée sur la plateforme i386 avec RedHat Linux 7.3 et 8.0 (je serais intéressé par plus d'informations).

Note

Les opérations décrites ont des implications légales, ce qui veut dire que vous ne pouvez pas redistribuer les CDs en tant que RedHat Linux si vous les avez modifiés de façon non conforme à la politique de RedHat. Pour les rendre légalement redistribuables, vous devez d'abord appliquer les lignes de conduites indiquées sur le site web de RedHat.

Note

Rappelez-vous toujours de mettre en place les variables dans rhcd.conf et d'exporter la variable d'environnement RHCDPATH avant de lancer les scripts que vous trouverez tout au long du reste de ce document et en relation avec les releases supérieures ou égales à la 6.2 de la RedHat Linux. Un fichier rhcd.conf d'exemple, qui devrait être bien commenté, est donné avec les scripts.


1.1. Avertissement et License

Ce document est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE; sans même la garantie implicite de qualité loyale et marchande ou d'exactitude pour un usage particulier.

Ni l'auteur ni les distributeurs, ou tout autre contributeur de ce document ne sont de quelque façon que ce soit responsables pour les dommages physiques, financiers, morals ou de tout autre type, occasionnés en suivant les suggestions de ce texte.


2. Anatomie du site FTP de Red Hat

Dans l'esprit de la communauté Linux, RedHat Software a rendu disponible ses distributions Linux pour plusieurs plateformes sur son site FTP. Elles sont toutes disponibles à partir de la racine du répertoire de distribution (pub/redhat/linux/). Jetez donc un œil sur l'arbre de la distribution.


2.1. Organisation des répertoires de la Redhat 8.0

La dernière distribution est, à l'heure où j'écris ces lignes, disponible uniquement pour la plateforme i386. Le répertoire de haut niveau apparaît un peu sans consistence, étant donnée la présence d'une seule architecture (pub/redhat/linux/8.0/en/os/).
 
        i386/
      

Autrement, le répertoire de haut niveau, pour les releases un peu plus anciennes que la 8.0, contient les distributions des différentes plateformes. Par exemple, le répertoire correspondant à la release 7.1 de RedHat Linux est structuré de cette façon:
 
        alpha/   i386/   ia64/   ppc/   s390x/
      

La racine du répertoire i386 ressemble à ce qui suit:
 
	-rwxr-xr-x    1 root     root          248 Sep 10 21:19 autorun
	drwxr-xr-x    7 root     root         4096 Oct 25 10:43 dosutils
	-rwxr-xr-x    1 root     root         6194 Sep 10 21:19 EULA
	-rwxr-xr-x    1 root     root        18385 Sep 10 21:19 GPL
	drwxr-xr-x    3 root     root         4096 Oct 25 10:43 images
	drwxr-xr-x    2 root     root         4096 Oct 25 10:43 isolinux
	-rw-r--r--    1 root     root        28320 Oct 24 22:36 pkgorder.txt
	-rwxr-xr-x    1 root     root         5350 Sep 10 21:19 README
	-rwxr-xr-x    1 root     root        13342 Sep 10 21:19 README-Accessibility
	-rwxr-xr-x    1 root     root         5781 Sep 10 21:19 README.de
	-rwxr-xr-x    1 root     root         5956 Sep 10 21:19 README.es
	-rwxr-xr-x    1 root     root         6351 Sep 10 21:19 README.fr
	-rwxr-xr-x    1 root     root         5684 Sep 10 21:19 README.it
	-rwxr-xr-x    1 root     root         6836 Sep 10 21:19 README.ja
	-rwxr-xr-x    1 root     root         6566 Sep 10 21:19 README.ko
	-rwxr-xr-x    1 root     root         4965 Sep 10 21:19 README.zh_CN
	-rwxr-xr-x    1 root     root         5267 Sep 10 21:19 README.zh_TW
	drwxr-xr-x    4 root     root         4096 Oct 25 10:43 RedHat
	-rwxr-xr-x    1 root     root        37493 Sep 10 21:19 RELEASE-NOTES
	-rwxr-xr-x    1 root     root        47340 Sep 10 21:19 RELEASE-NOTES-de.html
	-rwxr-xr-x    1 root     root        44726 Sep 10 21:19 RELEASE-NOTES-es.html
	-rwxr-xr-x    1 root     root        47994 Sep 10 21:19 RELEASE-NOTES-fr.html
	-rwxr-xr-x    1 root     root        42160 Sep 10 21:19 RELEASE-NOTES.html
	-rwxr-xr-x    1 root     root        44680 Sep 10 21:19 RELEASE-NOTES-it.html
	-rwxr-xr-x    1 root     root        56720 Sep 10 21:19 RELEASE-NOTES-ja.html
	-rwxr-xr-x    1 root     root        50814 Sep 10 21:19 RELEASE-NOTES-ko.html
	-rwxr-xr-x    1 root     root        37770 Sep 10 21:19 RELEASE-NOTES-zh_CN.html
	-rwxr-xr-x    1 root     root        39122 Sep 10 21:19 RELEASE-NOTES-zh_TW.html
	-rwxr-xr-x    1 root     root         1910 Sep 10 21:19 RPM-GPG-KEY
	-rwxr-xr-x    1 root     root          338 Sep 10 21:56 TRANS.TBL
      

Le répertoire SRPMS contient les paquets RPMS en forme source.

Le répertoire images contient les images des disquettes de démarrage et de pilotes pouvant être copiés sur une disquette si besoin est. Pour la release 8.0, trois images de disque de démarrage sont disponibles. La première image est appelée boot.img et est requise lorsque l'installation est réalisée directement à partir du CD-ROM. Si l'installation est réalisée depuis un disque NFS monté ou par FTP, l'image disque bootnet.img est nécessaire. L'installation via des adapteurs PCMCIA nécessite la disquette pcmcia.img. Voir la section installation et les références pour plus de détails et consulter le fichier README dans le répertoire pour une explication plus détaillée des différents fichiers.

Le répertoire isolinux contient les fichiers nécessaires pour démarrer sur le CD (et pour reconstruire des CDs amorçables qui fonctionnent de la même façon). Ce processus a été modifié pour passer d'une émulation de disquette à pas d'émulation du tout. Ceci aide à éviter les contraintes d'espace et les problèmes de compatibilité.

Le répertoire dosutils contient différents programmes pour certains autres systèmes d'exploitation, qui sont parfois utiles pour le bon déroulement du processus d'installation. Un fichier README d'explications est aussi inclus dans ce cas.

La liste est complétée par un grand nombre de fichiers et le répertoire RedHat. Ce dernier est le sujet des sections suivantes alors que les précédents ont un contenu compréhensible en lisant seulement leur nom (sauf peut-être celui du EULA, ou End User License Agreement).


2.2. Le répertoire "RedHat" -- le cœur de la distribution

La plus importante partie de l'arbre du répertoire a sa racine dans le répertoire RedHat:

 
        drwxr-xr-x    2 root     root        53248 Jun 14 03:15 RPMS
        drwxr-xr-x    2 root     root          4096 Jun 14 04:15 base
      

Le répertoire RPMS contient la grosse partie de la distribution RedHat consistant en un ensemble de fichiers RPM (Redhat Package Manager). Un paquet RPM contient typiquement des exécutables binaires, avec les fichiers de configuration et la documentation. Voir la section les paquets RPM pour plus d'informations.

Le répertoire base contient différents fichiers nécessaires lors de l'installation, comme le fichier comps.xml, qui définit les composants (groupes de paquets) utilisés durant la phase "Choisissez les paquets à installer". Voir la section le fichier comps pour plus d'informations sur ce fichier, et pour savoir l'utiliser.

Deux autres fichiers importants dans le répertoire base sont hdlist et hdlist2 contenant la plupart des champs d'entêtes de tous les RPMs dans le répertoire RPMS. Ceci veut dire que toutes les interdépendances parmi les paquets RPM peuvent être déterminées simplement en lisant ces fichiers sans avoir à lire tous les RPM, ce qui est très appréciable spécialement lors des installations par FTP. Une autre utilisation de ces fichiers est la correspondance des noms de paquets avec ceux des fichiers (par exemple perl vers perl-5.004-6.i386.rpm). Ceci veut dire que si vous voulez des mises à jour de RedHat (voir section inclure les mises à jour) ou ajouter vos propres paquets dans le répertoire RPMS, vous aurez besoin de mettre à jour hdlist et hdlist2. Ceci est décrit plus tard dans reconstruire l'installateur. En dehors de ces fichiers, on trouve les images à partir desquelles l'environnement d'installation est lancé (c'est-à-dire le noyau, l'interpréteur python, anaconda, etc...).


2.3. Le répertoire "updates"

Le répertoire /pub/redhat/linux/updates dispose des mises à jour de toutes les releases de la distribution RedHat depuis la version 3.0.3. C'est l'endroit où trouver les paquets qui ont été mis à jour pour une raison ou une autre. Vous devez tout particulièrement faire attention aux mises à jour de sécurité. Elles sont affichées sur la page des erreurs de RedHat dès qu'une correction est disponible. Les fichiers les plus importants trouvés dans le répertoire updates sont:

 
        drwxrwsr-x    3 root      root          4096 Jul 13 10:13 5.2
        drwxrwsr-x    3 root      root          4096 Jul 13 10:13 6.0
        drwxrwsr-x    3 root      root          4096 Jul 13 10:13 6.1
        drwxrwsr-x    4 root      root          4096 Jul 13 10:14 6.2
        drwxrwsr-x    4 root      root          4096 Jul 13 10:14 7.0
        drwxrwsr-x    4 root      root          4096 Jul 13 10:14 7.1
        drwxrwsr-x    4 root      root          4096 Jul 13 10:13 7.2
        drwxrwsr-x    3 root      root          4096 Jul 13 10:14 7.3
        drwxrwsr-x    3 root      root          4096 Jul 13 10:14 8.0
      

La structure de chacun de ces sous-répertoires est similaire à ce qui est décrit dans la section l'organisation de la Redhat 8.0. Donc, pour chaque version, vous trouverez dans le sous-répertoire en/os/ une série de sous-répertoires représentant les nombreuses architectures ainsi que les sous-répertoires noarch et SRPMS, pour les paquets qui fonctionnent respectivement sur toutes les architectures ou sont sous forme de source.

 
        drwxrwsr-x    2 root      root          4096 Sep 23 05:28 SRPMS
        drwxrwsr-x    2 root      root          4096 Aug 28 18:25 athlon
        drwxrwsr-x    2 root      root          8192 Sep 23 05:28 i386
        drwxrwsr-x    2 root      root          4096 Jul 13 10:14 i486
        drwxrwsr-x    2 root      root          4096 Aug 28 18:26 i586
        drwxrwsr-x    2 root      root          4096 Aug 28 18:26 i686
        drwxrwsr-x    2 root      root          4096 Jul 13 10:14 noarch
      


2.4. Différences avec l'arbre 7.x

Les deux distributions sont pratiquement similaires à ce niveau. Les seuls changements d'intérêt pour nous (et faciles à remarquer avec une petite inspection de l'arbre principal de la distribution) sont représentés par un répertoire isolinux manquant et quelques modifications sur le répertoire RedHat/base. Le premier changement est dû à la façon dont les CDs d'installation sont rendus amorçables dans les releases précédant la 8.0 (l'<< émulation disquette >> a été changée en << pas d'émulation >> pour la release 8.0), alors que le second est un effet de la migration du format du fichier comps en XML pour la Redhat 8.0 (ce qui explique pourquoi il a été renommé comps.xml). Le fichier Redhat/base/comps est, en fait, un simple fichier texte avec une syntaxe peu flexible dans les releases RedHat 7.3 et précédentes.


2.5. Différences avec l'arbre 6.x

Pour la release 6.2 (pub/redhat/linux/6.2/en/os/), la dernière des six séries, l'organisation est la suivante (celle des précédentes releases est à peu près similaire, mais pas complètement):

        alpha/   i386/   sparc/
      

Quant à elle, la racine du répertoire i386 ressemble à ceci:
        -rw-r--r--    1 root     root        18385 Sep  7  1999 COPYING
        -rw-r--r--    1 root     root         3400 Mar  8  2000 README
        -rw-r--r--    1 root     root        16300 Mar  8  2000 RELEASE-NOTES
        -rw-r--r--    1 root     root         1908 Sep 25  1999 RPM-GPG-KEY
        drwxr-xr-x    1 root     root          512 Sep 27 15:22 RedHat
        drwxr-xr-x    1 root     root        17408 Sep 27 15:22 SRPMS
        -rwxr-xr-x    1 root     root          538 Sep 26  1999 autorun
        -rwxr--r--    1 root     root         2048 Mar  9  2000 boot.cat
        drwxr-xr-x    1 root     root          512 Sep 27 15:22 doc
        drwxr-xr-x    1 root     root          512 Sep 27 15:22 dosutils
        drwxr-xr-x    1 root     root          512 Sep 27 15:22 images
        drwxr-xr-x    1 root     root          512 Sep 27 15:22 misc
      

Dans les paragraphes suivants, je listerai seulement les différences entre les nouvelles releases; ce qui n'est pas explicitement mentionné est resté (ou est supposé être resté) inchangé.

Le répertoire doc contient une abondance d'informations. Plus important, le manuel d'installation RedHat peut être trouvé au format HTML dans le répertoire ou sur le site web de RedHat ( Guide d'installation RedHat 6.2). Ensuite, il y a le guide de référence et le guide de démarrage (getting started). La documentation pour les releases 7.x/8.x est sur un CD séparé (dans un arbre différent, sur le site ftp).

Le répertoire images contient les images de disquettes de démarrage qui peuvent être copiées sur une disquette si nécessaire, comme pour les 8.0 et 7.3. Voir la section installation et ses références pour les détails. Le répertoire misc contient sources et exécutables d'un certain nombre de programmes nécessaires pour l'installation.

La plus importante partie de l'arbre du répertoire est (encore) située à la racine du répertoire RedHat:

        drwxr-xr-x   2 root     root    28672   Oct 26 09:01   RPMS
        drwxr-xr-x   2 root     root     4096   Oct 26 09:01   base
        -rw-r--r--   1 root     root        0   Jan 19  1999   i386
        drwxr-xr-x   6 root     root     4096   Oct 26 09:01   instimage
      

Le répertoire RPMS devrait déjà être connu de vous. Voir la section les paquets RPM pour plus d'informations. Le répertoire base conserve différents fichiers nécessaires lors de l'installation, comme pour les releases 7.3 et 8.0. Les seules différences visibles sont représentées par un fichier hdlist et un fichier manquant stage2.img dont les fonctionnalités devront être assurées par les fichiers inclus dans le répertoire instimage. Il contient, en fait, un vrai système de fichiers avec un certain nombre de programmes et de bibliothèques partagées durant la procédure d'installation.

Le répertoire updates est vraiment similaire à celui décrit pour la release 8.0, la seule différence étant qu'il comporte davantage de répertoires en relation avec l'architecture.


3. Paquets RPM

La majeure partie de la distribution RedHat consiste en un ensemble de fichiers RPM (Redhat Package Manager). Un paquet RPM contient en général des exécutables binaires, avec les fichiers de configuration et la documentation. Le programme rpm est le gestionnaire de paquets de RedHat, qui peut être utilisé pour installer, rechercher, vérifier, effacer et construire les paquets au format RPM. Rpm gère convenablement une base de données de tous les paquets installés, ce qui rend l'information sur les logiciels installés disponible à tout moment.

Les fichiers binaires RPM inclus dans la distribution ont été construits sur un système utilisant lui-même la distribution. C'est important, parce que la plupart des programmes dans les paquets dépendent des bibliothèques partagées. A partir de RedHat 5.0, la nouvelle version 3 de la bibliothèque C standard de GNU (qui est compatible 64 bits) a été utilisée. Cette version de la bibliothèque est communément appelée glibc ou sous Linux: libc 6. Tous les exécutables de cette distribution ont été liés avec cette bibliothèque. Si vous tentez d'installer les fichiers binaires d'une distribution différente, il y a beaucoup de chances que cela ne fonctionne pas, sauf si vous installez le paquet libc5 pour la compatibilité descendante. Il existe aussi des incompatibilités entre les nombreuses versions du RedHat Package Manager lui-même qui feront rater l'installation de quelques paquets même sur les machines où ils sont supposés fonctionner.

Les noms des paquets RPM contiennent le suffixe .arch.rpm, où arch est l'architecture, ayant habituellement la valeur i386 pour les binaires de la plateforme Intel. Les paquets que vous installez doivent correspondre aux versions des bibliothèques partagées disponibles sur la machine. Le programme rpm est habituellement assez bon pour s'assurer que c'est bien le cas. Néanmoins, il existe des moyens de le vérifier, et vous devez être sûr de savoir ce que vous faites si vous forcez l'installation de paquets de cette façon. Néanmoins, en utilisant le disque de démarrage de l'installation RedHat, il est assuré que l'ensemble correct des paquets RPM est installé sur la machine.

Si vous découvrez un paquet RPM qui n'a pas été installé sur votre système durant le processus d'installation, ne désespérez pas. A tout moment, vous pouvez (en tant que root) installer des paquets RPM, par exemple:
      # rpm --install  WindowMaker-0.18-1b.i386.rpm
    

Vous pouvez même installer directement d'Internet, si vous connaissez l'URL du paquet RPM:
      # rpm --install ftp://rufus.w3.org/redhat-contrib/noarch/mirror-2.9-2.noarch.rpm
    

Si vous voulez mettre à jour un paquet RPM (ou l'installer s'il n'est pas présent sur la machine), utilisez la commande:
      # rpm --update  WindowMaker-0.18-1b.i386.rpm
    

Si vous voulez mettre à jour un paquet RPM et seulement si une version précédente est déjà installée, utilisez la commande:
      # rpm --freshen  WindowMaker-0.18-1b.i386.rpm
    

Une autre version des paquets RPM contient les sources originaux utilisés pour construire les binaires. Ces paquets ont le suffixe .src.rpm et sont situés dans le répertoire SRPMS. Ces paquets composent les deux derniers CDs et une partie du troisième sur cinq, qui font la release 8.0 (ou la 7.3). Pour la 6.2 (et les précédentes versions, pas trop anciennes), les choses changent un peu puisqu'il n'existe qu'un seul CD d'installation qui ne comporte pas les paquets SRPMS, que vous pouvez graver sur un disque différent si vous le voulez.

Pour obtenir plus d'informations sur le gestionnaire de paquet RedHat, je vous suggère de lire les pages man et le livre bien détaillé Maximum rpm.

Dans la prochaine section, j'introduirai un programme C qui sera utilisé dans des scripts variés tout au long du reste du howto. Il indique entre deux versions du même paquet RPM, celui qui est le plus récent. Ce programme est basé sur le code utilisé dans le gestionnaire de paquets RedHat (release 4.1) et est utilisé quand l'option --freshen est ajoutée.


3.1. Comparer deux versions d'un paquet RPM

Le code C inclus dans les trois fichiers Makefile, rvc.h, rvc.c a été extrait du gestionnaire de paquets RedHat et (légèrement) modifié pour combler vos besoins. Ils forment un programme C simple qui, avec deux versions A et B d'un paquet retourne 1, 0 ou -1 si A est respectivement plus récent, égal ou plus ancien que B et d'autres valeurs en cas d'erreur (vous pouvez lire les commentaires du code pour des informations plus détaillées). Pour compiler le programme (vous avez besoin du programme make et du compilateur C gcc). Copier le fichier dans le même répertoire et envoyer la commande:
        $ make
      

Ce programme est nécessaire pour pratiquement tous les scripts utilisés dans les sections suivantes et met en place la variable RVC dans le fichier rhcd.conf.

Vous pouvez trouver une copie des sources et de la version précompilée dans l'archive rhcd-sripts.tar.gz située dans le répertoire rpmvc.


4. Obtenir votre copie locale de la distribution

Vous avez besoin d'une copie de la distribution sur un disque où vous pouvez écrire, et accessible à partir de l'ordinateur possédant le graveur. Si vous incorporez les dernières mises à jour, le répertoire doit (aussi) être accessible à partir d'une machine Linux, soit à partir d'un disque local, soit à partir d'un disque monté NFS d'une autre machine, soit à partir d'un disque JAZ. Vous pouvez copier la distribution à partir des CDs de RedHat (recommandé), ou vous pouvez l'obtenir via FTP. Si vous choisissez d'utiliser FTP, il existe deux moyens de le faire. Vous pouvez utiliser un script shell basé sur wget, script présenté dans la section suivante, ou utiliser le paquet mirror comme suggéré par les versions précédentes et jusqu'à la 1.34 incluse de ce howto (rapporté dans la section utiliser mirror).


4.1. Utiliser wget et bash

Ce n'est pas la plus simple des méthodes, même si elle est la plus précise. Je l'apprécie parce qu'elle permet de comparer les versions RPM des fichiers et non plus leur date/heure ou nom (comme les paquets standards de miroirs) et qu'elle vérifie les signatures des mises à jour à chaque fois qu'elle en télécharge quelques unes, si ceci est bien configuré avec la variable CHECKSIG dans le fichier rhcd.conf.

Créez un répertoire qui contiendra les fichiers d'installation et entrez à l'intérieur (cd); lancez ensuite la commande (qui téléchargera environ 3Go de données sur votre disque dur pour la RedHat 7.3 et 8.0):

 
        $ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \
            ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386
      

Vous voudrez probablement changer le miroir FTP de téléchargement et, en conséquence, le paramètre passé à l'option --cut-dirs. C'est en fait utilisé conjointement avec -nH pour éviter la re-création de la hiérarchie des répertoires du site FTP. Pour plus d'informations sur l'utilisation correcte de cette option, jetez un œil sur la documentation wget et les pages man.

Si vous voulez exclure un ou plusieurs répertoires des téléchargements, vous pouvez utiliser l'option -X liste, où liste représente une liste de répertoires séparés par des virgules. Par exemple, pour exclure le répertoire SRPMS des précédents téléchargements, vous pouvez utiliser:
 
        $ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \
            -X /sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386/SRPMS \
            ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386
      

Cela peut être utile si vous considérez la taille du répertoire SRPMS (environ 1.2Go); en tout cas, je le trouve utile.

Si vous voulez vérifier les signatures GPG pour vous assurer de l'authenticité des paquets (ce que je recommende), vous devez installer le paquet gnupg et importer la clé publique security@redhat.com que vous trouverez dans le répertoire racine des CDs (RPM-GPG-KEY) ou sur le site web RedHat. La clé est importée en lançant la commande: gpg --import <filename> pour les releases jusqu'à la 7.3 (en l'incluant), ce qui a été remplacé par rpm --import <filename> pour la release 8.0 (pour plus d'informations sur ceci, jetez un œil sur les sites web de GNU Privacy Guard et de RPM (Redhat Package Manager)).

Si vous voulez vérifier les paquets RPM, vous pouvez le faire en utilisant la commande suivante (je suppose que vous la lancez à partir du répertoire où vous avez réalisé les téléchargements):

Pour les releases jusqu'à la 7.3 (comprise):
 
        $ find . -name "*.rpm" -exec rpm -K --nopgp {} \; |grep "NOT *OK"
      

Pour la release 8.0 (ainsi que pour les futures releases, je suppose):
 
        $ find . -name "*.rpm" -exec rpm -K {} \; |grep "NOT *OK"
      

Si vous ne voulez pas vous << ennuyer >> avec toutes ces étapes, j'espère que vous voudrez au moins vérifier l'intégrité des fichiers téléchargés (ce qui ne veut pas dire que personne ne les a modifiés), à l'aide des signatures md5. Ceci est fait avec:

Pour les releases jusqu'à la 7.3 (comprise):
 
        $ find . -name "*.rpm" -exec rpm -K --nopgp --nogpg {} \; |grep "NOT *OK"
      

Pour la release 8.0 (ainsi que pour les futures releases, je suppose):
 
        $ find . -name "*.rpm" -exec rpm -K --nosignature {} \; |grep "NOT *OK"
      

Le contenu d'une distribution RedHat ne change pas entre les releases, donc vous avez seulement besoin de télécharger ces paquets UNE FOIS. Tous les changements de la distribution sont dans le répertoire updates. Donc, si vous voulez conserver un miroir à jour de la distribution RedHat, vous avez seulement besoin de conserver le répertoire updates. Ceci se fait en utilisant le script updateDist.sh. Avant d'utiliser le script, vous devez configurer le fichier rhcd.conf et exporter la variable RHCDPATH pointant vers le répertoire où se trouve le fichier.

        $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
        $ sh updateDist.sh
      

Ce script va télécharger les nouvelles mises à jour en excluant les sous- répertoires contenus dans la variable EXCLUDELIST, en déplaçant les anciens (c'est-à-dire ceux remplacés par les nouvelles versions) dans le répertoire représenté par la variable OLDDIR et vérifier leur signature qui dépend de la valeur des deux variables CHECKSIG et USEGPG. En cas d'erreurs lors du processus de vérification des signatures, le script va déplacer les paquets en question dans OLDDIR en leur ajoutant l'extension << .UPDcheckfail >> et va sortir sans déplacer les anciennes mises à jour dans OLDDIR.


4.2. Utiliser mirror

Mirror est un script perl sophistiqué comparant le contenu d'un répertoire d'un site distant avec un répertoire local. Il utilisera FTP pour récupérer les fichiers qui sont sur le site distant mais pas sur le site local, et supprimera sur le site local les fichiers qui ne sont pas sur le site distant. Le programme mirror est configuré avec un fichier. Le RPM du paquet est disponible à partir de rufus.w3.org. Créez votre copie locale mirror.redhat du fichier de configuration de mirror, et éditez les champs correspondant au haut du fichier. Après la section par défaut, définissez ces paquets:

 
        package=updates
          site=ftp.mirror.ac.uk
          exclude_patt=(SRPMS/)
          remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386
          local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3-updates

        package=dist
          site=ftp.mirror.ac.uk
          exclude_patt=(SRPMS/)
          remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386
          local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3
      

La commande suivante va copier l'arbre RedHat en entier sur votre disque local. **Pensez**, avant de faire cela, que vous allez télécharger à peu près 1,5Go de données (si vous avez exclu le répertoire SRPMS)!

 
        $ mirror -pdist mirror.redhat 
      

Ceci va créer le miroir du site FTP de RedHat sur votre disque local. Le contenu de la distribution RedHat ne change pas entre les releases, donc vous avez seulement besoin de télécharger ces paquets UNE FOIS. Tout changement dans la distribution se trouve dans le répertoire updates. Donc, si vous voulez que votre miroir reste à jour, vous avez seulement besoin d'actualiser le répertoire updates. Cela se fait avec la commande suivante:

 
        $ mirror -pupdates mirror.redhat 
      

Vous pouvez la lancer régulièrement, disons une fois par semaine, avec un script cron. La distribution RedHat est disponible sur un grand nombre de serveurs FTP tout autour du monde, mis à jour quotidiennement à partir du site maître ftp.redhat.com. Vous devriez choisir un site FTP proche de vous, en consultant la liste des sites miroirs RedHat.

Note

Je n'ai pas personnellement testé cette procédure. C'était la seule procédure proposée sur les anciennes versions de ce howto (jusqu'à la version 1.34, concernant RedHat <6.1). Néanmoins, je pense qu'elle a été bien plus testée que mes scripts, donc vous pouvez certainement l'utiliser.


5. Inclure les mises à jour

Il y a trois étapes, les deux premières étant (pratiquement) identiques pour toutes les releases, alors que la dernière change un peu en raison des modifications de l'installateur anaconda:

  1. Corriger les modes de protection de fichier

  2. Remplacer les RPMs mis à jour

  3. Reconstruire l'installateur

Pour incorporer les mises à jour, vous avez besoin d'avoir les droits d'accès au répertoire de la distribution à partir de la machine Linux, avec une version fonctionnelle de rpm installée, alors que pour reconstruire l'installateur anaconda, vous avez besoin d'utiliser une release de RedHat Linux égale à celle pour laquelle vous avez reconstruit l'installateur (sinon la procédure échouera) . Si vous maintenez un miroir du répertoire updates, vous pouvez à tout moment produire un CD incluant les dernières mises à jours en répétant ces étapes.


5.1. Corriger les modes de protection des fichiers

Durant le processus d'installation des releases jusqu'à la 6.2 (comprise), quelques programmes sont lancés directement du CD. Malheureusement, le programme FTP ne préserve pas toujours les modes de protection des fichiers et des répertoires qui sont copiés. Donc, il est nécessaire de s'assurer que la permission d'exécuter est donnée aux programmes, scripts shells et bibliothèques partagées, avant que le répertoire ne soit gravé sur le CD. Ceci est fait en lançant le script updatePerm.sh sur votre copie locale de la distribution. C'est réellement nécessaire pour les versions 6.2 et précédentes, la seule partie utile à la procédure des releases 7.3/8.0 est la mise à jour des permissions des répertoires, même si le reste ne posera pas de problème et que tout restera cohérent. C'est pratiquement identique au script updatePerm inclus dans la précédente version de ce howto, seuls quelques petits changements ont été réalisés. Avant d'utiliser ce script, vous devez configurer le fichier rhcd.conf et exporter la variable RHCDPATH pointant vers le répertoire où se trouve le fichier.

        $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
        $ sh updatePerm.sh
      


5.2. Remplacer les RPMs mis à jour

Le script updateCD.sh copie tous les nouveaux fichiers du répertoire update vers le répertoire RPMS (et SRPMS). Le script utilise le programme rvc qui a été présenté dans la section comparer les versions des RPM pour déterminer quels paquets dans le répertoire update sont les plus récents. Les anciens paquets sont déplacés dans le répertoire ${OLDDIR}. Si la variable CHECKSIG est mise sur << yes >>, tous les paquets dans l'arbre principal verront leur signature vérifiée. Si la vérification de signature d'un paquet échoue (le genre de vérification est configuré par l'usage de la variable USEGPG, assignée dans le fichier rhcd.conf), celui-ci est déplacé dans le répertoire OLDDIR avec une extension ajoutée, << CDcheckfail >>.

Avant d'utiliser ce script, vous devez configurer le fichier de configuration rhcd.conf et exporter une variable RHCDPATH pointant vers le répertoire où se trouve ce fichier.

        $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
        $ sh updateCD.sh
      

Note

Après avoir incorporé les mises à jour dans le répertoire principal RedHat/RPMS, votre copie de la distribution n'est plus un miroir du site de la distribution RedHat. Néanmoins, il est plus à jour! Donc, si vous essayez de faire le miroir de la distribution en utilisant mirror, les anciennes versions des RPMs qui ont été mis à jour seront téléchargées une fois de plus, et les mises à jour supprimées. La procédure basée sur bash/wget ne souffre pas de ce problème, mais laissera l'arbre principal dans un état incohérent. Les anciens et les nouveaux paquets seront dans ce cas mélangés, mais vous pouvez les trouver et les supprimer en intégrant le binaire rvc dans un script shell simple (que je laisserai comme exercice pour le lecteur...).


5.3. Reconstruire l'installateur

Les choses ont bien changé dans cette section avec l'arrivée de l'installateur anaconda (release 6.1) et l'augmentation considérable en taille (et... en nombre de CDs) que les distributions 7.x/8.0 ont connue. Jusqu'à la release 6.2, la seule étape composant cette section était représentée par la génération d'un nouveau fichier hdlist. Avec la release 6.2, cela reste vrai seulement jusqu'à un certain point, en raison des changements dans l'installateur anaconda, dans le logiciel rpm lui-même (à partir des versions 3.x, jusqu'au 4.x) et de la migration des paquets mis à jour vers cette nouvelle version (les mises à jour pour la release 6.2 sont en fait packagées avec les deux releases majeures du logiciel rpm). Nous considèrerons les trois procédures différentes en essayant de couvrir toutes les releases.


5.3.1. RedHat ≤ 6.1

5.3.1.1. Regénérer le fichier hdlist

Lors de l'installation à partir du CD, le programme d'installation sur le CD dépend du fichier RedHat/base/hdlist qui décrit quels sont les paquets RPM disponibles sur le CD. Le fichier hdlist peut être généré par le programme misc/src/install/genhdlist. Ce programme doit être lancé avec le chemin absolu vers la racine de la distribution comme seul argument. Voici le script updateHdlist qui appelle ce programme (à partir de la version 1.34 de ce howto):

            #!/bin/bash

            RHVERSION=6.1
            ARCH=i386

            echo generating hdlist...
            RHROOT=/home/luigi/tmp/redhat-${RHVERSION}
            GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils
          
            chmod u+x ${GENHDDIR}/genhdlist
            chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist
            ${GENHDDIR}/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***"

            exit 0
          

NoteImportante note pour la RedHat < 6.1
 

L'installation de la RedHat 6.1 est complètement différente de celle des versions précédentes, et RedHat a introduit anaconda. Le programme genhdlist est maintenant localisé à un autre endroit, donc dans le script ci-dessus, nous utilisons
              GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils
            
alors que pour les releases jusqu'à la 6.0 (comprise), cette ligne doit être
              GENHDDIR=${RHROOT}/${ARCH}/misc/src/install
            

Dans certains cas, genhdlist échoue lors de son exécution, parce que l'exécutable n'est pas lié statiquement. Dans un tel cas, vous pouvez ajouter une nouvelle ligne ${RHROOT}/${ARCH}/RedHat/instimage/usr/lib dans /etc/ld.so.conf et lancer ldconfig -v.

Une autre solution est de recompiler genhdlist. La modification suivante au script updateHdlist a fonctionné sous RedHat 5.2:
	    #!/bin/bash

	    RHVERSION=6.1
	    ARCH=i386

	    RHROOT=/misc/redhat/redhat-${RHVERSION}
	    GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils

	    echo Compiling genhdlist...
	    sed -e 's/FD_t/int/' \
	        -e 's/fdOpen/open/' \
	        -e 's/fdClose/close/' \
	        -e 's/fdFileno//' < ${GENHDDIR}/genhdlist.c > /tmp/genhdlist.c
	    cc -o /tmp/genhdlist -I/usr/include/rpm /tmp/genhdlist.c -lrpm -lz

	    echo generating hdlist...
	    chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist
	    /tmp/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***"

	    exit 0
	  

Dans cette version du script, une copie du source C de genhdlist.c est envoyée à sed à travers un pipe pour créer une copie dans /tmp qui compilera sous RedHat 5.2. Cette version de genhdlist est alors utilisée pour créer le fichier hdlist.

NoteImportante note pour la RedHat 5.2
 

Tel qu'il est distribué avec la RedHat versions 5.2 et précédentes, genhdlist PLANTE si les fichiers dans le répertoire RedHat/RPMS ne sont pas des fichiers RPM! Il cause des problèmes parce que dans la distribution 5.2, il existe un couple de fichiers non-RPM nommés ls-lR et ls-lR.gz situés dans RedHat/RPMS. Donc, vous devez supprimer tous les fichiers non-RPM du répertoire. Sinon, vous pouvez appliquer le correctif genhdlist.c.diff au fichier misc/src/install/genhdlist.c et faire un make. Ce correctif fait que genhdlist ignore tout fichier non-RPM.


5.3.1.2. Créer l'image iso du CD

Vous aurez besoin de créer un fichier image qui sera écrit sur le CD. Ce fichier fera 500Mo ou plus donc trouvez une partition avec assez d'espace disque libre. Vous pouvez avoir besoin d'être root pour utiliser mount et cdrecord. Ici, vous préparerez l'image iso du CD amorçable à graver. Il n'est pas strictement nécessaire de créer un CD amorçable parce que vous pouvez utiliser une disquette de démarrage à la place, mais c'est vraiment une fonctionnalité sympathique (et elle rend votre disque plus similaire au disque général). Voici les commandes que j'utilise pour réaliser cette tâche:
            $ mkdir /images-destination-dir
            $ mkisofs  -r  -J  -T  -v  -V "Red Hat 6.1 (Hedwig)" \
                -c boot.cat  -b images/boot.img \
                -o /images-destination-dir/i386-disc.iso .
          
C'est nécessaire pour graver le disque (amorçable) et c'est exécuté à partir du répertoire haut niveau de la distribution. Le répertoire /images-destination-dir est le contenant de l'image iso que vous générez, et il doit exister (nécessairement) avant le lancement de la procédure. Dans la table suivante, vous pouvez lire une brève explication des nombreuses options et de leurs motivations (la plupart ont été extraites de la page man de mkisofs).

Tableau 1. Options et paramètres de mkisofs

-r Extensions Rock Ridge avec les valeurs utiles pour les permissions
-J Extensions Joliet pour utiliser le CD avec quelques différents systèmes d'exploitation
-T Génère un fichier TRANS.TBL dans chaque répertoire pour faire correspondre les noms de fichiers même sur des systèmes qui ne supportent pas des extensions Rock Ridge
-v Soit verbeux

-V <volid>

 Spécifie l'ID du volume (nom du volume ou label) à écrire dans le bloc maître.

-c <boot catalog>

 Spécifie le chemin et le nom du fichier du catalogue de démarrage à utiliser lors de la création du CD amorçable "El Torito". Le nom du fichier doit être relatif au chemin source spécifié à mkisofs.

-b <eltorito boot image>

 Spécifie le chemin et le nom du fichier de l'image de démarrage à utiliser lors de la création du CD amorçable "El Torito". Le chemin doit être relatif au chemin source spécifié à mkisofs et doit indiquer une image de disquette (ce qui explique pourquoi nous utilisons une des images de disquette trouvée sur le CD original). Vous pouvez vouloir le changer avec l'image pcmcia.img pour installer en utilisant des périphériques pcmcia comme des cartes réseau ou des lecteurs CDROMs.

-o <filename>

 Nom du fichier contenant l'image iso généré
. Ceci est le répertoire racine de notre image iso (nous sommes en train de travailler à partir du répertoire racine de chaque CD, donc un point est suffisant).

Vous trouverez des détails sur la façon de graver une image sur un média dans graver le CD. Les étapes mkisofs et cdrecord peuvent être exécutées en utilisant une application graphique comme X-CD-Roast qui doit déjà supporter la création de CDs amorçables (je ne l'ai jamais fait, donc ne vous attendez pas à ce que je vous donne une explication).


5.3.2. RedHat 6.2

Apparemment, il existe un problème lorsque vient le moment de graver un CD à mettre à jour. L'introduction de la version 4 du gestionnaire de paquets RedHat (RPM) fait que la procédure de mise à jour de l'installateur anaconda échoue. Donc les procédures listées fonctionneront seulement si les paquets mis à jour sont construits en utilisant une version du logiciel RPM qui est antérieure ou égale à la 3.0.5 (donc, basiquement, 3.0.4 ou 3.0.5).

Si vous utilisez les paquets originels de RedHat, il faut éviter d'utiliser les mises à jour sorties après le 28 mars 2001 (ce qui est un peu inutile, selon moi) ou alors vous devez reconstruire les paquets en utilisant l'ancien format rpm. Les détails sur la procédure et les outils qui l'implémentent peuvent être trouvés dans le document rpmhack. Je n'ai pas personnellement testé cette procédure, mais elle semble fonctionner d'après les listes de diffusion anaconda-devel et kickstart (vous pouvez les trouver sur la section des listes de diffusion du site web de RedHat.

Si vous décidez de rester sur les anciens paquets originels et de compléter la mise à jour (en utilisant les paquets rpm 4.0.2 après que l'installation est finie), il existe deux façons de le faire, en fonction du type de mise à jour que vous souhaitez faire. Si certaines des mises à jour dépendent directement du processus d'installation (c'est-à-dire le noyau, python, kudzu), vous devrez utiliser la procédure de reconstruction de l'installateur expliquée dans le document Construire un CDROM Red Hat Linux 6.2, sinon vous pouvez toujours utiliser l'ancienne procédure (celle pour les releases précédentes jusqu'à la 6.1 comprise, expliquée dans la section précédente). Les deux dernières étapes, qui sont la création de l'image iso et la gravure du media, sont décrites respectivement dans créer des images iso et graver le CD.


5.3.3. RedHat 8.0 et 7.3

Une fois encore, beaucoup de choses ont été changées avec la release des séries 7.x de la distribution. Il y a maintenant plus d'opérations à réaliser pour obtenir une série de CDs frais et mis à jour. En réalité, le CD a cessé d'être unique avec la release 7.0 et maintenant l'arbre doit être divisé pour tenir sur le média. Ceci est fait en utilisant le script splitdistro, qui est écrit en python comme beaucoup d'éléments de l'installateur anaconda. Pour terminer cette partie, vous devez utiliser une machine Linux RedHat 7.3 ou 8.0 avec le paquet anaconda-runtime installé (il aura probablement la version 7.3.7 ou 8.0.4), en fonction de la release que vous voulez reconstruire. La procédure est composée de sept étapes, qui sont placées ensemble dans un script shell dans la dernière section:

  1. Regénérer les fichiers hdlist et hdlist2

  2. Mettre à jour le fichier comps.xml

  3. Reconstruire l'installateur

  4. Diviser la distribution en plusieurs parties de la taille d'un CD

  5. Regénérer (encore) les fichiers hdlist et hdlist2

  6. Générer les images iso

  7. Ajouter et vérifier les signatures md5 dans les images iso

Toutes les étapes sont regroupées dans un seul script présenté dans la dernière section.


5.3.3.1. Opérations préliminaires sur l'arbre principal

Quelques uns des scripts inclus dans le paquet anaconda-runtime ont besoin de l'arbre principal qui doit être déplacé dans un sous-répertoire nommé comme l'architecture que nous allons construire (donc i386/ pour moi). Nous déplacerons tout vers un tel répertoire avant de lancer la procédure et de modifier l'invocation des scripts qui n'ont pas besoin de cette modification.

Pour la RedHat 8.0:
            $ chmod  -R  u+w  /absolute-path-to-toplevel-dir
            $ mkdir  -p  /absolute-path-to-toplevel-dir/i386
            $ cd /absolute-path-to-toplevel-dir
            $ /bin/mv  *  i386
          
Vous devez changer << /chemin-absolu-vers-le-répertoire-haut-niveau >> avec le chemin absolu du répertoire où la racine de votre copie locale de la distribution est placée (peut-être quelque part sur un disque dur). Vous obtiendrez une erreur, à partir de l'exécution de la dernière commande, parce que le répertoire i386/ ne peut être déplacé sous lui-même, mais vous n'avez pas besoin de vous en soucier.

Pour redhat 7.3:
            $ chmod  -R  u+w  /absolute-path-to-toplevel-dir
            $ mkdir  -p  /absolute-path-to-toplevel-dir/i386
            $ cd /absolute-path-to-toplevel-dir
            $ for i in `ls` ; do [ $i != "SRPMS" -a $i != i386 ] && /bin/mv $i i386 ; done
          
Vous ne devriez recevoir aucun message d'erreur cette fois, après la dernière commande (avec un peu d'espoir).


5.3.3.2. Regénérer les fichiers hdlist et hdlist2

Ceci est fait au moyen des deux commandes suivantes avec l'aide du programme genhdlist.
            $ /usr/lib/anaconda-runtime/genhdlist  /absolute-path-to-toplevel-dir/i386
            $ chmod  644 /absolute-path-to-toplevel-dir/i386/RedHat/base/hdlist{,2}
          
Une fois encore, << /chemin-absolu-repertoire-haut-niveau >> est le chemin absolu de ce répertoire où la racine de votre copie locale de la distribution est placée. La seconde commande est nécessaire pour vous assurer que les permissions sont correctes pour ce fichier. Vous devez déjà avoir une idée de ce que sont ces fichiers si vous avez lu le répertoire RedHat.


5.3.3.3. Mettre à jour le fichier comps.xml

Dans RedHat Linux 8.0, le format du fichier comps a complètement changé et il est maintenant basé sur XML. Il apporte beaucoup plus de flexibilité et de facilité de personnalisation comme vous pouvez le lire dans le fichier comps. Si vous avez modifié ou si vous souhaitez modifier la liste des paquets installés, vous avez besoin de terminer cette étape. Cela implique en retour d'avoir installé le paquet comps-8.0.tar.gz qui contient le fichier maître comps trouvé sur le site web de RedHat et le paquet rpm comps-extras. Suivez alors ces étapes (seulement pour Redhat 8.0):
            $ cd /some-dir-of-your-choice
            $ tar xzvf /path-to-comps-8.0.tar.gz/comps-8.0.tar.gz 
            $ cd comps
            $ make
            $ cat comps-milan.xml |sed 's!</comps>!!g' >comps-tmp.xml
	    $ /usr/share/comps-extras/getfullcomps.py  comps.xml \
                 /absolute-path-to-toplevel-dir i386 >> comps-tmp.xml
	    $ echo '</comps>' >> comps-tmp.xml
	    $ cp comps-tmp.xml /absolute-path-to-toplevel-dir/i386/RedHat/base/comps.xml
          
Avec << /chemin-absolu-repertoire-haut-niveau >>, vous devez prendre soin d'assigner les noms valides vers << /répertoire-de-votre-choix >> et << /chemin-vers-comps-8.0.tar.gz >>. Le reste des commandes peut simplement etre copié.

Avant de lancer la commande make, vous devez modifier le fichier comps-milan.xml.in en utilisant votre éditeur de texte favori et en suivant les lignes de conduite et les suggestions trouvées dans le fichier comps et dans la section anaconda comps du site web RedHat.

Le script présenté dans la dernière section exécutera toutes les étapes nécessaires après la commande make, en utilisant la variable COMPSFILE pour trouver le fichier comps-milan.xml (il n'a pas besoin d'avoir ce nom, j'utilise juste le nom original, mais vous pouvez le changer si vous le voulez).

Si vous utilisez RedHat 7.3, le fichier comps (avez-vous noté la différence de nom...) est un fichier textuel avec une syntaxe complètement différente décrite avec plus de détails dans le fichier comps. Dans ce cas, les seules opérations nécessaires modifient le fichier pour coller à vos besoins et copier le fichier RedHat/base/comps dans l'arbre principal écrasant l'original.


5.3.3.4. Reconstruire l'installateur

Ceci reconstruira l'installateur anaconda dans votre copie locale de la distribution en utilisant les paquets mis à jour.
            $ /usr/lib/anaconda-runtime/buildinstall  \
                --pkgorder /absolute-path-to-toplevel-dir/pkgorder.txt  \
                --comp dist-8.0 --version 8.0  --release "Redhat 8.0 (Psyche)" \
                /absolute-path-to-toplevel-dir/i386  
          
Où, une fois encore, << /chemin-absolu-vers-le-répertoire-haut-niveau >> est le répertoire où la racine de votre copie locale de la distribution est placée.

Pour la Redhat 7.3, la procédure est pratiquement la même:
            $ /usr/lib/anaconda-runtime/buildinstall  \
                --pkgorder /absolute-path-to-toplevel-dir/pkgorder.txt  \
                --comp dist-7.3 --version 7.3 /absolute-path-to-toplevel-dir/i386  
          

L'absence de l'option (obligatoire pour la 8.0) --release est la seule différence notable.


5.3.3.5. Diviser la distribution

Ceci créera cinq répertoires, chacun correspondant à un CD différent et placera dedans des liens physiques vers les fichiers réels contenus dans votre copie locale de la distribution.

Note

Ceci ne fonctionnera pas du tout pour la RedHat 7.3 si vous n'utilisez pas la version modifiée du script splitdistro rapporté dans le prochain paragraphe. Pour RedHat 8.0, une version modifiée de splitdistro est proposée principalement parce que, même si les problèmes du script précédent ont été corrigés, l'exécution échouait toujours si il n'existait pas suffisament de paquets pour remplir tous les CDs (les quatre premiers complètement et le dernier juste partiellement).

            $ $/usr/lib/anaconda-runtime/splitdistro  \
              --fileorder /absolute-path-to-toplevel-dir/pkgorder.txt  --release \
                "Redhat 8.0 (Psyche)"  /absolute-path-to-toplevel-dir  i386 
          
La seule chose que vous avez besoin de changer pour la 7.3 est la phrase passée à l'option --release (qui doit être << Redhat 7.3 (Valhalla) >>).

Pour la Redhat 7.3, la version utilisée du script (python) splitdistro7.3 était extraite du paquet anaconda-runtime 7.3.7 et modifiée par moi. Vous pouvez le substituer à l'original (peut-être après avoir copié ce dernier) nommé /usr/lib/anaconda-runtime/splitdistro.

La seule modification (en dehors de quelques petites corrections) que le script a subie est un changement dans son comportement si le répertoire SRPMS n'est pas trouvé (il ne se termine pas, mais génère les CDs sans les paquets source).

Pour la Redhat 8.0, la version utilisée du script (python) splitdistro8.0 a été extraite du paquet anaconda-runtime 8.0.4 et modifiée une fois encore par moi pour obtenir certaines améliorations dont je ressentais le besoin. Vous devez y substituer le fichier original (peut-être après avoir copié le dernier) nommé /usr/lib/anaconda-runtime/splitdistro. Néanmoins, l'original fonctionne bien, si vous voulez construire une distribution qui a tous les paquets SRPMS (donc pour remplir tous les cinq CDs, sinon le script échouera).

La seul modification apportée au script est un changement dans son comportement si le répertoire SRPMS n'est pas trouvé (il ne se termine pas en échouant, mais génère les CDs sans les paquets source) ou s'il y a un CD qui n'a aucun paquet (au lieu d'échouer , le script génère un répertoire vide).


5.3.3.6. Regénérer les fichiers hdlist et hdlist2

Il est nécessaire de recréer les fichiers hdlist et hdlist2, en utilisant quelques unes des informations obtenues dans les étapes précédentes. Il n'y a pas de différences entre 7.3 et 8.0 pour l'exécution du programme. La commande à envoyer est la suivante:
             $ /usr/lib/anaconda-runtime/genhdlist  \
                 --fileorder /absolute-path-to-toplevel-dir/pkgorder.txt  --withnumbers \
                 /absolute-path-to-toplevel-dir/i386-disc[1-3]
           
Comme vous pouvez le voir, il y a deux nouvelles options passées au programme, si vous vous rappellez le premier lancement. Le premier, --fileorder, indique à genhdlist d'utiliser le fichier pkgorder.txt que nous avons généré lors de la seconde étape (reconstruire l'installateur). Ce fichier garde les informations sur la division des paquets sur les différents CDs, et est utilisé par l'installateur pour déterminer dans quel ordre les paquets doivent être installés. De manière simple, si vous ne l'utilisez pas, vous finirez probablement en échangeant les différents CDs plusieurs fois durant l'installation. L'option --withnumbers est nécessaire pour associer un numéro de CD à chaque paquet (comme vous le voyez, une expression régulière indiquant les trois premières images iso est utilisée).


5.3.3.7. Générer les images iso

Ici, vous préparez les cinq images iso à graver sur les CDs actuels. Il y a deux commandes différentes à utiliser pour le premier disque et pour le reste. Ceci est dû au besoin d'obtenir un premier CD qui soit amorçable. Ceci n'est pas strictement nécessaire parce que vous pouvez utiliser une disquette de démarrage à la place, mais il s'agit d'une fonctionnalité intéressante (et elle rend le comportement de vos disques plus similaire aux originaux). Il existe des commandes que j'utilise pour terminer la tâche:

              $ mkdir /images-destination-dir
              $ mkisofs  -r  -J  -T  -v  -V "Red Hat 8.0 (Psyche) disc 1" \
		  -c isolinux/boot.cat  -b isolinux/isolinux.bin -no-emul-boot \
                  -boot-load-size 4 -boot-info-table -o /images-destination-dir/i386-disc1.iso .
            
Cela est nécessaire pour graver le premier disque (amorçable) pour la RedHat 8.0 (sans émulation de disquette) et c'est exécuté à partir du répertoire haut-niveau de la distribution. Le répertoire /repertoire-destination-images est le contenant pour les cinq images iso que vous avez générées, et il doit exister avant de lancer la procédure.

              $ mkdir /images-destination-dir
              $ mkisofs  -r  -J  -T  -v  -V "Red Hat 7.3 (Valhalla) disc 1" \
                  -c boot.cat  -b dosutils/autoboot/boot.img \
                  -o /images-destination-dir/i386-disc1.iso .
            
Il est nécessaire de graver le premier disque (amorçable) sur la 7.3 et de l'exécuter à partir du répertoire haut-niveau de la distribution (cette fois avec une émulation de disquette).

Le reste des images peut être écrit au moyen d'une boucle << for >>
              $  for i in `echo 2 3 4 5` ; do mkisofs  -r  -J  -T  -v  \
                   -V "Red Hat 8.0 (Psyche) disc ${i}"  \
                   -o /images-destination-dir/i386-disc${i}.iso . ; done
            
La boucle présentée va préparer les quatre dernières images en leur donnant les bons numéros. Comme vous pouvez le voir, il y a deux options manquantes à partir du premier lancement, et, comme vous pouvez le deviner, elles sont nécessaires uniquement pour créer un CD amorçable. Dans créer des images iso, vous pouvez lire une brève explication sur les différentes options et leur significations (la plupart ont été extraites des pages man).


5.3.3.8. Implanter et vérifier les signatures md5 dans les images iso

C'est une étape optionnelle mais elle permet l'utilisation de l'option << checkmedia >> pour vérifier les signatures des CDs avant de les installer, et donc de garantir leur correction.

Les commandes suivantes permettent d'injecter ou de vérifier une signature md5 sur une image iso:
            $ /usr/lib/anaconda/implantisomd5 iso-image
            $ /usr/lib/anaconda/checkisomd5 iso-image
          

Après avoir fini toutes ces étapes, nous aurons les cinq images CD à graver. Considérant que taper tout ceci prend du temps, dans la prochaine section sera présenté un script qui réalisera toutes les opérations listées en une seule fois (n'oubliez pas de configurer les paramètres proprement).


5.3.3.9. Réunir toutes les étapes

Le script updateBuild.sh exécutera toutes les étapes nécessaires pour reconstruire les CDs de distribution pour la RedHat 7.3 ou 8.0 en un seul lancement (réalisé en tant que root). Avant d'utiliser ce script, vous devez configurer le fichier rhcd.conf après l'exportation d'une variable RHCDPATH pointant vers le répertoire où se trouve ce fichier. Si vous voulez inclure le fichier comps.xml modifié (ou comps) dans vos CDs comme expliqué dans le fichier comps, vous devrez le copier à l'emplacement défini au moyen de la variable COMPSFILE maintenant (avant d'exécuter le script). N'oubliez pas d'ajouter le script modifié splitdistro dans le répertoire /usr/lib/anaconda-runtime si vous en avez besoin.

            # export RHCDPATH=/home/luigi/tmp/rhcd-scripts
            # sh updateBuild.sh
          


6. Graver les CD(s)

Cette étape est composée d'une partie optionnelle et d'une partie obligatoire. Rappellez-vous que vous avez, probablement, besoin d'être << root >> sur votre machine pour lancer cdrecord.


6.1. Tester l'image ou les images

Si vous êtes paranoïaque, vous pouvez tester votre nouvelle image disque en la montant. Si vous oubliez de corriger les permissions des fichiers ou de mettre en place les extensions rock ridge, alors l'erreur sera évidente comme les noms de fichier et la structure des répertoires seront erronés. Le test (optionnel) peut être réalisé en tapant la commande suivante:

 
        # mount -t iso9660 -o ro,loop=/dev/loop0 iso-image /mnt/cdrom
      

<< iso-image >> est le nom que vous avez donné à l'image iso à monter (qui doit être seule pour les releases supérieures ou égales à la 6.2). Quand vous avez terminé, n'oubliez pas de la démonter.

        # umount /mnt/cdrom
      


6.2. Graver le(s) disque(s)

Assurez-vous que vous avez mis en place les bons paramètres pour votre périphérique. Par exemple, cette commande est pour un graveur 4x, ce qui est assez lent. De plus, il est vérifié que le graveur CD est ici sur le bus SCSI numéro 0, avec l'ID 0, LUN 0 (vous pouvez obtenir ces valeurs en lançant un cdrecord -scanbus et assignez-les au paramètre -dev=).

        # cdrecord -v speed=4 dev=0,0,0 /images-destination-dir/disc1.img
      


7. Le fichier comps

Le fichier comps définit comment les paquets seront assemblés durant l'installation. Dans la distribution RedHat, ceci est fait selon la fonctionnalité qu'ils procurent, par exemple:

Quelquefois durant le processus d'installation, l'utilisateur se trouve face à une fenêtre appelée "Composants à installer". Quelques-uns des composants ont été présélectionnés, d'autres non. Le dernier point sur la liste des composants est appelé "Tout". Sur la fenêtre, il existe aussi une option qui permet à l'utilisateur de personnaliser très précisément la liste des paquets qui seront installés. Personnaliser l'installation à la main, ou sélectionner "Tout" dans la liste des composants est le seul moyen d'avoir vos propres paquets installés, sauf si vous modifiez le fichier RedHat/base/comps.


7.1. Format du fichier comps pour RedHat versions < 6.1

Le fichier comps commence avec un entête décrivant la version du format comps, suivie d'une ligne vide.
        0.1
        <empty line>
      

Après ceci, les composants sont listés, séparés par des lignes vides:
        <composant 1>
        <ligne vide>
        <composant 2>
        <ligne vide>
        ....
        <composant n>
        <ligne vide>
        EOF
      

Chaque composant a la définition suivante:
        (0|1) (--hide)? <name>
        <RPM 1>
        <RPM 2>
        ...
        <RPM n>
        end
      

Avant le nom de chaque composant est placé un 0 ou un 1. Une valeur de 1 à cet endroit veut dire que le composant est choisi par défaut, et un 0 veut dire le contraire. L'option --hide veut dire que vous ne pouvez pas voir l'entrée, sauf si vous choisissez l'installation << en mode expert >>. Le premier composant est appelé << Base >>, et il est spécial, dans le sens où il doit être présent et qu'il n'apparait pas dans le dialogue (vous ne pouvez pas désélectionner l'installation de la base, ce qui est sensé). Suit une liste de paquets RPM appartenant à ce composant. Notez qu'il s'agit du nom du paquet stocké dans le fichier rpm, et non pas d'une partie du nom du fichier du paquet (bien qu'il doive être identique par convention).

En ajoutant vos paquets au fichier comps, vous pouvez personnaliser votre propre distribution, et vous assurer que vos paquets seront installés par défaut. Une chose à laquelle vous devez porter attention est l'interdépendance entre vos paquets, mais ici c'est à vous de jouer :-) Un mot pour vous prévenir: faites attention de ne pas ajouter ou supprimer les espaces blancs supplémentaires dans le fichier. Examinez le fichier comps existant (faites une copie de l'original) pour voir comment il est fait (ou vérifiez i386/misc/src/install/pkgs.c si vous voulez voir comment le fichier est analysé).


7.2. Format du fichier comps pour RedHat version 6.1

Avec RedHat version 6.1, le format du fichier comps a changé. Le décodage s'effectue dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Je n'ai pas encore analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier comps et en testant quelques configurations.

Dans la release 6.1, la définition du composant est étendue pour inclure quelques éléments optionnels supplémentaires avant les <RPM>. Ces élements sont:
          <RPM-dépendant-de-architecture 1>
          ...
          <RPM-dépendant-de-architecture n>
          <composant-requis 1>
          ...
          <composant-requis n>
          <RPM-composant-dépendant 1> 
          ...
          <RPM-composant-dépendant n>
        

Un <RPM-dépendant-de-architecture> définit une dépendance entre un paquet et une architecture spécifique et a la définition suivante:
          (!)?arch: <RPM>
        

Donc il peut, par exemple, se présenter, dans le monde réel, comme:
          !alpha: kernelcfg
        
ce qui veut dire: si l'architecture n'est pas alpha alors il faut installer le paquet kernelcfg.

Ou comme:
          i386: mkbootdisk
        
Ce qui veut dire: si l'architecture est i386 alors il faut installer le paquet mkbootdisk

Un <composant-requis> renforce la dépendance avec un autre composant et il est défini comme:
          @ <component>
        

Donc, par exemple, si à l'intérieur de la définition d'un composant, vous trouvez la ligne suivante:
          @ Station Réseau
        
cela veut dire que le composant lui-même a besoin de l'installation d'un autre composant nommé Station Réseau.

Un <RPM-composant-dépendant> est utilisé pour sélectionner l'installation de quelques paquets additionnels pour un composant, étant donné la présence d'un autre composant. Sa définition est la suivante:
          ? <composant> { 
            <RPM 1>
            ...
            <RPM n>
          }
        

Donc si, par exemple, dans la définition d'un composant, il vous arrive de lire les lignes suivantes:
        ? KDE { 
          kpppload
        }
      
alors si le composant KDE est installé, le paquet kpppload sera installé avec les paquets inclus dans le composant où la définition se trouve.


7.3. Format du fichier comps dans RedHat version 6.2

Avec RedHat version 6.2, le format du fichier comps a apparemment un peu changé. Le décodage se fait aussi dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Encore une fois, je n'ai pas analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier et en testant quelques configurations.

Dans la release 6.2, la définition du composant est étendue pour inclure deux éléments optionnels supplémentaires:
        <RPM-dépendant-language 1>
        ...
        <RPM-dépendant-language n>
        <composant-dépendant-architecture 1>
        ...
        <composant-dépendant-architecture n>
      

Un <RPM-dépendant-language> est nécessaire pour spécifier l'installation d'un paquet au cas où une langue spécifique a été sélectionnée. C'est défini ainsi:
        (lang <language>): <RPM>
      

Par exemple, la ligne suivante
        (lang ja_JP)): locale-ja
      
veut dire: si la langue japonaise est sélectionnée, alors il faut installer le paquet locale-ja avec les autres paquets installés pour ce composant.

Un <composant-dépendant-architecture> étend le concept du <RPM-dépendant-architecture>, introduit lors de la release 6.1, au composant entier, comme vous pouvez le comprendre à la lecture de sa définition:
        (!)?arch: <component>
      


7.4. Format d'un fichier comps dans la RedHat version 7.3

Avec la RedHat version 7.3, le format du fichier comps a gagné en syntaxe. Le décodage prend place (encore) dans le script comps.py, que vous pouvez maintenant trouver dans le répertoire /usr/lib/anaconda/ si vous avez installé le paquet anaconda. Les dépendances sur une langue ou sur une architecture pour un composant ou un paquet peuvent maintenant être liées avec l'opérateur and. Par exemple:
        (arch !s390 and arch !s390x and arch !ia64): readline2.2.1
      

ce qui veut dire que si l'architecture n'est ni s390, ni s390x, ni ia64, alors il faut installer le paquet readline2.2.1. Ceci peut être fait avec des composants au lieu des paquets, et avec des langues à la place des architectures. Tout ceci est définitivement plus qu'assez pour les simples exemples de personnalisation de l'installation par défaut qui seront présentés dans la prochaine section.


7.4.1. Personnaliser l'installation par défaut de la RedHat version 7.3

L'exemple que nous allons parcourir dans cette section implique des modifications dans le fichier comps pour changer les valeurs par défaut qui concernent l'installation des paquets. Je préfère habituellement, particulièrement dans certaines situations, une installation par défaut incluant seulement les paquets de base, avec quelques légères modifications pour certains d'entre eux. Dans le premier des exemples présentés, nous construirons une installation par défaut qui ajoute libsafe au composant << Base >>, dont la plupart des paquets, qui sont généralement installés par défaut, sont déselectionnés, dans le but de construire une installation minimale. Dans le second des exemples, nous modifierons quelques-uns des composants pour construire une autre installation minimale qui remplit nos besoins (cette fois, pratiquement parfaitement; ce sont, en fait, mes besoins, les vôtres peuvent varier). Si vous voulez inclure un fichier comps modifié dans vos CDs, vous devez le copier dans l'arbre principal juste avant de lancer reconstruire l'installateur 7.3 ou 8.0.


7.4.1.1. Ajouter des RPMS et désélectionner les composants par défaut

Pour personnaliser votre installation de cette façon, vous devez éditer le fichier comps avec votre éditeur de texte favori (faites attention à ne pas laisser d'espaces ou de tabulations dans ce fichier) et le déplacer dans le répertoire Redhat/base en écrasant l'original.

Dans le premier fichier comps inclus, le paquet libsafe était ajouté dans le composant << Base system >> et presque tous les composants étaient désélectionnés pour obtenir une installation par défaut comportant seulement 200 paquets (je sais qu'ils sont encore trop nombreux).


7.4.1.2. Modifier quelques-uns des composants standards

Nous construisons le deuxième fichier comps ci-joint à partir de l'étape précédente, pour réduire un peu plus l'installation par défaut (cette fois, il n'y aura plus que 154 paquets dans l'installation par défaut). Quelques-uns des groupes ont été divisé pour donner à l'installation plus de granularité. Toutes les modifications que vous faites doivent prendre en compte les interdépendances entre paquets et les applications utilisées durant les phases d'installation (vous ne pouvez pas supprimer kudzu, par exemple, du composant Base, même si vous pouvez le faire après installation). Il doit être dit que des résultats similaires peuvent être obtenus en utilisant kickstart. Pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation de RedHat Linux.


7.5. Format du fichier comps à partir de RedHat version 8.0

Avec la RedHat version 8.0, le format du fichier comps a été complètement changé et on utilise maintenant un fichier XML, nommé comps.xml. Les détails sur la syntaxe du fichier peuvent être trouvés dans la section anaconda comps du site web de RedHat.


7.5.1. Personnaliser l'installation par défaut de la RedHat version 8.0

Nous reproduirons maintenant les exemples présentés pour la release 7.3 en prenant en compte les modifications soumises aux différents groupes. Le groupe le plus important (le groupe << Base >>, divisé ici en deux groupes nommés << Base >> et << Core >>) doit représenter l'installation minimale.


7.5.1.1. Notre premier exemple revisité...

Cette fois, pour personnaliser votre installation, vous devez éditer le fichier comps-milan.xml.in avec votre éditeur de texte favori. Le fichier peut être trouvé dans l'archive comps-8.0.tar.gz sur le site web de RedHat. Pour ajouter les informations de paquets au fichier que vous venez de créer, vous avez besoin d'avoir installé le paquet rpm comps-extras. Les commandes à lancer pour terminer les opérations sont listées dans mettre à jour comps.xml et dans la documentation. Après avoir créé le fichier, vous devez le copier dans le répertoire Redhat/base en écrasant l'original. Si vous utilisez le script updateBuild.sh, vous devez seulement copier comps-milan.xml (après avoir modifié comps-milan.xml.in qui se trouve dans le paquet tar/gzip comps-8.0.tar.gz et lancé la commande make), à l'emplacement que vous avez déjà configuré dans la variable COMPSFILE (dans rhcd.conf).

Dans le premier fichier comps ci-joint, le paquet libsafe a été ajouté au groupe (composant) << Base >> et pratiquement tous les groupes (composants) ont été déselectionnés, sauf << Base >> et << Core >>, pour avoir une installation par défaut de seulement 220 paquets environ (probablement trop nombreux, encore une fois).


7.5.1.2. Notre deuxième exemple revisité...

Nous construisons le deuxième fichier comps ci-joint sur la précédente configuration et réduisons un peu plus l'installation par défaut (cette fois, il restera seulement 158 paquets de l'installation par défaut). Encore une fois, des résultats similaires peuvent être obtenus en utilisant kickstart, pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation de la RedHat Linux. Dans cet exemple, je n'ai pas désélectionné complètement l'installation du groupe, parce qu'il y a trop de paquets que j'utilise, donc j'ai juste désélectionné l'installation par défaut pour ces paquets en les rendant optionnels. Comme vous pouvez le voir, même le paquet redhat-logos dans le groupe << Base >> a été rendu optionnel. En considérant que les paquets présents dans ce groupe doivent représenter la plus petite installation possible, vous ne voudrez probablement pas le faire (de plus, mes CDs fonctionnent même ainsi; il doit exister quelques problèmes que je n'ai pas encore détectés). La dernière modification visible a été faite au groupe << dialup >>, qui sera installé même s'il est désélectionné, parce que le groupe << core >> en dépend (ce qui est indiqué dans la définition du groupe lui-même).


8. Installer à partir du CD

Lors de l'installation à partir du nouveau CD, vous pourriez avoir tout d'abord besoin de créer une disquette d'installation amorçable. IMPORTANT: utilisez une NOUVELLE disquette, tout juste formatée MS-DOS!. Utiliser une vieille disquette peut provoquer des problèmes étranges lors de l'installation! Sur un système Linux, vous pouvez créer la disquette en utilisant la commande dd:

      $ dd if=/mnt/cdrom/images/boot.img of=/dev/fd0 bs=1440k 
    

Sur un système tournant sous DOS ou Windows-9x, vous avez besoin d'utiliser le programme rawrite.exe, disponible sur le CD dans le répertoire dosutils. Sur une machine sous Windows-9x/Me/NT/2k, vous pouvez utiliser rawritewin.exe situé dans le répertoire dosutils/rawritewin.

Arrêtez la machine sur laquelle vous voulez l'installer (ou faire une mise à jour du système), insérez la disquette de démarrage et votre CD tout juste gravé, et laissez la machine démarrer à partir de la disquette. Pour plus d'informations sur le processus d'installation, voir les documents et le Installation-HOWTO ou le Bootdisk-HOWTO.


8.1. Démarrer d'un CD amorçable

La plupart des machines modernes sont capables de démarrer à partir d'un CD, à condition qu'il soit rendu amorçable avec la procédure indiquée dans la section créer des images iso. Souvent, néanmoins, vous avez besoin de changer le paramétrage du BIOS pour permettre le démarrage à partir du lecteur de CD. Voir la documentation de votre carte-mère pour savoir comment le faire.


9. Autres distributions Linux

Les informations présentes dans les précédentes versions de ce howto (≤1.34), et reportées dans ce présent document, s'appliquant aux releases jusqu'à la 6.1 de RedHat Linux comprise, sont supposées s'appliquer à toutes les distributions clones de RedHat, telle que la distributionMandrake. Malgré tout, la procédure est reportée comme non testée (comme vous pouvez le lire dans le howto lui-même).

Des considérations similaires s'appliquent à la distribution LinuxPPC pour Apple PowerMacs. Pour créer une distribution pour la plateforme PowerMac, vous avez besoin d'utiliser mkhybrid au lieu de mkisofs et ce doit être la seule différence.

Les informations apportées pour les nouvelles releases de RedHat (>6.1) ne doivent pas fonctionner avec Mandrake, qui a maintenant un installateur vraiment différent de celui de RedHat. Je ne sais vraiment pas si quelques autres clones de RedHat peuvent avoir leur distribution CDs mise à jour de cette façon, mais je serais heureux que vous me le disiez.


10. Ce document...

Le source SGML de la plus récente version de ce document peut être trouvée à partir d'ici.


10.1. Documents en rapport

10.1.1. Documentation en rapport à la version actuelle

Les documents suivantes ont été utiles pour la création de ce howto:

Le mini-HOWTO (non officiel) sur l'installateur personnalisé pour la RedHat 7, par Tony Nugent, que vous pouvez trouver sur www.linuxworks.com.au

Miguel Freitas a écrit le mini-HOWTO CDs RedHat7, que vous pouvez lire sur ce site web.

Ron Yorston a écrit le document rpmhack, intéressant pour la release 6.2 de Redhat Linux.

Quelqu'un (je n'ai pas trouvé son nom) a écrit le document Construire un CDROM Red Hat Linux 6.2, utile pour la release 6.2.


10.1.2. Documentation en rapport à l'édition précédente

Avec le sens des bonnes choses dans la vie, Jussi Torhonen de Finland nous dit comment créer un CD-ROM RedHat Linux 5.2 amorçable fait-à-la-maison.

A partir du LDP, voir le CD-writing HOWTO.


10.2. Remerciements

A part ceux mentionnés ci-dessus, je remercie les personnes suivantes pour les informations de valeur, les retours d'informations, discussions et autres:


10.2.1. Remerciement pour la version actuelle


10.2.2. Remerciements pour les versions précédentes


11. Adaptation française

11.1. Traduction

La traduction française de ce document a été réalisée par Guillaume Lelarge .


11.2. Relecture

La relecture de ce document a été réalisée par Guillaume Hatt .