KERNEL-IMG.CONF(5)

NOM
kernel-img.conf - Fichier de configuration général pour les paquets d'images 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. Ce fichier est automatiquement créé par le script d'installation dans certaines circonstances.

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

postinst_hook
    OBSOLETE : Indiquez ici un script à exécuter pendant l'installation. 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), tandis que KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package en charge de la création du paquet. 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. Lorsqu'on utilise debconf pour 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 de script pour les utilisateurs de GRUB est donné dans le répertoire /usr/share/doc/kernel-package/. Ce script sera exécuté après les scripts du répertoire /etc/kernel/postinst.d.

postrm_hook
    OBSOLETE : Indiquez ici un script à exécuter dans le postrm, c'est-à-dire, après que l'image ait é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. La variable d'environnement KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package chargée de la création du paquet. 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. Lorsqu'on utilise debconf pour 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. Ce script est exécuté après les scripts du répertoire /etc/kernel/postrm.d.

preinst_hook
    OBSOLETE : 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. La variable d'environnement KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package chargée de la création du paquet. 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. Ce script est exécuté après les scripts du répertoire /etc/kernel/preinst.d.

prerm_hook
    OBSOLETE : 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. La variable d'environnement KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package chargée de la création du paquet. 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. Lorsqu'on utilise debconf pour 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. Ce script est exécuté après les scripts du répertoire /etc/kernel/prerm.d.

src_postinst_hook
    OBSOLETE : 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. La variable d'environnement KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package chargée de la création du paquet. Ce script doit être appelé avec deux arguments, le premier est le nomdu paquet à installer (ce peut être les sources noyau, ou les entêtes), et le second est la version du paquet à installer. Des erreurs dans le script déclencheront un échec de postinst. Ce script est exécuté après les scripts du répertoire /etc/kernel/src_postinst.d.

header_postinst_hook
    OBSOLETE : 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. La variable d'environnement KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package chargée de la création du paquet. Ce script sera appelé avec deux arguments, le premier étant le nom du paquet à installer, le second étant la version du paque à installert. Des erreurs dans le script déclencheront un échec de la post-installation. Ce script est exécuté après les scripts du répertoire /etc/kernel/src_postinst.d.

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.

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 du noyau 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 « build link » créé par les noyaux récents. Si le lien est un lien ballant, un nouveau lien symbolique sera créé et pointera sur /usr/src/, 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 »).

silent_modules
    Cette option est là pour ceux qui sont excédés par les avertissements concernant l'existence d'un répertoire de modules /lib/modules/$version. Ce répertoire peut appartenir à un ancien paquet image du noyay, 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.

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é. Cette variable n'a pas de valeur par défaut.

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

VOIR AUSSI
make(1), make-kpkg(1), kernel-pkg.conf(5), le manuel de 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.