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