| Notes de version de System Management Services (SMS) 1.5 |     |
| Notes de version de System Management Services (SMS) 1.5 | |
| C H A P I T R E 2 |
|
Bogues identifiés dans SMS 1.5 |
Ce chapitre présente des informations sur les bogues connus de SMS 1.5. Il aborde les sujets suivants :
Cette section recense les principaux bogues affectant le fonctionnement de SMS 1.5.
La commande smsrestore échoue lorsque l'archive cpio contient plus de 4 095 fichiers.
Le palliatif consiste à supprimer les fichiers inutiles et à recréer l'archive cpio à l'aide de smsbackup. Parmi les fichiers superflus, les candidats les plus probables sont les journaux post et les fichiers dump. Vous pouvez très bien vous retrouver avec jusqu'à 1 000 journaux post par domaine et autant de fichiers dump.
Si un serveur haut de gamme Sun Fire est exécuté alors que son numéro de série de châssis (CSN, Chassis Serial Number) n'est pas défini sur les contrôleurs système (SC) à l'aide de la commande setcsn, les rapports d'événements FMA (Fault Management Architecture, architecture de gestion des pannes) envoyés à NetConnect suite à l'arrêt d'un domaine (Dstop) indiqueront un numéro de série de châssis vide.
Palliatif : exécutez la commande setcsn pour définir le numéro de série du châssis, puis redémarrez SMS. Le numéro de série du châssis ne figurera pas dans les rapports d'événements tant que vous ne redémarrez pas SMS.
Pour plus d'informations sur la définition du numéro de série de châssis sur le SC, reportez-vous au Guide d'installation de System Management Services (SMS) 1.5.
Vous pouvez exécuter la commande ndd(1M) en tant que root afin de lire et d'écrire certains paramètres de pilotes de périphérique. scman(7D) (ndd/dev/scman) gère la partie SC Starcat du réseau MAN (Management Area Network) et prend en charge la commande ndd(1M).
Si le paramètre man_pathgroups_report de scman(7D) est mal interprété, une erreur d'origine logicielle peut apparaître comme une erreur matérielle grave. De ce fait, on peut faussement conclure qu'il est nécessaire de remplacer le matériel pour corriger ce problème root.
Lorsque le paramètre man_pathgroups_report est spécifié, une sortie de ce type peut être générée :
L'astérisque (*) figurant à la dernière ligne indique que « la dernière fois qu'une interface physique hme1 a été utilisée, une erreur a été détectée ». Or, par expérience, nous savons que la majorité des occurrences sont dues à un problème logiciel, pas matériel.
Le logiciel produit une erreur lorsque le pair du réseau MAN ne répond plus aux messages de « pulsation » ou en présence d'une transition d'état dlpi(7P) incorrecte. Il est possible de reproduire à volonté le premier scénario en exécutant la commande suivante en tant que root (en supposant que la sortie exacte présentée ci-dessus a été générée) :
Pour le SC qui exécute la commande (SC0, par exemple), son chemin actif passe de eri0 à hme1. Pendant quelques temps, le contrôleur système SC1 continue à envoyer les paquets à l'interface physique eri0 et le contrôleur système SC0 les transmet à hme1. Après un laps de temps relativement court, les deux contrôleurs sont synchronisés et communiquent alors au moyen de la même interface. Toutefois, un astérisque sera visible (sur chaque SC) pour signaler la dernière interface sur laquelle une erreur est survenue. Dans ce cas, l'erreur est effectivement due à un problème logiciel (autrement dit, l'erreur correspond réellement à une absence de réponse à une séquence de messages de « pulsation »). Il ne s'agit donc pas d'une erreur matérielle fatale.
Un astérisque sera effectivement visible dans la sortie en présence d'une erreur matérielle fatale persistante. Il ne faut cependant pas supposer que le matériel est la seule origine possible à la présence de cet astérisque.
Si vous supprimez, installez et assignez des cartes dans le domaine A situé sur un système Sun Fire, puis que vous exécutez la commande showenvironment avec l'option -d A, la commande renvoie un message d'erreur de ce type :
Aucune carte assignée au domaine A.
Le message d'erreur est faux et ne doit pas être pris en compte. Ce problème se pose uniquement dans le cas du domaine A.
Cette section résume les erreurs qui figurent dans les pages de manuel et la documentation relatives à SMS 1.5.
La remarque de la page de manuel rcfgadm(1M) devrait être rectifiée ainsi :
Si la commande rcfgadm échoue, l'état initial d'une carte n'est pas restauré. Un message d'erreur dxs ou dcs est consigné sur le domaine. Si l'erreur est récupérable, vous pouvez tenter à nouveau d'exécuter la commande.
Avant cela, assurez-vous que les entrées dcs suivantes se trouvent dans le fichier de configuration /etc/inetd.conf situé sur le domaine et qu'elles n'ont pas été désactivées :
S'il s'agit d'une erreur irrécupérable, redémarrez le domaine pour pouvoir utiliser la carte.
La description de l'option -c figurant dans la page de manuel testemail(1M) devrait être rectifiée ainsi :
Classe de pannes ou liste de classes de pannes séparée par des virgules qu'utilise testemail pour générer un événement.
-c fault_class, fault_class, fault_class
Des exemples de classes de pannes valables sont disponibles dans le fichier intitulé /etc/opt/SUNWSMS/config/SF15000.dict.
La remarque de la section « Description » devrait être rectifiée ainsi :
Lors de l'appel de testemail à l'aide d'une ressource de cache externe, assurez-vous que la carte système comprenant le cache externe est sous tension. À défaut, l'appel de testemail échouera et aucun e-mail ne sera généré.
La description de VCMON est inexacte pour les systèmes haut de gamme Sun Fire. La description appropriée figure à la section VCMON de ce même document.
Dans la description de la commande showboards, l'option -a devrait s'appeler -v.
Dans la description de la commande showenvironment, la catégorie « Device » (périphérique) aurait dû être supprimée.
Le premier exemple devrait être rectifié ainsi :
showlogs -d indicateur_domaine -p s
Le second exemple devrait être corrigé ainsi :
showlogs -d indicateur_domaine -p c
Les commandes suivantes devraient être ajoutées :
smsinstall : installe le logiciel SMS.
smsupgrade : met à niveau le logiciel SMS existant installé sur un système.
Annexe B (CR 6227544 et 4943474)
Les catégories de messages d'erreur suivantes devraient être ajoutées entre les codes d'erreur 11300 et 50000 :
11500-11699 : Réservés aux messages EFHD
11700-11899 : Réservés aux messages ELAD
11900-12099 : Réservés aux messages ERD
12100-12299 : Réservés aux messages Event Utilities
12300-12499 : Réservés aux messages Wcapp
12500-12699 : Réservés aux messages liés aux ID de FRU
12700-12799 : Réservés aux messages EBD
L'étape 3 devrait être rectifiée comme suit :
Exécutez la commande smsupgrade afin de réinstaller SMS.
L'étape 3 suivante devrait figurer après l'étape 2 :
Mettez à niveau le SE Solaris. Reportez-vous à la section « Mise à niveau du SE Solaris sur le SC », page 35.
L'étape 4 suivante devrait figurer après l'étape 3 :
Exécutez smsupgrade pour réinstaller SMS après une mise à jour importante du SE (voir page 36). Sinon, passez à l'étape suivante et restaurez la configuration SMS.
Le titre « Réinstallation du logiciel SMS 1.5 » devrait être remplacé par « Restauration de la configuration SMS 1.5 ».
| Notes de version de System Management Services (SMS) 1.5 | 819-3298-10 | |
Copyright © 2005, Sun Microsystems, Inc. Tous droits réservés.