test

Notes de version de Solaris 10 5/08

Administration système

Cette section décrit les bogues d'administration du système dans SE Solaris 10.

Connexion impossible à la console de gestion Solaris après l'activation de Solaris Trusted Extensions (6639493)

La console de gestion SolarisTM se bloque et la connexion root à la console de gestion Solaris est impossible une fois Solaris Trusted Extensions activé. Le message d'erreur ci-dessous peut s'afficher en cas de blocage de la console de gestion Solaris :


Configuring the Management Server...

Solution : Procédez comme suit :

  1. Configurez Solaris Trusted Extensions et démarrez la console de gestion Solaris.

  2. Dans le menu de la console, choisissez Ouvrir une boîte à outils.

  3. Si localhost est répertorié, sélectionnez-le.

  4. Dans le cas contraire, tapez localhost.

  5. Choisissez la boîte à outils Policy=TSOL.

  6. Connectez-vous à nouveau à la console de gestion Solaris en tant qu'utilisateur root.

  7. (Facultatif) En cas d'échec de la deuxième connexion à la console de gestion Solaris, répétez les étapes 1 à 5 en tapant 127.0.0.1 au lieu de localhost à l'étape 3.

Échec possible de la commande zoneadm attach (6550154)

Lors de la connexion d'une zone, si l'hôte d'origine et le nouvel hôte présentent des packages au même niveau de patch mais à des historiques de patch intermédiaires différents, la connexion peut échouer. Plusieurs messages d'erreur s'affichent. Le message d'erreur dépend des historiques de patch des deux hôtes.

Solution : assurez-vous que la même séquence de versions de patch a été appliquée pour chaque patch sur les machines de l'hôte d'origine et du nouvel hôte.

Solaris est incapable de gérer les commutateurs de mode entre les modes hérité et AHCI pour le contrôleur SATA (6520224)

Dans les systèmes dotés d'un contrôleur SATA compatible AHCI, la configuration du BIOS permet habituellement au contrôleur d'être défini en mode RAID, hérité ou AHCI. Solaris prend en charge les modes hérité et AHCI.

Vous ne devez pas modifier la configuration du mode SATA dans le BIOS après l'installation initiale de Solaris. De même, vous ne pouvez pas la modifier avant ou après une mise à niveau Solaris. Si vous modifiez la configuration BIOS du mode SATA après l'installation de Solaris, la réinitialisation qui s'en suit échoue, sans qu'une explication quant aux raisons de la panne ne soit donnée.

Solution : si l'échec de l'initialisation est dû à la modification de la configuration BIOS, rétablissez le paramétrage d'origine et redémarrez Solaris.

Application de patch à activation différée (6486471)

À partir des patchs 119254-42 et 119255-42, les utilitaires d'installation de patchs, patchadd et patchrm, ont été modifiés : une nouvelle méthode de gestion est appliquée à certains patchs assurant de nouvelles fonctionnalités et à des fichiers existants incompatibles avec le système en cours d'exécution. Cette modification d'utilitaires affecte l'installation de ces patchs sur toutes les versions de Solaris 10. Ces patchs "à application différée" gèrent mieux les multiples modifications distribuées à l'aide de patchs de noyau.

Lors de l'application de patchs à activation différée, une copie du système de fichiers racine est créée à l'aide d'un système de fichiers loopback, lofs. Les fichiers d'origine patchés sont copiés à un emplacement fiable et la copie lofs du système de fichiers racine est patchée. Ensuite, le fichier d'origine est remonté via lofs sur le nouveau fichier lorsqu'il est patché. Ainsi, le système en cours d'exécution reste cohérent tout au long de l'application de patchs, les nouvelles fonctions restent inactives et toute modification incompatible reste masquée jusqu'à ce que l'utilisateur réinitialise le système.

Le système doit être réinitialisé dès que possible après l'application d'un patch à activation différée, mais il est possible d'ajouter d'autres patchs avant de procéder à la réinitialisation.

Le patch README contient des instructions sur les patchs nécessitant une réinitialisation.

Remarque –

Sun recommande vivement que les opérations de patch soient exécutées en mode monoutilisateur, tout particulièrement si c'est ce que conseille le patch README.

Si vous exécutez des zones non globales ou si lofs est désactivé, tenez compte des indications ci-dessous lors de l'installation et de la suppression de patchs à activation différée.

