Tester les noyaux candidats à la mise à jour

Un article de Wiki de la communauté Mandriva.

Jump to: navigation, search
Cette page est en cours de traduction par .:Spip:. depuis la version originale : en:Development/Howto/Test Update Candidate Kernels

Si vous voulez aider à sa traduction, cliquez simplement sur l'onglet modifier. Vous pouvez contacter le traducteur en cliquant sur son nom et en modifiant sa page de discussion.

Consultez également les autres pages à traduire.
Cette article explique la procédure pour mettre à jour son noyau vers un noyau candidat (de test)


Sommaire

[modifier] Qu'est ce qu'un noyau candidat ?

Un noyau (ou kernel) candidat (connu sous le nom de -uc ou UC) est une version de test du prochain noyau stable de la version 200x.x de mandriva.

[modifier] Règles de base

  • Ne tester ce nouveau noyau que si vous accepter la possibilité d'une régression de votre système. Si votre environnement doit être très stable, ce kernel n'est pas pour vous.
  • Les paquets sont disponibles dans le répertoire main/testing

[modifier] Rapport de bug

Avant tout, si vous rencontrez un bogue, faites un rapport comme il est expliqué ici : Comment rapporter un bug pour le noyau

[modifier] Comment l'utiliser

La méthode la plus simple pour tester n'importe quel programme est simple : il faut juste l'utiliser.


Le noyau n'est pas une exception, il suffit d'installer un paquet RPM et redémarrer la machine. (Un des rares cas où l'on doit redémarrer sous Linux est la mise à jour du noyau.)


Si quelque chose ne fonctionne plus (ou mal), c'est-à-dire qu'un bogue a été introduit, vous pouvez le rencontrer de divers manières. Les plus courantes :

  • Le nouveau noyau ne démarre pas
  • Votre ordinateur se gèle
  • Un matériel qui fonctionnait auparavant (par exemple : clef USB, carte réseau/WIFI, carte son...) cesse de fonctionner.
  • Un programme que vous utilisiez auparavant sans problème avec le précédent kernel affiche maintenant une erreur de segmentation (segmentation fault) et se ferme.

[modifier] Vérifier les bogues résolus

Vous pouvez aider la communauté en vérifiant que les bogues qui sont considérés comme résolus le sont vraiment. Essayez de les reproduire sur une version du noyau pre- et post- résolution du bug.

En résumé, vous avez à :

  • Lire le changelog (c'est un fichier qui comporte les changements qui ont été fait avec la version précédente), et trouver des problèmes reproductibles. Bugzilla est un bon point de départ pour cela.
  • A partir des bogues que vous avez choisi, essayez de les reproduire avec un noyau défaillant (c'est à dire la version juste avant la version -uc).
  • Si vous réussissez, essayer de le refaire avec le nouveau noyau (c'est à dire la version actuelle -uc)
  • Si vous n'y parvenez pas, c'est que tout va bien !

Donnons nous un exemple : prenons le changelog -18uc2mdk 

$ rpm -q --changelog kernel-smp-2.6.12.18.uc2mdk-1-1mdk | less

* Thu Mar 02 2006 Luiz Capitulino <lcapitulino@mandriva.com> 2.6.12-18.uc2mdk
o Samir Bellabes <sbellabes@mandriva.com>
    - Support of the Acer Aspire 5xxx/3xxx series in the acerhk module
    (patch from Olivier Blin <oblin@mandriva.com>)

  o Luiz Capitulino <lcapitulino@mandriva.com>
    - Adds the corresponding CVE entry number for ZZ93 patch by renaming
      ZZ93_mlodable_protocols_refcnt_fix.patch to
      ZZ93_CVE-2005-3359_mlodable_protocols_refcnt_fix.patch
    - Rediffed RS02_rsbac-2.6.11-v1.2.4.patch, the current patch has a very
      wierd line which probably got in due to a mistake while making the
      diff (closes #20307)
    - USB storage: remove info sysfs file as it violates the sysfs 1 value per
      file rule (fixes #21245)
    - Fix OOPS in sysfs_hash_and_remove_file()
    - USB: pl2303 driver, makes pl2303HX chip work correctly
    - Security fixes:
      * ZZ95_CVE-2006-0554_xfs_ftruncate_could_expose_stale_data.patch
      * ZZ96_CVE-2006-0555_nfs_local_dos_fix.patch
      * ZZ97_CVE-2006-0741_x86_64_check_bad_elf_entry_addr.patch

Les lignes comportant des numéros comme #1234 sont des références de bugs sur le site Bugzilla ([[1]]). Prenons : 

- USB storage: remove info sysfs file as it violates the sysfs 1 value per
  file rule (fixes #21245)

Avec le noyau possédant le bug, vous aurez une erreur de segmentation et un OOPS dans les fichiers log du système. Par contre, avec le kernel patché, vous obtiendrez une jolie liste d'information dans le sysfs.

[modifier] Chasse aux régressions

Un autre test à effectuer est de vérifier si un changement spécifique a introduit une régression.

Vous devez vérifier le changelog comme décrit à la section précédente et vérifier aussi le patch correspondant.

Par exemple, le patch suivant a été ajouté dans le kernel 2.6.12-18uc2mdk :

ZZ95_CVE-2006-0554_xfs_ftruncate_could_expose_stale_data.patch

Vous pouvez voir que c'est un problème de XFS' ftruncate()

Un bonne manière de trouver une régression peut être de :

  • Créer une partition XFS et de la mettre à l'épreuve...
  • Comprendre comment la fonction modifiée est utilisée et essayer de la mettre à l'épreuve.
  • Essayez d'écrire un programme de test pour vérifier si le nouveau comportement de la fonction modifiée est celui attendu.

Il est bien évident que si vous n'avez pas un Oups ou un comportement étrange (comme des fichiers corrompus), vous aurez besoin de savoir ce que vous faites afin de déterminer ce qui a donné (ou pas) la régression.

[modifier] Outils de test

Il existe plusieurs outils pour tester le noyau Linux. Cette partie en donne quelques-un.

Autotest

Linux Test Project (LTP)

  • Description : Suite comprenant des tests divers du noyau Linux.
  • Lien du projet : http://ltp.sourceforge.net/
  • Paquet Mandriva : ltp

dbench

Cerberus

Récupérée de « http://wiki.mandriva.com/fr/Tester_les_noyaux_candidats_%C3%A0_la_mise_%C3%A0_jour »
Autres langues
Ad (via La Vignette)
Looking for a job?