La base de données CIM du référentiel WBEM peut être corrompue :
Si vous appliquez une version du patch 112945 pour une version de mise à jour Solaris 9 à un système fonctionnant sous l'environnement d'exploitation Solaris 9.
Si vous supprimez ensuite ce patch.
Si le référentiel WBEM est corrompu, l'afficheur de journal de la Solaris Management Console affiche les messages d'erreur suivants :
CIM_ERR_FAILED: /usr/sadm/lib/wbem/../../../../var/sadm/wbem/logr/ preReg/PATCH113829install/Solaris_Application.mof,18,ERR_SEM, ERR_EXC_SET_CLASS,CIM_ERR_FAILED:Other Exception: java.io.StreamCorruptedException: invalid stream header |
Solution : choisissez l'une des solutions proposées ci-dessous.
Pour éviter toute corruption du référentiel WBEM, procédez comme indiqué ci-dessous.
Devenez superutilisateur.
Avant d'appliquer le patch, effectuez une sauvegarde du référentiel WBEM.
# cp -r /var/sadm/wbem/logr chemin/logr |
Dans cet exemple, chemin correspond au chemin d'accès au référentiel WBEM sauvegardé.
Si le référentiel WBEM est corrompu après la sauvegarde du patch, arrêtez le serveur WBEM.
# /etc/init.d/init.wbem stop |
Restaurez le référentiel WBEM.
# cp -rf path/logr /var/sadm/wbem/logr |
Redémarrez le serveur WBEM.
# /etc/init.d/init.wbem start |
Pour créer un nouveau référentiel WBEM, procédez comme indiqué ci-après.
cette solution ne restaure pas les données WBEM si le référentiel WBEM est corrompu. Toute donnée ajoutée lors de l'installation est perdue.
Devenez superutilisateur.
Arrêtez le serveur WBEM.
# /etc/init.d/init.wbem stop |
Supprimez les fichiers du répertoire /logr.
# rm /var/sadm/wbem/logr/* |
Supprimez le répertoire /notFirstTime.
# rmdir notFirstTime |
Démarrez le serveur WBEM.
# /etc/init.d/init.wbem start |
Compilez manuellement tout MOF propriétaire.
# /usr/sadm/bin/mofcomp nom_fichier_MOF |
Si vous installez un patch prenant en charge les architectures à patchs multiples, une erreur sans gravité, similaire à celle du message ci-après, risque de s'afficher dans le fichier /var/sadm/install_data/Maintenance_Update_log.
Installing xxxxxx-yy (x of xx) See /var/sadm/patch/xxxxxx-yy log for details grep: can't open pdgabbrev.extension/pkginfo |
Par exemple, si le patch 123456-01 contient les modules de patchs SUNWcar et SUNWcar.u, le message d'erreur suivant s'affiche :
grep: can't open SUNWcar.u/pkginfo |
Solution : ignorez le message d'erreur. Il n'affecte pas l'installation du patch. Le message indique que la commande patchadd ne transmet pas les paramètres corrects à la fonction remove_PATCH_PROPERTIES.
Pour de plus amples informations, reportez-vous à la page de manuel patchadd( 1M).
En raison de problèmes d'interaction entre sh(1) et ksh(1), il est possible que le programme install_mu n'installe pas correctement certains patchs. Cette défaillance survient lorsque vous le lancez à l'aide de la commande indiquée ci-dessous à partir d'une ligne de commande ou d'un script d'administration.
# /bin/sh ./install_mu options |
Solution : pour exécuter install_mu à partir d'une ligne de commande ou d'un script d'administration, utilisez la commande indiquée ci-dessous.
# ./install_mu options |
Un des messages sans gravité indiqués ci-dessous peut s'afficher dans le fichier Maintenance_Update_log du répertoire /var/sadm/install_data.
One or more patch packages included in XXXXXX-YY are not installed on this system. Patchadd is terminating. |
Ou :
Installation of XXXXXX-YY failed: Attempting to patch a package that is not installed. |
Ces messages indiquent que la commande patchadd n'a pu localiser sur votre système aucun des modules auxquels elle comptait appliquer un patch ; le patch indiqué a donc été sauté.
Ces messages s'affichent lorsque patchadd détecte un conflit entre l'architecture du patch et celle du système sur lequel vous voulez l'installer. Par exemple, un patch sun4u sur un système sun4m.
Cela peut aussi être dû à l'absence d'un ou plusieurs modules. Soit le module a été supprimé par l'administrateur, soit il n'a jamais été installé. Ce type d'erreur peut survenir par exemple si une grappe plus petite que la distribution complète a été installée.
Solution : ignorez le message d'erreur.
Si vous installez la MU en mode mono-utilisateur, ne lancez pas la commande exit une fois la procédure terminée. Utilisez la commande reboot. Si vous utilisez la commande exit au lieu de la commande reboot, vous pouvez être confrontés aux problèmes suivants :
Le système passe au niveau init 3, et vous devez le réinitialiser pour pouvoir vous reconnecter.
Aucun autre utilisateur ne pourra se connecter tant que le système n'aura pas été réinitialisé.
Le module pam_projects.so.1 crée un vidage d'image mémoire lorsqu'un utilisateur ou un processus tente de se connecter. Le message suivant s'affiche :
NOTICE: core_log: in.rshd[1479] core dumped: /var/crash/core.in.rshd.1479 |
Si un processus tente d'accéder au module pam_projects.so.1, la console système affiche des messages de chargement de module ; il peut s'agir des messages suivants :
cron[1433]: lad_modules: can not open module /usr/lib/security/pam_projects.so.1 |
Ces messages s'affichent également si vous installez la MU en mode multi-utilisateur, mais dans les deux cas ils disparaissent après réinitialisation du système.
Solution : si vous avez utilisé la commande exit après une installation en mode mono-utilisateur, réinitialisez le système.
Si vous avez utilisé la commande exit après une installation de la MU en mode multi-utilisateur et qu'aucun superutilisateur (root) n'est encore connecté, réinitialisez le système.