Content-type: text/html Man page of KERNEL-IMG.CONF

KERNEL-IMG.CONF

Section: Manuel Debian GNU/Linux (5)
Updated: 21 mars 2000
Index Return to Main Contents
 

NOM

kernel-img.conf - fichier de configuration général pour les paquets d'image du noyau  

SYNOPSIS

/etc/kernel-img.conf  

DESCRIPTION

Le processus de post-installation de l'image du noyau recherche le fichier /etc/kernel-img.conf. Ce simple fichier permet d'utiliser des options locales pour gérer certains des aspects de l'installation, outrepassant ainsi les valeurs par défaut intégrées dans l'image elle-même.

Le format de ce fichier consiste simplement en paires VARIABLE = VALEUR. Des valeurs booléennes peuvent être écrites Yes, True, 1, ou No, False, 0, sans distinction entre les majuscules et les minuscules. Si ce fichier n'existe pas, et que le lien symbolique /vmlinuz n'existe pas non plus, il est automatiquement créé par le script d'installation. Le script demande s'il faut créer le lien symbolique et stocke la réponse dans /etc/kernel-img.conf.

Les variables actuellement modifiables par l'utilisateur sont les suivantes :

link_in_boot
Valeur « Yes », si vous voulez que le lien symbolique vers l'image du noyau, à savoir vmlinuz, soit dans /boot plutôt que dans / (valeur par défaut). L'ancien nom, prêtant à confusion, image_in_boot, est déconseillé, car c'est habituellement le lien symbolique qui est déplacé. La valeur par défaut est « No ».
do_symlinks
Par défaut, le script de post-installation de l'image créera ou mettra à jour les liens symboliques /vmlinuz et /vmlinuz.old. Ceci est vrai si le lien /vmlinuz existe déjà. Cependant, en l'absence de ce lien, le script recherchera ce fichier de configuration. Si ce fichier n'existe pas, le script demandera à l'utilisateur s'il faut créer le lien symbolique et enregistrera la réponse dans un nouveau fichier /etc/kernel-img.conf. Si le fichier de configuration existe déjà et si cette option vaut « No », aucun lien symbolique ne sera créé. Cela est fait pour les gens qui peuvent démarrer leur machine par d'autres méthodes et qui n'aiment pas que les liens symboliques encombrent le répertoire /. La valeur par défaut est fixée à « Yes ».
minimal_swap
Si le lien symbolique /vmlinuz ne pointe pas sur une image identique à celle qui va être installée, le script de post-installation renomme /vmlinuz en /vmlinuz.old et crée un lien symbolique de l'image du noyau vers /vmlinuz ; il s'agit d'empêcher que /vmlinuz et /vmlinuz.old ne pointent vers l'image en cours, ce qui pourrait être désastreux si cette image est défectueuse en quoi que ce soit. Cependant, si cette option est activée, rien n'est fait si /vmlinuz.old pointe sur l'image installée (les liens symboliques sont échangés). La valeur par défaut est « no ».
no_symlinks
Cette variable définit s'il faut utiliser des liens symboliques avec le fichier image. C'est l'opposée de reverse_symlinks et peut être utilisée avec link_in_boot (image_in_boot). Si cette variable est positionnée à Yes, l'image réelle est mise dans vmlinuz plutot que dans /boot/vmlinuz-X.X.XX. Si vous utilisez aussi link_in_boot, /boot/vmlinuz-X.X.XX est mis dans /boot/vmlinuz. L'ancienne image /vmlinuz est renommée d'office en vmlinuz.old.(Normalement, cela n'est fait que si la version de la nouvelle image est différente de l'ancienne.) Vous ne pouvez avoir que deux images, à moins de prendre des mesures pour conserver des copies des anciennes images. Cela peut servir aux gens qui ont /boot sur un système qui n'accepte pas les liens symboliques, et qui utilisent alors loadlin comme programme de démarrage. C'est un bidouillage. La valeur par défaut est « No ».
reverse_symlinks
Cette variable définit s'il faut utiliser des liens symboliques inversés avec le fichier image (c'est-à-dire que le fichier réel n'a pas de numéro de version et que c'est le lien qui possède ce numéro). C'est l'opposée de no_symlinks, et elle peut être utilisée avec link_in_boot (image_in_boot). Tout se passe comme avec no_symlinks, sauf que /boot/vmlinuz-X.X.XX est un lien symbolique vers la nouvelle image réelle, vmlinuz. Là aussi, vous ne pouvez avoir que deux images, à moins de prendre d'autres mesures. Les liens symboliques plus anciens sont laissés ballants. Cela peut servir à ceux qui ont /boot sur umsdos et qui ne peuvent voir les liens symboliques dans dos mais veulent connaître la version de l'image quand ils sont sous Linux. C'est un bidouillage. La valeur par défaut est « No ».
image_dest
Si vous voulez que le lien symbolique (ou l'image, si move_image est positionnée) soit placé ailleurs que dans /, indiquez le répertoire de votre choix. Veuillez remarquer que cette variable n'est pas une variable booléenne. Cela peut servir aux utilisateurs de loadlin qui pourront déclarer à la fois cette variable et move_image. La valeur par défaut est /. Elle peut être utilisée avec toutes les options ci-dessus, sauf link_in_boot (image_in_boot), ce qui n'aurait pas de sens. Si vous déclarez à la fois image_dest et link_in_boot (image_in_boot), link_in_boot (image_in_boot) prend le dessus.
postinst_hook
Indiquez ici un script à exécuter pendant l'installation, après que tous les liens symboliques ont été créés mais avant de lancer le programme d'amorçage. Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Avant d'appeler ce script, la variable d'environnement STEM doit être définie avec la même valeur que l'argument --stem (ou contenir la valeur par défaut, linux). Ce script doit être appelé avec deux arguments, le premier est la version de l'image du noyau, et le second est l'adresse de l'image du noyau elle-même. Des erreurs dans le script déclencheront un échec de la post-installation. Puisque l'on utilise debconf avant l'appel du script, ce dernier ne générera pas de message de diagnostic sur la sortie standard. En effet, au moment où la post-installation appelle db_stop, debconf ne rétablit pas la sortie standard, et tous les messages en sa direction disparaissent. Un exemple pour les utilisateurs de Grub est donné dans le répertoire /usr/share/doc/kernel-package/.
postrm_hook
Indiquez ici un script à exécuter dans le postrm, c'est-à-dire, après que l'image a été supprimée et toutes les actions de suppression effectuées). Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Ce script doit être appelé avec deux arguments, le premier est la version de l'image du noyau, et le second est l'adresse de l'image du noyau elle-même. Des erreurs dans le script déclencheront des messages d'avertissement mais seront ignorées. Puisqu'on utilise debconf avant l'appel du script, ce dernier ne générera pas de message de diagnostic sur la sortie standard. En effet, au moment où la post-installation appelle db_stop, debconf ne rétablit pas la sortie standard, tous les messages en sa direction disparaissent.
preinst_hook
Indiquez ici un script à exécuter avant que le paquet ne soit dépaqueté ; il peut servir à effectuer d'autres contrôles. Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Ce script doit être appelé avec deux arguments, le premier est la version de l'image du noyau, et le second est l'adresse de l'image du noyau elle-même.
prerm_hook
Indiquez ici un script à exécuter avant que les fichiers du paquet ne soient supprimés (donc tout fichier ajouté peut être supprimé). Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Ce script doit être appelé avec deux arguments, le premier est la version de l'image du noyau, et le second est l'adresse de l'image du noyau elle-même. Des erreurs dans le script déclencheront un échec de prerm. Puisqu'on utilise debconf avant l'appel du script, ce dernier ne générera pas de message de diagnostic sur la sortie standard. En effet, au moment où la post-installation appelle db_stop debconf ne rétablit pas la sortie standard, tous les messages en sa direction disparaissent.
ramdisk
Indiquez ici une liste d'exécutables (séparés par des espaces) afin de créer un RAM disk initial. Cela n'a d'effet que pour l'installation d'une image du noyau qui utilise un ramdisk initial. Les commandes indiquées doivent fonctionner d'une manière identique à mkinitrd. Lors de l'installation, ces exécutables sont appelés avec les options --supported-host-version et --supported-target-version, afin de s'assurer qu'ils sont compatibles avec le noyau en cours d'utilisation et avec le noyau en cours d'installation (respectivement). Les exécutables non compatibles sont retirés de la liste. Le premier outil valide est utilisé pour créer le RAM disk initial. L'installation échouera si aucun outil valide n'est trouvé. Cette liste contient par défaut un sous-ensemble de mkinitrd mkinitrd.yaird mkinitramfs.
src_postinst_hook
Contrairement aux autres variables de type « hook », cette variable indique un script qui sera exécuté pendant la phase de post-installation d'un paquet de documentation, d'en-têtes ou de sources. L'utilisation de cette possibilité pour les paquets d'en-têtes est maintenant déconseillé ; le script de post-installation des paquets d'en-têtes doit seulement lancer le script headers_postinst_hook. Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Ce script sera appelé avec deux arguments, le premier étant le nom du paquet qui est installé (p. ex. kernel-source-X.X.XX ou kernel-headers-X.X.XX), le second étant la version du paquet. Des erreurs dans le script déclencheront un échec de la post-installation.
headers_postinst_hook
Contrairement aux autres variables de type « hook », cette variable indique un script qui sera exécuté pendant la phase de post-installation d'un paquet d'en-têtes seulement. Le chemin peut être un chemin relatif si le script est situé dans un répertoire « sûr » (c'est-à-dire s'il est dans /bin, /sbin, /usr/bin, ou /usr/sbin), sinon il doit être exprimé en absolu. Ce script sera appelé avec deux arguments, le premier étant le nom du paquet qui est installé (p. ex. kernel-headers-X.X.XX), le second étant la version du paquet. Des erreurs dans le script déclencheront un échec de la post-installation.
move_image
Au lieu de créer un lien symbolique vers image_dest (ou l'inverse si reverse_symlinks est demandée, l'image est déplacée de boot vers image_dest. Si reverse_symlinks est demandée, boot contiendra un lien symbolique vers l'image réelle. Cette option peut servir à ceux qui utilisent loadlin, et qui pourraient vouloir déplacer l'image sur une autre partition dos. Cette variable n'a pas de valeur par défaut.
clobber_modules
Quand cette variable est déclarée, le script de pré-installation cherchera à déplacer silencieusement /lib/modules/version, si cette version est la même que celle de l'image à installer. Utilisez-la à vos risques et périls. Cette variable n'a pas de valeur par défaut.
warn_reboot
Cette variable peut être utilisée pour désactiver l'émission des alertes (« warnings ») lors de l'installation d'une image du noyau qui est de la même version que celle actuellement lancée. Si la liste des modules a changé, les dépendances entre modules ont peut-être été modifiées, et les modules du nouveau noyau pourraient ne pas fonctionner correctement avec le noyau actuel, notamment si la liste des ABI du noyau a changé entre les deux. C'est une bonne idée de redémarrer la machine, et un message vous le précisera. Si vous savez ce que vous faites, vous pouvez définir cette variable à « no ». Cette variable est active par défaut.
do_bootloader
Si la valeur de cette variable est « NO », elle empêche le script post-installation de lancer le programme de démarrage. La valeur par défaut est « Yes ».
relative_links
Si la valeur de cette variable est « Yes », le script post-installation de l'image s'assurera par tous les moyens que les liens symboliques sont relatifs. Normalement, ils le sont, et il est facile de savoir si des liens relatifs fonctionnent. La valeur par défaut est « NO ».
do_initrd
Si la valeur de cette variable est « YES », le script de post-installation de kernel-image n'affiche pas d'avertissement quand on installe un noyau avec initrd. Cela suppose que le programme de démarrage doit être correctement configuré et qu'il sache amorcer l'image initrd. Valeur par défaut : « NO ». Il faut préférer à cette variable la variable warn_initrd, mais remarquez que son sens est inversé.
warn_initrd
Si la valeur de cette variable est « NO », le script de post-installation de kernel-image n'affiche pas d'avertissement quand on installe un noyau avec initrd. Il est donc nécessaire que le programme de démarrage soit correctement configuré et qu'il sache amorcer l'image initrd. Cette variable est maintenant préférée à do_initrd, puisqu'il s'agit d'éviter les avertissements. La valeur par défaut est « Yes ».
use_hard_links
Cette variable existe pour ceux qui ne peuvent pas gérer les liens symboliques (certains programmes de démarrage n'acceptent pas les liens symboliques, par exemple). Si la valeur de cette variable est « Yes », la post-installation de l'image utilisera des liens physiques pour /vmlinuz et /vmlinuz.old, qui sont gérés automatiquement. Cette variable est probablement compatible avec les variables move_image et reverse_symlinks. Avertissement : C'est à l'utilisateur de s'assurer que le répertoire image_dest et l'emplacement de l'image (nominativement /boot) sont sur le même système de fichiers, car on ne peut créer des liens physiques d'un système de fichiers à un autre. Vous avez été prévenus.
relink_build_link
Cette option manipule le « build link » créé par les noyaux récents. Si le lien est un lien ballant et si les en-têtes correspondants semblent avoir été installés sur le système, un nouveau lien symbolique sera créé et pointera sur eux. La valeur par défaut est de relier le lien de construction (« YES »).
force_build_link
Cette option manipule le lien de construction créé par les noyaux récents. Si le lien est un lien ballant, un nouveau lien symbolique sera créé et pointera sur /usr/src/kernel-headers-X.Y.ZZ, que ces en-têtes aient été installées ou non. Il n'y a pas de valeur par défaut, les liens symboliques potentiellement ballants ne sont pas créés par défaut.
relink_src_link
Cette option manipule le « source link » créé par les noyaux récents. Si le lien est un lien ballant, il sera effacé au moment de l'installation. La valeur par défaut est de relier (effacer) le lien des sources (« YES »).
mkimage
La valeur sera une commande pour créer une image initrd, un répertoire étant donné. Elle est passée à l'option -m du programme mkinitrd. Par exemple,
  mkimage="genromfs -d %s -f %s"
 ou
  mkimage="mkcramfs %s %s"
silent_modules
Cette option est là pour ceux qui sont excédés par les avertissements concernant l'existence d'un répertoire /lib/modules/$version. Ce répertoire peut appartenir à un ancien paquet kernel-image-$version, qui a peut-être même disparu, auquel cas les modules restant dans ce répertoire peuvent poser problème ; ou bien, ce répertoire a le droit d'exister parce qu'on installe un paquet indépendant des modules d'une version du noyau qui a déjà été dépaquetée. Dans ce dernier cas, l'existence de ce répertoire est bénigne. Si vous utilisez cette variable, vous n'aurez plus la possibilité d'interrompre l'installation si un répertoire /lib/modules/$version est détecté. Cette variable n'a pas de valeur par défaut.
silent_loader
Si la valeur de cette variable est déclarée, la question posée dans la phase d'installation et avant le lancement du programme de démarrage ne sera pas affichée. Cette option n'influe pas sur l'exécution du programme de démarrage (consultez do_bootloader pour savoir comment contrôler son exécution. L'absence du fichier de configuration rendra le processus d'installation loquace et interactif).
ignore_depmod_err
Si elle est déclarée, cette variable empêchera une interrogation de l'utilisateur après un problème avec depmod dans le script de post-installation. Cela facilite les installations automatiques, mais cela peut cacher un problème avec l'image du noyau. Un diagnostic est affiché.
 

FICHIERS

Le fichier décrit ici est /etc/kernel-img.conf.  

VOIR AUSSI

make-kpkg(1), kernel-pkg.conf(5), make(1), le manuel GNU Make  

BOGUES

Il n'y a pas d'erreur. Toute ressemblance avec un bogue est du délire. Vraiment.  

AUTEUR

Cette page a été écrite par Manoj Srivastava, <srivasta@debian.org>, pour le système Debian GNU/Linux.  

TRADUCTION

Cette page de manuel a été traduite et est maintenue par Sylvain Cherrier <sylvain.cherrier@free.fr> et les membres de la liste <debian-l10n-french@lists.debian.org> entre 2004 et 2007.


 

Index

NOM
SYNOPSIS
DESCRIPTION
FICHIERS
VOIR AUSSI
BOGUES
AUTEUR
TRADUCTION

This document was created by man2html, using the manual pages.
Time: 12:37:45 GMT, March 12, 2007