Aucun message d'erreur n'est affiché.

Solution : Sun recommande de gérer l'application de patchs à l'aide de Solaris Live Upgrade. Solaris Live Upgrade évite les problèmes d'application de patch sur un système en cours d'exécution. Solaris Live Upgrade réduit la période d'indisponibilité due à l'application des patchs et diminue les risques en offrant la possibilité de poursuivre les opérations en cas de problème. Pour de plus amples informations, reportez-vous au Guide d’installation de Solaris 10 5/08 : Solaris Live Upgrade et planification de la mise à niveau.

Erreur possible d'applications 32 bits recherchant des informations relatives à l'état des systèmes de fichiers de grande taille (6468905)

Exécutées sur des systèmes de fichiers volumineux, ZFS par exemple, les applications recherchant des informations sur l'état des systèmes à l'aide de statvfs(2) ou statfs(2) affichent une erreur. Le message d'erreur suivant s'affiche :


Value too large for defined data type

Solution : les applications doivent plutôt utiliser statvfs64().

Utilisation restreinte de la commande patchadd avec l'option -R pour spécifier un chemin racine de remplacement à partir des systèmes ne tenant pas compte des zones (6464969)

Sur les systèmes exécutant une version de Solaris incompatible avec les zones, la commande patchadd - R, ou toute commande acceptant l'option -R ne permet pas de spécifier un chemin racine de remplacement pour une zone globale contenant des zones non globales installées.

Contrairement à la commande luupgrade [- t, -T, -p, -P], aucun message d'erreur relatif aux restrictions d'utilisation de ces commandes ne s'affiche.

Rien n'indique que l'option -R n'a pas fonctionné. En raison de l'échec de la commande, les packages ou patchs Solaris 10 ne sont ajoutés à aucune zone non globale installée.

Ce problème se produit lors de l'installation et de la désinstallation des packages ou patchs.

Remarque –

L'option -R fonctionne si l'environnement d'initialisation de remplacement possède des zones non globales configurées, mais aucune zone non globale installée. En cas de doute sur l'existence de zones non globales installées et utilisées en tant que chemin racine de remplacement, et pour éviter tout problème, limitez l'utilisation de l'option -R dans toutes les instances.

Pour plus d'informations, reportez-vous aux pages de manuel suivantes :

Solution 1 : mettez le système d'exploitation à niveau vers Solaris 10 1/06 ou une version supérieure.

Si vous exécutez la version Solaris 10 3/05, installez les patchs suivants pour permettre l'exécution des commandes acceptant l'option -R pour créer un chemin racine de remplacement :

Solution 2 : limitez l'utilisation de la commande patchadd -R et de toute commande acceptant l'option -R pour créer un chemin racine de remplacement.

À la place, initialisez le chemin racine de remplacement, par exemple la version Solaris 10, comme système d'exploitation actif. Ensuite, installez et désinstallez les packages et patchs Solaris 10 sans utiliser l'option -R.

Sun Patch Manager Tool 2.0 incompatible avec les versions précédentes

Un système qui exécute Sun Patch Manager Tool 2.0 peut gérer des systèmes distants exécutant l'outil Patch Manager, notamment Sun Patch Manager Tool 1.0.

Cependant, un système avec une version antérieure de l'outil Patch Manager ne peut pas gérer des systèmes distants qui exécutent Patch Manager Tool 2.0. Les versions précédentes de ce programme comprennent notamment :

Remarque –

La prise en charge par CIM/WBEM (Common Information Model/Web Based Enterprise Management) de l'outil Patch Manager n'existe pas dans le système d'exploitation Solaris 8. Par conséquent, la gestion à distance avec Patch Manager n'est pas applicable aux systèmes Solaris 8.

Impossible de supprimer les clients sans disque existants du système (6205746)

Si vous utilisez la commande smdiskless pour supprimer un client sans disque, cette commande échoue. Le client sans disque n'est pas supprimé des bases de données du système. Le message d'erreur suivant s'affiche :


Failing with error EXM_BMS.

Solution : annulez le partage de la partition /export avant d'ajouter un nouveau client.

SPARC : la commande smosservice delete ne parvient pas à supprimer tous les répertoires (6192105)

