[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]


Notes de publication pour Debian GNU/Linux 3.1 (« sarge »), Intel x86
Chapitre 5 - Problèmes à connaître pour sarge


5.1 Changements dans les paquets Python

Aucun des paquets python2.X inclus avec sarge n'inclut les modules standard « profile » et « pstats » car ils sont sous une licence qui n'est pas en conformité avec les principes du logiciel libre selon Debian (DFSG) (voir le bogue n° 293932 pour plus de détails). Ces deux modules peuvent être trouvés dans les paquets python-profiler et python2.X-profiles qui sont inclus dans la section non-free de l'archive Debian.


5.2 Mettre à jour vers un noyau 2.6

La série de noyaux 2.6 contient des changements majeurs par rapport à la série 2.4. Des modules ont changé de noms et beaucoup de pilotes ont été partiellement et parfois presque complètement réécrits. La mise à jour vers un noyau 2.6 à partir d'une version précédente n'est donc pas un processus à prendre à la légère. Cette section a pour objectif de vous prévenir de certains problèmes que vous pourriez rencontrer.

Vous êtes fortement encouragé à ne pas faire une mise à jour vers un noyau 2.6 en tant que partie d'une mise à niveau de woody vers sarge. Au lieu de cela, vous devriez tout d'abord vous assurer que votre système fonctionne correctement soit avec l'ancien noyau, soit avec un noyau 2.4 de sarge, puis faire la mise à jour vers un noyau 2.6 par la suite en tant que projet séparé.

Si vous compilez votre propre noyau à partir des sources, assurez-vous d'installer module-init-tools avant de redémarrer avec le noyau 2.6. Ce paquet remplace modutils pour les noyaux 2.6. Si vous installez l'un des paquets kernel-image de Debian, ce paquet sera installé automatiquement grâce aux dépendances.

Si vous utilisez LVM, vous devriez également installer lvm2 avant de redémarrer car le noyau 2.6 ne gère pas directement LVM1. Pour accéder aux volumes LVM1, la couche de compatibilité de lvm2 (le module dm-mod) est utilisé. Vous pouvez laisser lvm10 installé ; le script d'initialisation détectera quel noyau est utilisé et exécutera la version appropriée.

Si vous avez des entrées dans le fichier /etc/modules (la liste des modules à charger pendant le démarrage du sytème), soyez conscient que certains noms de module ont pu changer. Si cela se produit, vous devrez mettre ce fichier à jour avec les nouveaux noms des modules.

Pour certains contrôleurs de disque SATA, le périphérique assigné à un disque et ses partitions peuvent changer de /dev/hdX à /dev/sdX. Si cela se produit, vous devrez modifier votre /etc/fstab et la configuration de votre chargeur d'amorçage en conséquence. Si ces changements ne sont pas faits correctement, il est possible que votre système ne puisse plus s'amorcer correctement.

Une fois que vous avez installé votre noyau 2.6, mais avant de redémarrer, assurez-vous d'avoir une méthode de récupération. Assurez-vous tout d'abord que la configuration du chargeur d'amorçage possède des entrées pour le nouveau noyau et pour l'ancien et fonctionnel noyau 2.4. Vous devriez également vous assurer d'avoir une disquette ou un cédérom de récupération sous la main au cas où une mauvaise configuration de votre chargeur d'amorçage vous empêcherait d'amorcer l'ancien noyau.


5.2.1 Configuration du clavier

Le changement le plus profond dans les noyaux 2.6 est un changement fondamental dans la couche d'entrée. Ce changement rend tous les claviers visibles comme des claviers PC « normaux ». Cela veut dire que si vous avez un type différent de clavier sélectionné (par exemple, un clavier USB-MAC ou un clavier Sun), il est très probable que vous obteniez un clavier non fonctionnel après le redémarrage avec le nouveau noyau 2.6.

Si vous pouvez vous connecter par SSH à la machine depuis un autre système, vous pouvez résoudre ce problème en exécutant dpkg-reconfigure console-data, en choisissant l'option « Choisir un codage clavier dans la liste complète » (ou « Select keymap from full list » en anglais) et en sélectionnant un clavier « pc ».

Si votre clavier de console est concerné, vous devrez probablement également reconfigurer votre clavier pour le système de fenêtrage X (« X Window System »). Vous pouvez faire cela soit en exécutant dpkg-reconfigure xserver-xfree86, soit en éditant /etc/X11/XF86Config-4 directement. N'oubliez pas de lire la documentation indiquée dans Choses à faire avant le prochain redémarrage, Section 4.6.

Il est improbable que ce problème touche l'architecture Intel x86 car tous les claviers PS/2 et la plupart des claviers USB seront déjà configurés comme un clavier PC « normal ».


