Bugs liés à l'installation

SPARC: la suppression de patchs après une mise à niveau peut entraîner une corruption du référentiel WBEM (4820614)

La base de données CIM du référentiel WBEM peut être corrompue :

1. Si vous appliquez un des patchs suivants de l'environnement d'exploitation Solaris 9 9/02, 12/02, ou 4/03 à un système tournant sous Solaris 9.

   Version	Patch
   Solaris 9 9/02	112945-03
   Solaris 9 12/02	112945-05
   Solaris 9 4/03	112945-14

2. Vous retirez ensuite du système un de ces patchs.

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 ci-dessous.

• Pour éviter toute corruption du référentiel WBEM, procédez comme indiqué ci-dessous.

  1. Devenez superutilisateur.

  2. 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é.

  3. 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

  4. Restaurez le référentiel WBEM.

     # cp -rf path/logr /var/sadm/wbem/logr

  5. Redémarrez le serveur WBEM.

     # /etc/init.d/init.wbem start

• Pour créer un nouveau référentiel WBEM, procédez comme suit :

  ---

  Remarque :

  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.

  ---

  1. Devenez superutilisateur.

  2. Arrêtez le serveur WBEM.

     # /etc/init.d/init.wbem stop

  3. Supprimez les fichiers du répertoire /logr.

     # rm /var/sadm/wbem/logr/*

  4. Supprimez le répertoire /notFirstTime.

     # rmdir notFirstTime

  5. Démarrez le serveur WBEM.

     # /etc/init.d/init.wbem start

  6. Compilez manuellement tout MOF propriétaire.

     # /usr/sadm/bin/mofcomp nom_fichier_MOF

patchadd affiche un message d'erreur si un patch prenant en charge les architectures à patchs multiples est installé (4706994)

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 patchadd(1M) ne transmet pas le paramètre correct à la fonction remove_PATCH_PROPERTIES().

install_mu ne fonctionne pas correctement s'il est lancé à l'aide de sh (4062334)

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

patchadd affiche un message indiquant sa fermeture

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 trouvé aucun des modules auxquels elle devait appliquer le patch indiqué sur votre système, et que ce patch a donc été ignoré.

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. Ces modules peuvent avoir été supprimés par l'administrateur, ou ne jamais avoir été installés ; par exemple, si vous avez installé un cluster plus réduit que la distribution complète.

Solution : ignorez le message.

Connexion (login) impossible si le système n'est pas réinitialisé (4423853)

Si vous effectuez l'installation 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 :

• 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é.

• pam_projects.so.1 crée un vidage d'image mémoire lorsqu'un utilisateur ou un processus tente de se connecter et 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 MU3 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 en mode multi-utilisateur et qu'aucun superutilisateur n'est encore connecté, réinitialisez le système.