Mandriva Linux 2009 Errata
De Wiki de la communauté Mandriva.
- Cette page est une traduction depuis l'anglais
- Les problèmes résolus ne sont pas forcément traduits car ils ne constituent pas une priorité (si le problème est résolu, installer le paquetage mis à jour indiqué dans l'article est suffisant).
- Les traducteurs se concentrent sur les autres problèmes (ceux non-résolus) qui indiquent souvent des possibilité de contourner le problème en attendant une mise à jour.
- Cette page est mise à jour très régulièrement (et suit la version anglaise de très près). Suivre cette page est un bon moyen d'être tenu au courant des mises à jour de Mandriva Linux (nécessite un compte sur ce site, créé en 2 étapes).
Cette page contient les Errata pour Mandriva Linux 2009. Autrement dit, cette page contient des informations sur les problèmes connus avec Mandriva Linux 2009, et, quand cela est disponible, les manières de les résoudre, ou de les contourner, ou de s'en arranger. Vous devriez aussi consulter les Notes de version (informations spécifiques à la version Mandriva Linux 2009) qui contiennent des informations complémentaires.
Vous pouvez aussi consulter le forum dédié aux mises à jour vers Mandriva Linux 2009 pour voir les retours d'expérience, puis obtenir du support de la communauté.
Errata pour les versions de Mandriva précédentes
Les pages d'errata sont aussi disponibles pour les version plus anciennes :
- Version 2008 spring (ou 2008.1)
- Version 2008 (ou 2008.0)
- Version 2007 Spring (ou 2007.1)
- Version 2007 (ou 2007.0)
- Version 2006 (en anglais)
Tester les candidats à la mise à jour
Quand un problème est identifié dans la Mandriva Linux 2009, le mainteneur du paquetage concerné peut réaliser un nouveau paquetage qui pourrait, selon lui, éliminer le bug. Il le place dans un certain dépôt appelé /main/testing qui est dédié au test des solutions potentielles pour les problèmes connus. Ce paquetage peut ensuite être testé par les utilisateurs affectés par ce problème et par l'équipe d'assurance qualité Mandriva. Si le test détermine que le paquetage résout effectivement le problème et n'en cause aucun nouveau, le paquetage sortira en tant que mise à jour officielle qui sera fournie à tous les utilisateurs de Mandriva Linux 2009 via MandrivaUpdate.
Si vous êtes affecté par un problème pour lequel un paquetage candidat est disponible, vous pouvez configurer votre système afin que l'outil de gestion des paquetage Mandriva utilisera le dépôt /main/testing pour installer les paquetages. Pour plus d'informations sur comment faire cela, se reporter à Installer_et_supprimer_des_logiciels#Utilisation_avanc.C3.A9e:_r.C3.A9troportages_.28backports.29_et_mises_.C3.A0_jour_candidates.
Il existe aussi un dépôt /contrib/testing qui fonctionne de la même manière pour les paquetages dans la section /contrib (noter que nous ne garantissons pas que les problèmes connus dans /contrib seront résolus, les mainteneurs de chaque paquetage choisissent s'il est nécessaire de faire un paquetage ou non). Configurer ce dépôt est traité dans la même page ci-dessus.
Installer des mises à jour
Les mises à jour pour les paquetages situés dans les sections /main, /non-free et /contrib de Mandriva Linux peuvent être installées en utilisant Mandriva Update. Vous pouvez lancer Mandriva Update à partir du Centre de Contrôle Mandriva en allant dans l'onglet "Gestionnaire de logiciels" et en cliquant sur le lien nommé "Mettre à jour votre système". À moins que vous ne l'ayez désactivé, vous serez aussi notifié des mises à jour par le système de notification Mandriva Online, qui affiche une icône dans la boîte à miniature et qui vous indique s'il existe des mises à jour.
Plus d'informations sur la mise à jour du système...
Problèmes résolus
Cette section contient les problèmes qui sont résolus dans une mise à jour officielle de Mandriva Linux.
Le pilote propriétaire NVIDIA ne fonctionne pas avec le noyau kernel-server
Le pilote propriétaire NVIDIA fourni avec Mandriva Linux 2009 ne fonctionne pas avec le noyau kernel-server. Ce problème survenait sur les machines récentes et puissantes équipées de 4GB ou plus de mémoire RAM; en effet, kernel-server étant installé sur de tels systèmes afin de s'assurer que la totalité de la mémoire RAM soit accessible. Une mise-à-jour du paquetage nvidia-current, nvidia-current-177.70-2.3mdv2009.0, disponible depuis le 16 octobre 2008 sur les miroirs 'official update', résout le problème. Utilisez MandrivaUpdate afin d'obtenir et d'installer cette mise-à-jour.
L'absence d'information sur une dépendance augmente légèrement le temps de démarrage
Voir aussi bulletin de sécurité MDVSA-2008:224. Un petit bogue dans le noyau fourni avec Mandriva Linux 2009 augmentait légèrement le temps de démarrage. Vous pouviez éviter cela en exécutant la commande depmod, sous root. Cela réduisait le temps de démarrage d'environ deux ou trois secondes. Un lot de paquetages mis à jour du noyau, kernel-2.6.27.4-1mnb-1-1mnb2, a été publié sur les canaux officiels de mise à jour le 4 novembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour.
L'installation de VMware sur Mandriva échoue en raison d'une version erronée du GCC version utilisé pour compiler le noyau
Voir aussi bulletin de sécurité MDVSA-2008:224. Dans la version i586 de Mandriva Linux 2009, le noyau fut construit avec une version de GCC antérieure à celle incluse dans l'édition finale, ainsi VMWare (et peut-être d'autres applications tierces qui utilisent les modules du noyau) refusait de construire son nodule noyau quand vous tentiez de l'installer sur Mandriva Linux 2009. Veuillez noter que cela ne s'applique qu'à l'installation d'une application VMware sur Mandriva Linux 2009, pas à l'installation de Mandriva Linux 2009 en tant qu'hôte VMware. Un lot de paquetages mis à jour du noyau, kernel-2.6.27.4-1mnb-1-1mnb2, a été publié sur les canaux officiels de mise à jour le 4 novembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour.
Les systèmes Eee ne s'arrêtent pas correctement
Voir aussi
bug n°44752 et bulletin de sécurité MDVSA-2008:224. Plusieurs utilisateurs ont rapporté que les systèmes Eee y compris au moins le 701 ne s'arrêtent pas correctement. Le processus d'arrêt s'accomplit jusqu'à la fin et l'écran est blanc, mais le voyant de puissance n'est éteint et le système n'est pas correctement arrêté. Pour contourner ce problème, ajoutez cette ligne au début du fichier /etc/init.d/halt :
rmmod snd-hda-intel
Un lot de paquetages mis à jour du noyau, kernel-2.6.27.4-1mnb-1-1mnb2, a été publié sur les canaux officiels de mise à jour le 4 novembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour.
Pas de réponse réseau (problème causé par l'entête du paquet TCP)
Voir aussi
bug n°43372 et bulletin de sécurité MDVSA-2008:224. Avant la version 2.6.27, en raison d'un bogue, le noyau Linux n'incluait pas le champ timestamp dans les paquets TCP. Maintenant, ce bogue a été résolu, et le noyau 2.6.27 (et suivants) comprend ce champ. Cependant, en ajoutant ce champ, l'ordre des champs à l'intérieur des en-têtes TCP fut modifié. Il apparaît que certains matériels réseau (principalement les routeurs) imposent que ces en-têtes soient dans un ordre particulier, et ne fonctionnent pas s'ils sont dans un ordre différent. Un lot de paquetages mis à jour du noyau, kernel-2.6.27.4-1mnb-1-1mnb2, a été publié sur les canaux officiels de mise à jour le 4 novembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour.
Si, dans un premier temps, ce problème semble vous empêcher d'installer les mises à jour, vous pouvez exécuter cette commande sous root : sysctl -w net.ipv4.tcp_timestamps=0. Cela devrait résoudre temporairement le problème, vous permettant d'accéder à internet et d'installer les mises à jour. Quand vous redémarrerez sur le noyau mis à jour, le problème devrait être définitivement résolu.
Emission continuelle d'un bruit fort par le périphérique son
Voir aussi
bug n°44703 et bulletin de sécurité MDVA-2008:168. Plusieurs utilisateurs ont rapporté qu'aussitôt le pilote son est chargé sur Mandriva Linux 2009, un son fort et déplaisant est continuellement émis dans les hauts parleurs ou le casque. Cela peut être résolu en exécutant un mixer, tel que kmix ou alsamixer, et en désactivant / rendant muet le(s) canal(aux) Bouclage analogique. Un paquetage mis à jour de scriptes son, sound-scripts-0.56-1.1mdv2009.0 a été publié sur les canaux officiels de mise à jour le 7 novembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour. Comme indiqué dans l'avis de sécurité, puisque le problème porte sur les données de configuration, le changement ne sera pas appliqué automatiquement. Vous pouvez soit appliquer manuellement la modification comme indiqué ci-dessus, ou exécuter la commande reset_sound avec les privilèges root après l'installation de la mise à jour.
Evolution ne peut pas envoyer de messages si on utilise un serveur Exchange
Voir aussi
bug n°44908 et bulletin de sécurité 2008:186 et bulletin de sécurité 2008:186-1. Un bogue dans le paquetage evolution fourni avec Mandriva Linux 2009 empêchait l'envoi des courriers sortants quand le serveur des courriers sortants est un serveur Exchange (via le plugin evolution-exchange). Evolution donnait l'impression d'envoyer le courrier, mais l'opération ne se terminait jamais. Un lot de paquetages mis à jour d'Evolution, evolution-2.24.2-1.1mdv2009.0, a été publié sur les canaux officiels de mise à jour le 1 décembre 2008, lequel résout ce problème. Utilisez MandrivaUpdate pour obtenir et installer cette mise à jour. Notez que la mise à jour initiale fut mal construite, et pourrait causer le crash d'Evolution au démarrage. Un lot de paquetages mis à jour
evolution-2.24.2-1.2mdv2009.0 fut publiè le jour suivant pour résoudre ce problème.
Problèmes d'installation
Problèmes après une mise à jour à chaud depuis la 2008 Spring vers la 2009
Une nouvelle fonctionnalité dans la 2009 est sa possibilité d'effectuer une mise à jour graphique à chaud depuis la 2008 Spring, via le système de notification des mises à jour Mandriva Online. Les utilisateurs de la 2008 Spring ont commencé à être notifiés de cette nouvelle version et ont eu l'opportunité de mettre leur système à jour depuis le 10 Octobre 2008. Les utilisateurs qui ont tenté de mettre à jour à cette date ont pu découvrir que la mise à jour ne fonctionnait pas correctement : après le redémarrage du système, il était impossible de se connecter graphiquement ou certaines applications semblaient ne pas fonctionner ou étaient manquantes. Cela est dû principalement au fait que le processus n'a pas été rendu assez robuste pour résister aux possibles problèmes qui pouvaient se produire pendant la mise à jour. Par exemple, les miroirs surchargés ont provoqué l'échec du téléchargement de plusieurs paquetages (et donc la mise à jour) ou l'absence de suffisamment d'espace disque sur le système empêchait la finalisation du processus de mise à jour
Si vous êtes affecté par une problématique de mise à jour la procédure suivante pourrait la résoudre : après le redémarrage de votre machine, presser ctrl-alt-F1 pour obtenir l'écran de connexion en mode texte. Puis, une fois connecté en tant que root, lancer cette commande:
urpmi --auto-update --auto -v
Suivez ensuite le processus : les paquetages qui n'ont pas été mis à jour avec succès devraient l'être. Si le processus indique que certains paquetages n'ont toujours pas pu être mis à jour à cause d'un problème de miroir, relancer la commande jusqu'à ce que toutes les mises à jour soit correctement installées. Quand le processus est terminé, lancer la commande reboot pour redémarrer le système. La mise à jour devrait maintenant être achevée.
Problèmes de noyau
Gel aléatoire du système graphique
Voir aussi
bug n°42833. Des utilisateurs de Mandriva Linux 2009 ont rencontré un bug où le système graphique se fige aléatoirement. Quand cela arrive, il est possible d'utiliser les touches ctrl-alt-F1 pour accéder à une console en mode texte. Ce problème est causé par un bogue dans les modules DRM du noyau provoquant l'entrée en boucle infinie du serveur graphique X.org. Pour établir le diagnostic du problème, examiner le fichier journal de X.org /var/log/Xorg.0.log, dans la console texte après le gel du bureau. La présence récurrente des lignes suivantes est la confirmation de ce bug :
[mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Pour contourner ce problème, dans le menu de boot de Mandriva Linux 2009, choisir l'option linux-nonfb à la place de l'option par défaut. Pour pouvez la définir comme nouvelle option par défaut permanente dans l'outil de configuration du démarrage de Mandriva, accessible depuis le Centre de Contrôle de Mandriva, onglet Démarrage, Configurer le démarrage du système. Agir ainsi, invalide le framebuffer vidéo, ce qui signifie que vous ne verrez plus les écrans du boot graphique ni de l'arrêt du système.
Le démarrage s'arrête indéfiniment en divers endroits jusqu'à ce qu'une touche soit appuyée
Voir aussi
bug n°44342. Sur plusieurs systèmes, y compris le Sony Vaio PCG-GRT-815E, le processus de boot s'arrête indéfiniment en divers endroits jusqu'à ce qu'une touche soit appuyée. Quand une touche est appuyée, il reprend. Si vous appuyez sur une touche à chaque fois qu'il s'arrête, finalement le boot se termine sans problèmes.
Ce problème est toujours sous investigation, et une solution pourra être fournie dans une future mise à jour du noyau. Il est possible de contourner le problème en ajoutant les lignes suivantes au fichier /etc/modprobe.d/blacklist-mdv :
blacklist thermal blacklist processor
ou en utilisant le paramètre suivant pour le noyau :
clocksource=jiffies
Les paramètres du noyau peuvent être ajoutés en utilisant l'outil de configuration du démarrage de Mandriva, disponible dans le Centre de Contrôle Mandriva.
Le réveil de l'hibernation échoue et affiche un écran blanc
Plusieurs utilisateurs ont rapporté que quand ils hibernent leur système (suspend to disk) et tentent par la suite de le réveiller, il affiche l'écran de démarrage Mandriva pendant un court instant puis se fige sur un écran blanc.
Il existe beaucoup de raisons pour lesquelles un portable ne se réveille pas correctement même si la plupart des modules du noyau (depuis 2.6) ont été revus pour améliorer le réveil. Réveiller la vidéo est un autre défi et beaucoup de bizarreries sont présentées pour divers portables et, alors que Mandriva utilise hal, se référer au site http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html pour en savoir plus. Veuillez y déposer votre rapport si votre portable n'est pas mentionné parmi les bizarreries (et que vous avez trouvé la solution).
Voici les bogues et contournements
bug n°45090, le bogue
bug n°44807 rapportait le problème du tout premier splashscreen coloré de Mandriva qui figeait le processus de réveil.
Splashy impliqué
Le moyen le plus facile de contourner le problème est de cliquer sur Echap immédiatement après le splashscreen coloré. Si le processus de réveil fonctionne après ce clic rapide cela signifie, d'après http://fixunix.com/mandriva/544016-cant-kill-splash-screen.html, que la cause du blocage est splashy. La méthode normale serait de remplacer splash=silent par défaut dans votre chargeur de boot (lilo ou grub) par splash=verbose, mais en raison d'un bogue quelque part aucune mention du mot splash dans les options de boot ne démarre splashy. Aussi l'astuce actuelle consiste à supprimer tout splash. J'ai supprimé tout mot splash des lignes du fichier lilo.conf,
- de :
append="resume=UUID=xxxxx splash=verbose" vga=788
- à :
append="resume=UUID=xxxxx" vga=788
Comme vous pouvez le voir, nous avons conservé le framebuffer vga=788 car ce n'était pas un gel du framebuffer. Et pendant le processus de réveil vous obtiendrez l'autre splashscreen gris de Mandriva qui cache les commentaires du réveil.
Framebuffer impliqué
Pour certains utilisateurs, ce problème peut être contourné en désactivant le système de démarrage graphique basé sur le framebuffer. Si votre menu de démarrage possède une entrée étiquetée 'linux-nonfb', vous pouvez démarrer sur cette entrée pour y parvenir.
Sinon, vous pouvez le faire depuis le Centre de Contrôle Mandriva. Allez dans l'onglet Démarrage et cliquez sur Configurer le démarrage du système. Sur le premier écran, simplement cliquer sur Suivant. Sur le second écran, assurez vous que l'entrée par défaut est sélectionnée, et cliquez sur Modifier. Regardez dans la ligne Options passées au noyau. S'il existe déjà une entrée de la forme vga=788 - le nombre peut être différent - remplacez le par vga=normal. S'il n'y a pas d'entrée vga=, ajoutez simplement vga=normal à la fin de la ligne. Cliquez ensuite sur OK puis sur Terminer, et vous avez fini. Redémarrer le système, et vérifier alors que l'hibernation fonctionne. Vous remarquerez que lors du démarrage, vous voyez maintenant un écran de texte à la place de l'écran graphique de démarrage de Mandriva. C'est un inévitable conséquence de la désactivation du framebuffer.
Problèmes matériels
Certaines puces pour liaisons sans fil n'obtiennent pas d'IP
Voir aussi le
bug n°45062 le client DHCP par défaut utilisé par Mandriva - dhclient - ne fonctionne pas avec certaines puces de liaison sans fil. Le problème vient du fait que dhclient n'est pas capable d'accepter un DHCPNAK quand il tente une requête sur sa dernière adresse IP utilisée depuis un serveur différent. Le remplacer par le paquetage dhcpcd devrait corriger immédiatement le problème.
Installez le paquetage dhcpcd depuis le DVD Free/Powerpack ou depuis le dépôt /Main. Ensuite, allez dans le Centre de Contrôle de Mandriva (icône Configurer votre ordinateur) et choisissez Configurer une nouvelle connexion Internet (...) dans la section Réseau & Internet. Ici vous pouvez normalement paramétrer votre carte sans fil, jusqu'à atteindre la section Sans fil / Paramètres IP. Utilisez le bouton Avancé pour obtenir une boite de dialogue supplémentaire où vous pourrez choisir dhcpcd comme Client DHCP.
Le réseau sans fil sur les modèles Eee s'arrête de fonctionner s'il est désactivé puis réactivé par les touches Fn+F2
Voir aussi
bug n°43332. En raison d'un bogue sur le pilote utilisé dans le noyau, la puce du réseau sans fil de la plupart des Eee s'arrête de fonctionner après une désactivation puis une réactivation avec les touches Fn+F2. L'arrêt puis la remise en marche se font normalement, mais il devient impossible de se connecter sur un point d'accès et de transférer des données.
Vous pouvez remédier à ce problème en ajoutant la ligne suivante dans le fichier /etc/modprobe.conf:
options pciehp pciehp_force=1
Et redémarrer. Après cela, désactiver et réactiver et l'adaptateur sans fil devrait fonctionner correctement.
Un candidat correctif a été placé parmi les paquetages du dépôt /main/testing : kernel-2.6.27.7-0.uc2mnb2. Si vous désirez aider au test de la solution candidate, veuillez lire le chapitre "Tester les candidats à la mise à jour" ci-dessus, pour avoir les instructions concernant la configuration de votre système pour installer les paquetages du dépôt /main/testing . Suivez ces instructions, puis installez les paquetages de la mise à jour du noyau. Veuillez bien vous assurer que vous installez le type approprié de noyau (desktop, desktop586, ou serveur) correspondant à votre matériel - la commande uname -r vous dira quel est le type que vous utilisez actuellement - et installez aussi le paquetage -devel correspondant au noyau que vous installez; si vous ne le faites pas, les modules compilés en dehors (comme les pilotes propriétaires de cartes graphiques NVIDIA et ATI) ont toutes les chances de ne plus fonctionner.
Le contrôleur de lecteur Marvell 88SE6121 ne fonctionne pas
Voir aussi
bug n°43975. Des utilisateurs ont rapporté que Mandriva Linux 2009 ne fonctionne pas avec la série de contrôleurs de lecteur Marvell 88SE61 présent sur de nombreuses cartes mères, y compris l'Asus P5E3 eet la MSI P965Neo-F V2. Si votre lecteur optique, ou disque dur sur lequel vous désirez installer Mandriva Linux 2009 est connecté à ce contrôleur, cela vous empêchera d'installer Mandriva.
Nous sommes actuellement en train de travailler sur l'identification de la cause du problème et en train de voir si une mise à jour et un contournement du problème peuvent être fournis.
Pauses fréquentes lors de l'exécution d'applications 3D accélérées avec du matériel NVIDIA
Voir aussi Ce fil de discussion sur NVNews. Un bogue dans le pilote propriétaire de NVidia peut causer de fréquents et courts arrêts - chaque demi seconde, ou seconde - lors de l'exécution d'applications 3D, si dans le noyau les attributs PAT (X86_PAT) sont supportés et activés. Cette option est activée par défaut dans Mandriva, aussi ce bogue apparaîtra sur les systèmes dont le processeur supporte les les attributs PAT. Si vous rencontrez ce problème, il peut être résolu en ajoutant nopat dans les paramètres de démarrage du noyau. Vous pouvez utiliser l'outil de configuration du démarrage de Mandriva, drakboot, pour ajouter les paramètres de démarrage du noyau. Il se trouve dans le Centre de Contrôle de Mandriva, onglet Démarrage, icône Configurer le démarrage du système.
Pas de son sur divers périphériques de son basés sur le snd-hda-intel
Voir aussi
bug n°44855 et
bug n°44727. En raison de changements dans le pilote amont, plusieurs périphériques de son basés sur le codec Intel HDA qui fonctionnaient dans les versions précédentes de Mandriva Linux, ne fonctionnent pas avec Mandriva Linux 2009. Ce problème est rendu plus complexe par le fait qu'il existe des dizaines d'implémentations matérielles légèrement différentes du codec Intel HDA, toutes supportées par le même pilote; certaines sont concernées par ce problème, d'autres pas. Certains cas ont été résolus par les mises à jour officielles du noyau publiées jusqu'à présent pour Mandriva Linux 2009:
kernel-2.6.27.4-1mnb-1-1mnb2, kernel-2.6.27.4-2mnb-1-1mnb2, et kernel-2.6.27.5-2mnb-1-1mnb2. Si vous ne l'avez pas encore fait, exécutez Mandriva Update pour mettre à jour votre système avec les derniers paquetages, et redémarrez. Cela peut résoudre le problème.
Il y a aussi un noyau candidat encore plus récent dans le dépôt de paquetages /main/testing : kernel-2.6.27.7-0.uc1mnb2. Si la dernière mise à jour officielle du noyau ne résout pas le problème, vous pouvez essayer la dernière mise à jour candidate.Si vous désirez aider au test de la solution candidate, veuillez lire le chapitre "Tester les candidats à la mise à jour" ci-dessus, pour avoir les instructions concernant la configuration de votre système pour installer les paquetages du dépôt /main/testing. Suivez ces instructions, puis installez les paquetages de la mise à jour du noyau.
Veuillez bien vous assurer que vous installez le type approprié de noyau (desktop, desktop586, ou serveur) correspondant à votre matériel - la commande uname -r vous dira quel est le type que vous utilisez actuellement - et installez aussi le paquetage -devel correspondant au noyau que vous installez; si vous ne le faites pas, les modules compilés en dehors (comme les pilotes propriétaires de cartes graphiques NVIDIA et ATI) ont toutes les chances de ne plus fonctionner.
Réponse internet lente ou absente (particulièrement la navigation sur le web)
Problèmes IPv6
Voir aussi
bug n°27070. Il existe un problème connu avec toutes les distributions Linux qui implique le réseau IPv6 (le nouveau standard pour les adresses qui utilise un format hexadécimal plus long pour fournir un plus grand nombre d'adresses disponibles. L'ancien standard est IPv4, qui fournit des adresses au format bien connu de quatre groupes de trois nombres décimaux, par ex : 216.105.167.65). Certains systèmes et réseaux ne se comportent pas bien si votre système est basé sur l'IPv6. Si vous rencontrez des lenteurs sur internet - surtout en navigant sur le Web - sans pouvoir en trouver la cause, vous devez essayer de désactiver l'IPv6. Pour faire cela, éditez le fichier /etc/modprobe.conf, ajoutez la ligne suivante puis redémarrez :
install ipv6 /bin/true
TCP window scaling
Voir aussi
bug n°27073. Si cela ne résoud pas votre problème, il existe une autre possibilité. La plupart des distributions Linux, y compris Mandriva, utilisent une caractéristique du noyau appelée TCP window scaling. Cela permet d'accroître la vitesse de transfert sur les connexions à très grande bande passante. Cependant, une modification fut apportée dans les valeurs par défaut de TCP window scaling dans le noyau 2.6.17, qui semble être la cause des très faibles performances du réseau chez certains utilisateurs et avec certains sites internet. Pour savoir si TCP window scaling vous pose problème, vous pouvez le désactiver avec cette commande :
sysctl -w net.ipv4.tcp_window_scaling=0
Si cela résout votre problème, vous pouvez rendre la modification définitive en ajoutant cette ligne au fichier /etc/sysctl.conf :
net.ipv4.tcp_window_scaling=0
Cela désactivera TCP window scaling à chaque démarrage. Si vous utilisez une connexion réseau à très grande bande passante - par exemple, vous transférez régulièrement de gros fichiers sur un réseau 100Mbit ou 1Gbit - vous pouvez remarquer que désactiver le TCP window scaling a pour conséquence le ralentissement de cette connexion. Dans ce cas vous pouvez essayer de restaurer les paramètres par défaut du pré-2.6.17 plutôt que de désactiver complètement le TCP window scaling. Pour faire cela, ajoutez la ligne suivante au fichier /etc/sysctl.conf, à la place (et non pas en plus) de la suggestion précédente :
net.ipv4.tcp_rmem=4096 87380 174760
Cela modifiera les paramètres par défaut du window scaling à chaque démarrage.
Réponse lente du réseau avec les adaptateurs internet sans fil ( utilisant le pilote rt2500pci)
Voir aussi
bug n°42180. Il a été rapporté que les adaptateurs sans fil qui utilisent le pilote rt2500pci se connecte à une très basse vitesse par défaut. Pour remédier à cela, reconfigurer la carte en utilisant l'outil de configuration du réseau de Mandriva (disponible dans le Centre de Contrôle Mandriva). Pendant la configuration, un champ vous permet d'entrer "iwconfig command extra arguments" (arguments hors commande iwconfig). Dans ce champ, entrez le texte suivant :
rate 54M
Cela devrait poermettre à la connexion de fonctionner à pleine vitesse dans le futur.
L'accès au réseau sans fil de l'Institut Dana-Farber Cancer avec une carte Wifi Intel 3945
Vous ne pouvez pas vous connecter au réseau sans fil sans invalider "allow access point roaming" (Traduction possible : "Permettre l'itinérance du point d'accès") (la case à cocher doit être décochée) pendant la configuration du réseau sans fil.
Problèmes logiciels
L'outil de configuration de l'imprimante n'est pas installé par défaut dans les éditions One
Voir aussi
bug n°43635. Le nouvel outil de configuration de l'imprimante, system-config-printer, n'est pas installé par défaut lors de l'installation de Mandriva Linux 2009 One. Cela signifie qu'il n'y a pas d'option disponible pour configurer une imprimante. Pour résoudre ce problème, utiliser tout simplement l'outil de gestion des logiciels pour installer le paquetage system-config-printer. Après avoir fait cela, l'outil de configuration de l'imprimante sera disponible dans le Centre de Contrôle de Mandriva, dans l'onglet Matériel.
Les éditions One échouent dans le démarrage du bureau graphique (xorg.conf non créé)
Voir aussi
bug n°43870. Plusieurs utilisateurs ont rapporté que les éditions One de Mandriva Linux 2009 échouent dans la création de fichier /etc/X11/xorg.conf lors du démarrage. Ceci peut résulter de plusieurs scénarii possibles. X.org tente de détecter automatiquement la carte et de charger le pilote adéquat. Si vous avez de la chance, cela marche, et vous ne remarquerez sans doute jamais le problème. Si l'auto-configuration de X.org échoue, cela provoque l'échec du démarrage du bureau graphique. Dans ce cas, la One démarrera sur un écran texte de login.
Dans le pire des cas, X.org trouvera un pilote valide suite à l'auto-configuration mais il ne fonctionnera pas à cause de conflits avec le système de framebuffer du noyau Linux, ce qui ressemblera à un échec du démarrage : un écran blanc avec un curseur clignotant en haut à gauche de l'écran. Il y a alors 2 approches possibles dans cette situation.
Vous pouvez redémarrer et utiliser le démarrage en mode texte plutôt que le démarrage en mode graphique. Cette option vous est proposée lors de l'écran du chargeur de démarrage après avoir appuyé sur la touche F3. Cela devrait réussir à démarrer le système en mode graphique, bien que le pilote le plus optimal pour votre carte n'ait certainement pas été choisi. Vous pouvez donc utiliser l'outil de configuration de la carte graphique du Centre de Contrôle Mandriva pour générer le fichier /etc/X11/xorg.conf. Vous devriez réaliser cette opération si vous avez l'intention d'installer la One de manière permanente. Si vous faites ceci puis installez la One sur votre disque, le problème ne devrait pas réapparaître quand vous démarrerez le système installé.
Une autre manière de faire : quand vous voyez l'écran blanc, appuyer sur Alt+F2 pour obtenir l'écran de connexion en mode texte. Vous pourrez ensuite vous connecter en tant que root (sans mot de passe) et lancer drakx11. Acceptez tous les paramètres par défaut dans cet outil puis fermez le. Lancez ensuite la commande service -f dm et le bureau graphique devrait démarrer correctement. Si vous installez la One sur votre disque dur, ce problème ne devrait pas réapparaitre quand vous démarrerez à partir du système installé. Néanmoins, il réapparaitra à chaque fois que vous démarrerez à partir du Live CD.
Si vous souhaitez vérifier si vous être atteint par ce problème, vérifiez tout simplement si le fichier /etc/X11/xorg.conf existe.
Les partitions cryptées ne sont pas montées lors du démarrage
Voir aussi
bug n°44464. Si vous utilisez la nouvelle fonctionnalité de diskdrake pour créer des partitions cryptées, et rendre ces partitions montées lors du démarrage (ou elles sont le système de partitions), il se peut que les passphrases ne vous soient pas demandées pendant le démarrage et que les partitions ne soient pas montées. Si elles sont le système de partitions, cela peut causer l'échec du démarrage du système. Cela est du au nouveau système graphique d'initialisation, splashy manquant de support pour le logiciel de cryptage cryptsetup.
Cependant nous nouos recommendons fortement de ne pas utiliser les outils Mandriva pour crypter une partiton système - c'est à dire toute partition qui pourrait contenir un des répertoires suivants :
bin/ boot/ dev/ etc/ home/ lib/ media/ mnt/ opt/ root/ sbin/ tmp/ usr/ var/
Il n'existe pas de solution connue pour ce problème. Nous travaillons pour lui trouver une mise à jour officielle aussi rapidement que possible. Une fois fait, vous pourrez installer un système avec des partitions cryptées et démarrer sans problème aussi longtemps que vous accepterez d'installer les mises à jour officielles à la fin du processus d'installation, lorsque cette option vous est offerte. Si vous ne le faites pas, le problème continuera à se produire.
L'outil Mandriva de configuration du réseau n'affiche pas la liste des points d'accès disponibles lors de la configuration de la connexion wifi
Voir aussi
bug n°43613. L'assistant Mandriva pour la création initiales des connexions réseau, drakconnect peut échouer pour afficher la liste des points d'accès disponibles lors de la tentative de configuration du wifi. La fenêtre qui devrait afficher la liste des points d'accès reste simplement vide.
Il est possible de contourner ce problème en attendant une minute ou deux; si l'adaptateur est capable de s'associer à un réseau quelconque, il le fera, et vous pourrez appuyer sur le bouton Suivant et continuer la configuration. Il peut aussi être possible de terminer la configuration de l'interface en utilisant le centre de configuration du réseau de Mandriva draknetcenter. Si cette méthode ne fonctionne pas pour vous, exécutez directement drakconnect depuis une console, avec cette commande :
Cela lancera l'outil en mode texte. Cette version ne comporte pas le bogue, aussi vous pourrez configurer votre interface. Ce problème est sous investigation et fera l'objet d'une future mise à jour officielle.
L'outil Mandriva de configuration du réseau ne peut pas configurer les cartes sans-fil Broadcom en utilisant le pilote natif
Voir aussi le
bug n°44740. Si votre système utilise une carte sans-fil Broadcom, vous ne pourrez pas le configurer correctement en utilisant l'assistant de configuration des connexions réseau Mandriva si vous choisissez le pilote natif (ce qui est le cas par défaut) plutôt que le pilote ndiswrapper. Ce problème est dû au pilote qui ne fonctionnera pas sans un firmware supplémentaire que vous devez extraire du fichier pilote qui vous a été fourni (comme décrit dans les notes de version ici) mais un bug empêche l'étape d'extraction du firmware de fonctionner correctement.
Pour contourner ce problème, vous devez extraire le firmware manuellement. Pour cela, d'abord télécharger le fichier pilote, nommé broadcom-wl-4.150.10.5.tar.bz2, comme décrit dans les notes de version ici. Extraire ensuite l'archive dans un répertoire de votre choix, puis lancer un terminal dans ce répertoire et lancer la commande suivante en tant que root :
b43-fwcutter -w /lib/firmware driver/wl_apsta_mimo.o
Cela va extraire le firmware requis dans le bon endroit. Il vous suffira ensuite d'utiliser l'assistant de configuration réseau Mandriva pour configurer la carte et cela fonctionnera correctement (mais veuillez aussi consulter la note dans l'errata qui précède celle-ci).
Cet errata ne concerne que l'utilisation du pilote natif pour les périphériques Broadcom b43. Cela est la sélection par défaut dans l'assistant de configuration du réseau de Mandriva. Si vous sélectionnez à la place Utiliser un pilote Windows via ndiswrapper, cet errata ne s'applique pas. Vous ne devez pas essayer d'utiliser le pilote mentionné dans cet errata avec ndiswrapper : ce n'est pas un pilote Windows et il ne fonctionnera pas. Le pilote dont vous avez besoin pour utiliser une carte sans fil Broadcom avec ndiswrapper est généralement appelé bcmwl5 : vous devez avoir bcmwl5.sys et bcmwl5.inf de copiés dans le même répertoire, et là, lorsque l'assistant demande le pilote Windows, choisissez bcmwl5.inf dans ce répertoire.
L'outil Mandriva de configuration du réseau sans fil ne gère pas correctement les clés contenant certains caractères spéciaux
Voir aussi
bug n°40065. L'outil Mandriva de configuration du réseau sans fil ne gère pas correctement les passphrases de cryptage qui contiennent certains caractères. Il existe deux solutions pour ce problème. Vous pouvez simplement changer votre passphrase de cryptage pour qu'il n'y ait plus aucun de ces caractères. Si vous ne souhaitez pas le faire, vous pouvez éditer le fichier de configuration approprié devant contenir la clé correcte. Pour le point d'accès par défaut de votre interface, éditez le fichier /etc/sysconfig/network-scripts/ifcfg-interface - par exemple, si l'interface est appelée wlan0, éditez le fichier /etc/sysconfig/network-scripts/ifcfg-wlan0. Pour tout autre point d'accès, éditez le fichier /etc/sysconfig/network-scripts/wireless.d/MAC, où MAC est l'adresse MAC du point d'accès. Dans les deux cas, éditez la ligne qui commence par le mot WIRELESS_ENC_KEY pour qu'elle ressemble à cela :
WIRELESS_ENC_KEY="s:KEY"
Où KEY est la clé. Ainsi si la clé était FOOBAR!@%=, vous devez éditer la ligne pour lire :
WIRELESS_ENC_KEY="s:FOOBAR!@%="
Une exception si la clé contient le double guillemet ("), auquel cas vous devez utiliser le simple guillemet (') pour encadrer la clé, par exemple :
WIRELESS_ENC_KEY='s:FOOBAR!"@%='
Ce problème fera l'objet d'une future mise à jour officielle
L'outil Mandriva pour accéder aux partages Windows / SMB / CIFS / Samba ne fonctionne pas
Voir aussi
bug n°42483. L'outil Mandriva pour accéder aux partages réseau SMB / CIFS / Samba (de type Windows) des lecteurs et partitions, disponibles dans le Centre de Contrôle Mandriva dans l'onglet Partages réseau, sous le nom Accéder aux disques et répertoires partagés de Windows (Samba), ne fonctionne pas. Il trouvera des partages disponibles, mais ne sera pas capable de les monter. Ceci car il tente de monter les partitions en utilisant le type obsolète smbfs au lieu du type correct cifs.
Pour contourner ce problème, nous vous conseillons simplement de ne pas utiliser cet outil, mais une autre méthode pour naviguer et accéder à ce type de lecteur ou partition partagés. Par exemple, dans les deux environnements de bureau KDE et GNOME, vous pouvez rejoindre l'emplacement smb:/ en utilisant le gestionnaire de fichiers pour accéder aux partages de type SMB / CIFS sur le réseau local. Pour monter des partages (afin qu'ils soient disponibles aussi pour les applications ni KDE, ni GNOME), smb4k peut être utilisé à la place.
Le problème fera l'objet d'une future mise à jour officielle.
Compiz et Metisse ne fonctionnent pas dans KDE 4 s'ils sont démarrés par startx
Si vous activez Compiz ou Metisse via l'utilitaire drak3d, puis essayez de démarrer KDE 4 depuis une console avec la commande startx après un démarrage de niveau 3 (au lieu de démarrer vers un gestionnaire graphique de login et de se loguer dans KDE 4 de cette façon, comme le font la plupart des utilisateurs), Compiz ou Metisse ne seront pas utilisés. Actuellement, ils ne fonctionneront que si vous vous loguez dans KDE 4 depuis un gestionnaire graphique de login plutot qu'en se loguant dans une console et en démarrant KDE 4 via startx.
Corruption graphique avec les cartes graphiques de la série NVIDIA GeForce 7xxx
Voir aussi
bug n°43716. Il y a des problèmes connus avec les performances graphiques dans KDE 4 avec les pilotes propriétaires des cartes graphiques NVIDIA. Afin de limiter ces problèmes, nous avons appliqué deux modifications à la configuration par défaut des pilotes NVidia : InitialPixmapPlacement=2 et GlyphCache=1. Cela a été testé et confirmé pour améliorer les performances dans presque tous les cas. Cependant, il semble que cela puisse aussi causer occasionnellement des problèmes de corruption (dans tous les environnements, pas seulement KDE 4) sur quelques autres cartes NVidia, apparemment de la série GeForce 7xxx. Si vous utilisez une carte NVidia et rencontrez des problèmes d'affichages, essayez de supprimer le fichier /etc/X11/xinit.d/01nvidia-performance.
Long délai avant l'ouverture du dialogue pour enregistrer ou ouvrir les fichiers dans les applications basées sur GTK+
Voir aussi
bug n°44532. En raison d'un bogue dans la paquetage beagle livré avec Mandriva Linux 2009, sur certains systèmes, il y a un long délai - qui met en évidence que l'application s'est figée - lorsqu'on essaye d'ouvrir ou de sauvegarder un fichier dans les applications basées sur GTK+ (notamment Mozilla Firefox, Opera, ou tout outil Mandriva). Si vous êtes affecté par ce problème, vous pouvez le contourner en enlevant le paquetage beagle, mais cela provoquera la désinstallation de toutes les applications basées sur Beagle. Les développeurs de Mandriva et de GNOME travaillent sur l'identification et la réparation du bogue qui cause ce problème, et une mise à jour sera rendue disponible le plus tôt possible.
Un candidat correctif a été placé parmi les paquetages du dépôt /main/testing : libbeagle-0.3.5.1-3mdv2009.0. Si vous désirez aider au test de la solution candidate, veuillez lire le chapitre "Tester les candidats à la mise à jour" ci-dessus, pour avoir les instructions concernant la configuration de votre système pour installer les paquetages du dépôt /main/testing . Suivez ces instructions, puis installez les paquetages de la mise à jour de libbeagle.
Les touches supplémentaires (touches multimedia) non supportées dans KDE 4
Voir aussi
bug n°43130. Les touches supplémentaires présentes sur beaucoup de claviers modernes - souvent appelées touches multimedia ne sont pas supportées par le bureau KDE 4 de Mandriva Linux 2009. Cela est du au fait que l'application de KDE qui gère ces touches, kmilo, n'est pas encore disponible dans la version KDE 4. Ce problème fera partiellement l'objet d'une mise à jour future, en associant par défaut les touches volume et muet avec le mixeur kmix, mais les autres touches supplémentaires ne peuvent pas être gérées avant qu'une version de kmilo pour KDE 4 ne soit disponible. Notez que ces touches fonctionnent correctement avec GNOME et Xfce.
Vous pouvez associer manuellement les touches volume et muet avec l'applet du mixeur kmix en suivant ces étapes. Cliquez droit sur l'icône du volume dans la zone de notification, et cliquez sur Afficher la fenêtre de mixage. Puis, dans la fenêtre qui apparaît, cliquez sur le bouton désigné Mixer. Essayez de changer les réglages de chaque canal pour voir celui qui contrôle le mieux votre carte (habituellement c'est le canal le plus à gauche). Puis cliquez droit sur le meilleur canal et cliquez sur Configurer les raccourcis ... Vous devez voir trois raccourcis - Diminuer le volume, Augmenter le volume, et (Dés)Active le mode muet. Cliquez sur Diminuer le volume, puis sur le bouton Aucun, et appuyez sur la touche de diminution de volume sur le clavier. Puis cliquez sur Augmenter le volume, puis sur le bouton Aucun et appuyez sur la touche d'augmentation de volume sur le clavier. Enfin cliquez sur (Dés)Active le mode muet, puis sur le bouton Aucun et appuyez sur la touche muet sur le clavier. Puis cliquez sur OK.
Activer le rendu des sous-pixels LCD dans KDE 4
Dans KDE4, QT4 possède un rendu prédéfini des sous-pixels mais il y a un bogue dans l'outil de configuration des polices dans le centre de contrôle de KDE (systemsettings), qui lui fait chercher un rendu des sous-pixels LCD seulement en FreeType. Le rendu des sous-pixels LCD FreeType est invalidé par défaut dans les bibliothèques FreeType de Mandriva en raison des droits, c'est pour cela que le dialogue apparaît en grisé dans le centre de contrôle KDE4, alors qu'en fait, il peut se reposer sur le rendu des sous-pixels prédéfini de QT4.
Pour remédier à cela, éditez ~/.fonts.conf (ce fichier est dans votre dossier /home/username, c'est un fichier caché, pour le voir, ouvrez Konqueror ou Dolphin puis ouvrez Affichage>Afficher les fichiers cachés). Vous pouvez éditer .fonts.conf avec un éditeur de texte, tel que kwrite. Changez :
<edit mode="assign" name="rgba" >
<const>none</const>
</edit>
par :
<edit mode="assign" name="rgba" >
<const>rgb</const>
</edit>
Pour vérifier son fonctionnement, ouvrir le centre de contrôle de KDE >Apparence>polices, assurez vous que l'anti-aliasing est actif, puis ouvrez Configurer. "Utiliser le rendu des sous-pixels" devrait être coché même même s'il est toujours en grisé.
Cela n'affectera que les applications nouvellement démarrées (par exemple les applications ouvertes après cette modification), aussi, il est préférable de se déconnecter puis de se reconnecter pour voir toute la différence avec ce paramétrage.
La plupart des moniteurs utilisent les sous pixels RGB, alors que d'autres utilisent BGR, aussi éditez .fonts.conf en conséquence.
Le panneau de KDE 4 affiche des corruptions graphiques lors d'exécution d'applications basées sur GTK+
Voir aussi
bug n°42420. Particulièrement avec les cartes graphiques NVIDIA, le panneau de KDE 4 peut afficher des corruptions graphiques (couleurs changée, des blancs) lors d'exécution d'applications basées sur GTK+, comme Mozilla Firefox ou OpenOffice.org, avec les adaptateurs graphiques de NVIDIA. La corruption est purement un problème esthétique : elle n'affecte pas les fonctionnalités du système ou du panneau. Nous travaillons à l'identification des causes de cette anomalie et à son remède, et cela sera résolu par une mise à jour officielle si possible.
KDE 4 ne peut pas afficher de nombreux formats vidéo bien qu'installés
Voir aussi
bug n°44586. Le lecteur vidéo par défaut de KDE 4, DragonPlayer, est incapable d'afficher de nombreux formats vidéo bien qu'installés. Si vous essayez de lire une vidéo dans un format non géré, DragonPlayer se lancera mais n'affichera pas la vidéo, seulement une fenêtre blanche.
Ce problème peut être en partie résolu en installant le paquetage gstreamer0.10-decoders, qui installera plusieurs codecs audio et vidéo qui permettront à DragonPlayer de lire plusieurs formats de vidéo. Si votre vidéo n'est toujours pas supportée, vous pouvez essayer d'installer le paquetage totem, qui fournit le lecteur multimédia Totem. Vous pouvez le trouver dans la section Son et Vidéo de menu, sous le nom Lecteur vidéo. Il peut utiliser le logiciel Codeina pour tenter d'identifier et de localiser un codec téléchargeable qui peut lire la vidéo en question.
Les applications KDE 4 ne peuvent pas lire les CD audio (mode numérique)
Voir aussi KDE Bug #164043. En raison de ce bug bien connu dans le backend Gstreamer pour Phonon (phonon-gstreamer), le logiciel intégré multimédia de KDE 4, que Mandriva Linux 2009 utilise par défaut; les applications standard de KDE 4, kscd and DragonPlayer, ne peuvent pas lire les CD audio en mode numérique (qui est utilisé par la plupart des gens et est le mode par défaut). Il existe plusieurs façons de contourner cela. Si vous voulez tout particulièrement utiliser kscd ou DragonPlayer, vous pouvez installer le paquetage phonon-xine. Ceci devrait faire commuter KDE sur le backend Xine pour Phonon (à la place de Gstreamer), qui autorise les applications basées sur Phonon à lire les CD audio sans problèmes. Cependant, il peut à son tour rendre certains autres fichiers audio ou vidéo non lisibles. Vous pouvez passer de Gstreamer à Xine pour résoudre ce problème. Exécutez l'outil Configurer le système KDE' (pas le Centre de Contrôle de Mandriva) en cliquant sur l'icône du tournevis et de la clé à molette dans la barre des tâches, ou dans le menu dans Outils, Outils système, Configurez votre bureau. Ensuite cliquez sur Son. Allez sur l'onglet Backend, et vous pouvez choisir l'ordre de priorité des deux Backends. Si vous voulez seulement écouter un CD, vous pouvez utiliser plusieurs solutions alternatives. Vous pouvez installer le paquetage totem, qui rendra totem disponible dans la section Son et Vidéo du menu sous le nom Lecteur vidéo. Cette application peut lire les CD audio sans problème. D'autre applications que vous trouverez dans les dépôts Mandriva pourront lire les CD audio comme vlc, kaffeine4 et kmplayer.
KDE 4 ne se met pas en veille lorsque le couvercle du portable est fermé
Voir aussi
bug n°43283. L'utilitaire kde4powersave inclus avec KDE 4, qui s'occupe de la gestion de l'énergie, ne réagit pas correctement à la fermeture du couvercle du portable. Il ne réalisera pas les actions configurées pour survenir lorsque le couvercle est fermé - y compris la configuration standard et la plus populaire, mettre le système en veille.
Pour éviter ce problème, vous devez soit mettre le portable manuellement en veille avant de le fermer, ou remplacer kde4powersave par un autre. Le gestionnaire de l'énergie pouvant convenir guidance-power-manager est disponible dans les dépôts officiels et a été rapporté comme fonctionnant correctement en cas de fermeture du couvercle.
Message d'erreur bogué lorsqu'on entre un mot de passe incorrect pour se connecter ou déverrouiller une session KDE 4
Voir aussi
bug n°44027. En raison d'un bogue dans le logiciel d'authentification PAM, si vous entrez un mot de passe incorrect pour vous connecter (en utilisant le gestionnaire de connexion KDM) ou déverrouiller une session KDE 4 qui a été verrouillée, un message d'erreur bogué sera affiché, similaire au suivant :
Cannot unlock the session because the authentication system failed to work; you must kill krunner_lock (pid XXXX) manually.
Le message d'erreur est inquiétant mais sans danger et déroutant. Vous serez alors redirigé vers l'écran de connexion ou de déverrouillage. Si vous entrez le mot de passe correct, les choses se dérouleront normalement.
Les applications KDE 4 ne peuvent s'exécuter sous root par su
Beaucoup d'utilisateurs sont habitués à exécuter des applications individuelles sous root en utilisant la commande su sur une console puis en lançant l'application, comme ceci :
[adamw@lenovo ~]$ su Password: [root@lenovo adamw]# kwrite
Cependant, pour la plupart des applications KDE 4 dans Mandriva Linux 2009, cela ne fonctionnera pas, vous devez utiliser la commande su - comme ceci :
[adamw@lenovo ~]$ su - Password: [root@lenovo adamw]# kwrite
Ce que cela fait est de créer un environnement root complet plutôt que de simplement vous donner les privilèges, mais la chose importante est que de cette manière, cela marche.
L'outil interactif de configuration du parefeu de Mandriva est trop grand pour les affichages en basse résolution
Voir aussi
bug n°38904. L'application de configuration du parefeu interactif de Mandriva, drakids, est trop grand pour tenir dans un affichage en basse définition, comme ceux de la plupart des netbooks. Pour contourner ce problème, dans la plupart des gestionnaires de fenêtres, vous pouvez tenir appuyé la touche Alt tout en faisant glisser la fenêtre. Ceci vous permet de la faire glisser loin du haut ou du bas de l'écran, et ainsi par déplacements successifs d'accéder à toutes les zones de la fenêtre.
Les webcams ne fonctionnent pas avec certaines applications (y compris Skype)
Plusieurs webcams ne fonctionnent pas avec certaines applications, y compris Skype, au sortir de la boite. Si votre webcam fonctionne avec certaines applications mais pas d'autres, vous pouvez contourner le problème en lançant l'application avec la commande suivante :
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so (application)
ou
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (application)
Ainsi pour Skype, vous devez exécuter :
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so skype
ou
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype
Pour que cela fonctionne, le paquetage libv4l doit être installé.
Pour les utilisateurs de x86-64, utilisez la commande ci-dessus exactement telle qu'elle est écrite pour Skype. Vous devez avoir la version i586 (non pas x86-64) du paquetage libv4l installée. Vous pouvez obtenir cela en téléchargeant : Le paquetage et en l'installant en exécutant la commande suivante sous root:
rpm -Uvh libv4l-0.4.3-1mdv2009.0.i586.rpm
depuis le répertoire dans lequel vous avez téléchargé le fichier. Cependant, pour la plupart des autres applications (qui seront des applications x86-64, au contraire de skype, qui est une application i586) vous devrez installer la version x86-64 du paquetage libv4l, et lancer l'application en utilisant la commande :
LD_PRELOAD=/usr/lib64/libv4l/v4l2convert.so (application)
Mandriva Linux 2009 ne démarre pas s'il est installé en tant que système KVM invité
Voir aussi
bug n°42358. En raison de l'utilisation d'une version plus ancienne du chargeur de boot graphique grub, une installation de Mandriva Linux avec la configuration par défaut ne démarrera pas en tant que système KVM (système de virtualisation) invité. Pour remédier à cela, lors de l'installation de Mandriva, changez de chargeur de boot pour le grub non-graphique ou Lilo.
Quelques fonctions OpenOffice.org ne fonctionnent pas dans l'édition One
Voir aussi le
bug n°44644. L'édition One de Mandriva Linux 2009 n'inclut pas l'environnement Java, en raison d'un manque de place. OpenOffice.org s'appuie sur Java pour plusieurs fonctionnalités, aussi celles-ci ne fonctionneront pas sur l'édition One exécuté en live, et ne fonctionneront pas non plus sur l'édition One après l'installation à moins que vous n'installiez le paquetage openoffice.org-java-common, en utilisant l'outil de gestion des paquetages de Mandriva. Voici un bref sommaire des fonctionnalités qui ne fonctionneront pas sans Java :
- Création de bases de données, formulaires et contrôles utilisateurs dans Base
- L'accès à tous types de bases de données dans Base qui utilise un connecteur JDBC
- Enregistrement / exporter vers AportisDoc (Palm) (.pdb), DocBook (.xml), Microsoft Word 2003 XML (.xml), OpenDocument Text (Flat XML) (.fodt), Pocket Word (.psw), Unified Office Format text (.uot), BibTex, Latex 2e et MediaWiki dans Writer
- Enregistrement / exporter vers Pocket Excel (.pxl), Microsoft XML 2003 Excel format (.xml) , OpenDocument SpreadSheet(Flat XML)(.fods) et Unified Office Format spreadsheet (.uos) dans Calc
- Enregistrement / exporter vers OpenDocument Presentation (Flat XML) (.fodp) et Unified Office Format presentation (.uop) dans Impress
- Enregistrement / exporter vers Enregistrer le fichier sous : OpenDocument Drawing (Flat XML) (.fodg) dans Draw
- Lettre, Fax, Agenda et assistant pages Web dans tous les modules
- Exporter vers XHTML (.xhtml, .html) dans tous les modules
- Enregistrement de documents contenant des macros écrites en JavaScript ou Beanshell dans tous les modules
A nouveau, pour rétablir ces fonctions, simplement installer le paquetage openoffice.org-java-common.
Les bibliothèques du paquetage libopenmotif3 ne peuvent pas être utilisées
Voir aussi
bug n°43808. Le paquetage libopenmotif3 est disponible dans les dépôts Mandriva Linux 2009. Aucun paquetage officiel ne dépend de cette bibliothèque, mais vous pouvez trouver des logiciels d'origine tierce qui nécessite un de ses fichiers, comme libXm.so.3. Si vous essayez d'installer ce paquetage pour fournir la bibliothèque, vous constaterez que la bibliothèque n'est pas trouvée par l'application. Ceci en raison du placement du fichier dans /usr/X11R6/lib, alors que Mandriva n'est plus configuré pour rechercher des bibliothèques à cet endroit.
Pour rapidement y remédier, vous pourriez copier ou lier les fichiers depuis /usr/X11R6/lib vers /usr/lib. Le problème ne sera pas résolu, car il se pourrait que l'introduction d'une nouvelle source de paquetages soit exigée par une ancienne version de openmotif, ce qui n'est pas ce que nous souhaitons pour l'instant. Le paquetage libopenmotif3 ne sera pas disponible dans les futures versions de Mandriva Linux.
Smart endommagé pour les metadata compressées lzma
Voir aussi
bug n°27697 (noter que seule la dernière partie de l'entrée de bugzilla est pertinente ici)
Pour la version du gestionnaire de paquetages Smart livrée avec Mandriva Linux 2009, le support du nouveau metadata 'info.xml.lzma' fut ajouté à la dernière minute. Les fonctionnalités requises pour cela furent aussi ajoutées au module lzma de python, mais malheureusement cette version ne fut pas, par accident, intégrée à l'édition. Un paquetage mis à jour 'python-liblzma-0.4.0-1mdv2009.0' se trouve dans la section 'contrib/testing' (pourra être déplacé dans 'contrib/updates' une fois vérifié). Notez que puisque cela peut avoir endommagé smart, l'empêchant d'installer cette mise à jour, vous pouvez être obligé de le télécharger manuellement et de l'installer avec 'rpm -Uvh python-liblzma-0.4.1-1mdv2009.1.*.rpm' ou d'utiliser urpmi à la place de smart.
Bureaux 3D accélérés
Bureaux 3D accélérés et lecture video
Voir aussi
bug n°25572. Si vous utilisez les technologies de bureau 3D accéléré incluses dans Mandriva Linux 2009 (AIGLX ou Xgl), vous pouvez remarquer que la lecture vidéo ne fonctionne pas bien - déplacer, redimensionner, agrandir la fenêtre vidéo cause des problèmes, ou bien vous pouvez voir d'étranges artefacts dans la vidéo. Vous pouvez aussi remarquer que, si vous utilisez la spécificité du 'cube' de compiz, la vidéo ne joue plus pendant la rotation du cube. Il y a deux façons d'éviter ce problème.
Si vous avez une puce graphique Intel, vous pouvez essayer d'utiliser le plugin Video Playback pour Compiz. En utilisant l'outil de configuration ccsm pour Compiz, déroulez vers le bas jusqu'à la section Utility et vous devriez voir un plugin dénommé Video Playback. Validez ce plugin. Ceci devrait permettre à la lecture vidéo de fonctionner dans plusieurs applications.
Si vous avez une autre puce graphique, ou vous rencontrez encore des problèmes avec le plugin Video Playback, vous devez paramétrer votre lecteur vidéo pour qu'il utilise un pilote de sortie qui n'emploie pas le recouvrement vidéo. Si vous utilisez AIGLX, vous devez utiliser le pilote de sortie x11 / xshm. Si vous utilisez Xgl, vous pouvez utiliser le pilote x11 / xshm ou le pilote de sortie OpenGL (qui peut être plus doux et offrir plus de réglages, tels que brillance / contraste, que le pilote x11 / xshm). La manière de faire cela est différente selon les lecteurs vidéo.
- Pour les lecteurs qui utilisent gstreamer - qui comprend le lecteur vidéo par défaut de Mandriva à la fois pour KDE 4 (DragonPlayer) et pour GNOME (Totem) - exécutez la commande gstreamer-properties, allez dans l'onglet "Video", et choisissez "X Window System (No Xv)" pour la sortie vidéo. Si gstreamer-properties n'existe pas, vous devez installer la paquetage gnome-media.
- Pour mplayer, pour les sorties x11 / xshm, ajoutez cette ligne à ~/.mplayer/config (et aussi à ~/.mplayer/mplayerplug-in.conf si vous utilisez le plugin du navigateur mplayerplugin) :
- vo=x11
Pour la sortie OpenGL, ajoutez plutôt la ligne suivante :
- vo=gl2
- Pour xine, allez dans le menu settings (configuration), mettez votre niveau d'expérience à "Advanced" (Avancé), puis allez dans l'onglet vidéo et modifiez "video driver to use" (pilote vidéo à utiliser) en "xshm" pour la sortie x11 / xshm ou en "openGL" pour la sortie OpenGL. Sinon, vous pouvez utiliser ces commandes en console. Pour la sortie x11 / xshm :
perl -pi -e 's|#video.driver:auto|video.driver:xshm|' ~/.xine/config
Pour la sortie OpenGL :
perl -pi -e 's|#video.driver:auto|video.driver:openGL|' ~/.xine/config
- Pour les versions KDE 3 de Kaffeine, allez dans la menu settings (configuration), sélectionnez "Xine backend configuration" et dans l'onglet vidéo modifier le pilote pour avoir "xshm" pour la sortie x11 / xshm ou "openGL" pour la sortie OpenGL
- Pour Totem en mode Xine, exécutez cette commande pour la sortie x11 / xshm :
perl -pi -e 's|#video.driver:auto|video.driver:xshm|' ~/.config/totem/xine_config
Ou cette commande pour la sortie OpenGL :
perl -pi -e 's|#video.driver:auto|video.driver:openGL|' ~/.config/totem/xine_config
- Pour la sortie x11 / xshm dans KMplayer, allez dans Settings -> Configure KMplayer. Puis dans la section "General Options" allez dans l'onglet Output (Sortie). Dans cette section changer Video Driver (pilote vidéo) pour "X11Shm".
- Pour la sortie x11 dans, ouvrir Tools -> Preferences -> Video et remplacer Output par X11 video output.