5.2.2 Configuration de la souris

À nouveau, à cause de changement dans la couche d'entrée du noyau, il se peut que vous deviez reconfigurer le système de fenêtrage X et gpm si votre souris ne fonctionne pas après avoir fait une mise à jour vers un noyau 2.6. La cause la plus probable est que le périphérique recevant les données de la souris a changé. Il se peut également que vous deviez charger différents modules.


5.2.3 Configuration du son

Pour la séries des noyaux 2.6, les pilotes de son ALSA sont recommandés par rapport aux pilotes de son OSS plus anciens. Les pilotes de son ALSA sont fournis en tant que modules par défaut. Pour que le son fonctionne, les modules ALSA appropriés pour votre matériel de son doivent être chargés. En général, cela se produit automatiquement si vous avez, en plus du paquet alsa-base, soit le paquet hotplug, soit le paquet discover d'installé. Le paquet alsa-base va marquer les modules OSS pour empêcher hotplug et discover de les charger. Si vous avez des modules OSS listés dans /etc/modules, vous devriez les supprimer.


5.2.4 Basculer vers un noyau 2.6 peut activer udev

Udev est une implémentation en espace utilisateur de devfs. Il est monté sur le répertoire /dev/ et va peupler ce répertoire avec des périphériques gérés par le noyau. Il va également ajouter et supprimer des périphériques quand les modules noyau sont chargés et déchargés respectivement, fonctionnant avec hotplug pour détecter de nouveaux périphériques. Udev ne fonctionne qu'avec les noyaux 2.6.

Comme udev est installé automatiquement en tant que dépendance de, par exemple gnome, il y a un risque qu'une mise à jour vers un noyau 2.6 résultera en l'activation d'udev.

Bien qu'udev ait été testé de manière extensive, vous pouvez rencontrer des problèmes mineurs avec certains périphériques qui devront être corrigés. Les problèmes les plus courants sont des changements de permission et/ou de propriétaire d'un périphérique. Dans certains cas, un périphérique peut ne pas être créé par défaut (par exemple, /dev/video et /dev/radio).

Udev fournit des mécanismes de configuration pour gérer ces problèmes. Veuillez consulter udev(8) et /etc/udev pour plus d'informations.


5.3 Erreur de chargement du système de fenêtrage X (« X Window System »)

Si, après avoir démarré votre machine, X échoue au chargement et que vous voyez une erreur « missing core pointer » dans /var/log/XFree86.0.log, le problème peut être que le pilote de souris n'est pas chargé assez rapidement par hotplug (bogue 255744). La solution est d'ajouter le module du pilote pour votre souris (par exemple, psmouse) dans /etc/modules.


5.4 Système de fenêtrage X (« X Window System ») sur systèmes Crusoe Transmeta

Le serveur X fourni dans sarge contient du code optimisé qui n'est pas exécuté correctement par un grand nombre de processeurs Crusoe(TM) de Transmeta(TM). Le résultat en est qu'à un certain moment (quand le code en cache « morphé » de x86 en instructions VLIW Crusoe dans le CPU est dans un état bogué), les applications clientes X qui se connectent au serveur échouent avec le message d'erreur suivant :

     X Error of failed request:  BadLength
        (poly request too large or internal Xlib length error)
     Major opcode of failed request:  18 (X_ChangeProperty)
     Serial number of failed request:  15
     Current serial number in output stream:  18

En termes pratiques, cela veut dire qu'après quelques heures d'utilisation, des applications se termineront soudainement en succession rapide ; si un gestionnaire d'affichage est en fonctionnement, celui-ci se terminera également de manière répétée et tentera de se relancer. L'état persistera jusqu'à ce que le code VLIW Transmeta bogué soit retiré du cache.

Comme le bogue est dans le logiciel propriétaire de « morphing » de code (CMS) de Transmeta et que le BIOS du portable vérifie la signature du vendeur dans le CMS lors de l'amorçage, cela ne peut être corrigé que par une coopération entre Transmeta et le vendeur du portable. Vous pouvez trouver plus d'informations sur ce problème à http://www.cs.auc.dk/~fleury/bug_cms/ et dans le rapport de bogue 216933.

Le contournement pour ce bogue est d'installer un serveur X compilé sans optimisation, comme le paquet xserver-xfree86-dbg.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ suivant ]


Notes de publication pour Debian GNU/Linux 3.1 (« sarge »), Intel x86

$Id: release-notes.fr.sgml,v 1.38 2005/10/12 00:07:14 fbothamy Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford (actuel), Frans Pop (actuel)
debian-doc@lists.debian.org