Si vous utilisez la commande smosservice delete pour supprimer un service de client sans disque, cette commande ne supprime pas tous les répertoires de service.

Solution : Procédez comme indiqué ci-dessous.

  1. Vérifiez qu'aucun client existant n'utilise le service.


    # unshare /export/exec/Solaris_10_sparc.all
# rm -rf /export/exec/Solaris_10_sparc.all
# rm -rf /export/exec/.copyofSolaris_10_sparc.all
# rm -rf /export/.copyofSolaris_10
# rm -rf /export/Solaris_10
# rm -rf /export/share
# rm -rf /export/root/templates/Solaris_10
# rm -rf /export/root/clone/Solaris_10
# rm -rf /tftpboot/inetboot.sun4u.Solaris_10

  2. Supprimez l'entrée suivante du fichier /etc/bootparams. 


    fs1-24 boottype=:os
    Remarque –

    Ne supprimez cette entrée que si ce serveur de fichiers ne fournit aucune fonction ou ressource pour d'autres services.

  3. Supprimez l'entrée suivante du fichier /etc/dfs/dfstab. 


    share -F nfs -o ro /export/exec/Solaris_8_sparc.all/usr

  4. Modifiez le fichier /var/sadm/system/admin/services/Solaris_10.

    • Si le serveur de fichiers n'est pas Solaris_10, supprimez le fichier.

    • Si le serveur de fichiers est Solaris_10, supprimez toutes les entrées après les trois premières lignes. Les lignes supprimées indiquent les packages USR_PATH et SPOOLED ROOT du service dans /export/root/templates/Solaris_10 et les plates-formes prises en charge.

La commande kill -HUP n'exécute pas toujours l'agent pour qu'il relise le fichier de configuration snmpd.conf (4988483)

Après avoir modifié le contenu du fichier snmpd.conf, vous pouvez exécuter la commande kill -HUP snmp Process ID. Cette commande arrête le processus snmp. Puis, elle envoie un signal à l'agent maître de System Management Agent (snmpd) pour qu'il relise snmpd.conf et applique les modifications que vous y avez apportées. La commande peut ne pas exécuter l'agent maître pour qu'il relise le fichier de configuration. Par conséquent, l'utilisation de la commande ne peut pas toujours activer les modifications dans le fichier de configuration.

Plutôt que d'utiliser la commande kill -HUP, redémarrez System Management Agent après avoir ajouté des modifications à snmpd.conf. Procédez comme suit :

  1. Prenez le rôle de superutilisateur.

  2. Tapez la commande suivante :

    # /etc/init.d/init.sma restart

x86 : échec de l'initialisation de la partition de service en cas d'activation de la touche F4 pendant l'initialisation du BIOS (4782757, 5051157)

Vous initialisez un serveur Sun LX50 qui comporte une partition Service et sur lequel SE Solaris 10 sur x86 est installé. Vous avez la possibilité d'initialiser la partition de service à l'aide de la touche F4. Cependant, cette opération efface le contenu de l'écran. Le système ne parvient pas à initialiser la partition de service.

Solution : n'appuyez pas sur la touche F4 lorsque l'écran d'initialisation du BIOS apparaît. Après quelques secondes, l'écran affichant les informations sur la partition de disque actuelle apparaît. Sélectionnez le chiffre dans la colonne Part# correspondant à type=DIAGNOSTIC type=DIAGNOSTIC puis appuyez sur la touche Entrée. le système initialise la partition de service.

Certains appels de méthodes d'API com.sun échouent avec le protocole XML/HTTP (4497393, 4497399, 4497406, 4497411)

Si vous décidez d'utiliser l'interface de programmation d'application com.sun plutôt que l'API javax pour développer votre logiciel WBEM, seul l'appel de méthode distant (RIM) CIM est totalement pris en charge. Il n'est pas certain que d'autres protocoles tels que XML/HTTP fonctionnent tout à fait avec l'API com.sun.

Le tableau suivant répertorie des exemples d'appels qui sont exécutés avec succès sous RMI, mais échouent sous XML/HTTP.

Appel de méthode 

Message d'erreur 

CIMClient.close()

NullPointerException

CIMClient.execQuery()

CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED

CIMClient.getInstance()

CIM_ERR_FAILED

CIMClient.invokeMethod()

XMLERROR: ClassCastException