Remarque : Cet article contient des références à certains éléments qui s'appliquent uniquement au système d'exploitation Solaris 10, par exemple, un nouveau bootblk. Le reste de l'article et le script fourni fonctionnent sous Solaris 8, 9 ou 10.
Il est important de recueillir suffisamment d'informations avant de démarrer une analyse de la cause première pour déterminer la raison pour laquelle une session patchadd ou patchrm a échoué. Ce document est censé aider les utilisateurs du système d'exploitation Solaris pour SPARC ou x86 à remplir cette tâche. L'accent est mis sur la procédure à mettre en oeuvre si le système sur lequel on a appliqué un patch n'a pas été réinitialisé correctement, soit en raison d'une grave erreur dans une boucle ou d'un abandon à l'invite OK (dans le cas du système d'exploitation Solaris pour plates-formes SPARC).
Cet article décrit quels sont les fichiers les plus importants, où les trouver et, en fonction de l'outil automatisé d'application de patch qui a été utilisé ou non, comment accéder à toutes les sorties importantes de ce type d'outil. Ce document n'a pas pour vocation d'analyser les causes réelles des défaillances car, les problèmes liés à l'application de patch peuvent avoir un grand nombre de causes, mais ce document tente de donner des directions génériques.
Initialisation du système à partir d'un CD-ROM ou du réseau.
Si le système a été réinitialisé et n'est pas revenu à l'état requis, ou qu'il a échoué à s'initialiser en mode maintenance (c'est-à-dire, si le système a abandonné à l'invite OK ou panique en boucle), il est nécessaire d'initialiser le système à partir du réseau ou d'un CD-ROM et de monter les systèmes de fichiers adéquats pour pouvoir accéder au système.
1. Pour les systèmes SPARC uniquement, si le système s'arrête à l'invite OK, comme ci-après, effectuer les sous-étapes suivantes :
{1} ok
a. Premièrement, essayer de capturer la sortie de la console appropriée à partir de la réinitialisation du système jusqu'à l'affichage de l'invite OK. Conserver cette sortie, car elle peut être très utile pour diagnostiquer les causes réelles sous-jacentes des erreurs.
b. À ce stade, essayer d'identifier si le problème peut être résolu sans avoir recours à l'initialisation à partir du réseau ou d'un média, par opposition à l'initialisation à partir du disque.
c. Si vous devez effectuer l'initialisation en mode mono-utilisateur à partir d'un média et monter les systèmes de fichiers racine, il existe plusieurs options :
Initialiser à partir du réseau
Initialiser à partir d'un CD-ROM
Pour initialiser à partir du réseau, assurez-vous que votre client est correctement configuré dans le serveur d'initialisation et que les connexions et la configuration réseau sont correctes (cela n'est pas traité dans ce document). Exécuter ensuite la commande suivante :
{1} ok boot net -s
Pour initialiser à partir d'un CD-ROM, exécuter la commande suivante :
{1} ok boot cdrom -s
2. Si le système panique et se réinitialise en boucle :
a. Essayer d'abord de capturer la sortie complète de panique à partir de la console.
b. Ensuite, pour un système SPARC, aller à l'invite OK et suivre les instructions de l'étape 1 ci-dessus.
Pour un système x86, vous devez veiller à ce que la priorité de l'initialisation du BIOS permette au système une initialisation à partir du réseau ou d'un CD-ROM avant d'initialiser à partir du disque dur. Si vous effectuez une initialisation réseau, assurez-vous que le client est correctement configuré dans le serveur d'initialisation. Par exemple, si vous utilisez le protocole DHCP, assurez-vous que les connexions et la configuration réseau du client soient correctes ou, si vous utilisez NIS, veillez à ce que le client soit correctement configuré dans le serveur NIS.
Collecte de données diverses pour activer l'analyse de la cause première
À ce stade, nous considérons que toutes les tâches dans l'étape 2 ci-dessus ont été réalisées et que le système a été monté sous /a.
Remarque : La plupart des données suivantes sont recueillies par le script patchanalysis_gather.txt, à l'exception des sorties réelles de patchadd dans le terminal. Voici le code source du fichier script patchanalysis_gather.txt.
1. Rassembler les fichiers journaux relatifs à patchadd ou patchrm.
Si une session patchadd a été exécutée uniquement par l'utilitaire patchadd alors, les données ne seront pas récupérables à moins que vous n'ayez capturé la sortie de la commande patchadd dans un fichier journal. Vous pouvez éventuellement simplement couper et coller la sortie patchadd du terminal ou de la console, si elle est encore disponible. Noter que dans ce cas vous souhaitez le résultat (STDOUT/STDERR) à partir de la commande patchadd elle-même, par opposition aux fichiers journaux dans /var/sadm/patch/ générés par patchadd.
Il est fortement recommandé de rediriger toutes les sorties patchadd vers un fichier lors de l'application de patch, pour que la sortie puisse être récupérée facilement s'il est nécessaire de faire des vérifications ultérieurement.
Par exemple, la commande suivante imprime la sortie de patchadd dans un fichier journal :
2. Dans les exemples suivants, nous utiliserons /a comme préfixe de toutes les commandes car nous supposons que l'initialisation a été faite à partir d'un autre support et que le système de fichiers racine est monté sous /a.
Si on a appliqué un patch au système à l'aide de l'outil Traffic Light Patch (TLP), alors la sortie TLP est située dans le répertoire suivant :
# ls /a/var/sadm/install_data/
PMGT:_TLP-Set_for_node_v4u-880c-muc07,_phase_GREEN,
_snapshot_2008-10-28_log
Ces données sont capturées par patchanalysis_gather.txt. Ces fichiers sont des fichiers texte standards contenant la sortie patchadd. Un fichier est généré à chaque exécution de l'outil TLP.
3. Si on a appliqué un patch sur le système avec Sun Update Connection - Enterprise (UCE) ou Sun xVM Ops Center (xVMOC) 1.x ou 2.x, vérifier que /a/var/opt/SUNWuce/agent existe, cela confirme que UCE, xVMOC 1.x, ou xVMOC 2.x a été utilisé.
Si /a/var/opt/SUNWuce/agent n'existe pas, et que vous avez vérifié que /a/var est monté correctement (en supposant qu'il est séparé du système de fichiers racine), le système n'a pas été retouché à l'aide d'un de ces outils.
4. Les données suivantes sont également capturées par patchanalysis_gather.txt.
Si /a/var/opt/SUNWuce/agent existe, exécuter les commandes suivantes et identifier lequel des outils automatisés d'application de patch a été utilisé :
pkgparam -R /a -v SUNWucea VERSION
Cette sortie implique que UCE soit installé : VERSION='1.1.1-314'.
pkgparam -R /a -v SUNWscnconnmgt VERSION
Cette sortie implique que xVMOC 1.x soit installé : VERSION='1.0.0'.
Cette sortie implique que xVMOC 2.x soit installé : VERSION='2.0.0.820,REV=2009.01.26.07.57.17'.
Il est utile de savoir quel utilitaire a été utilisé afin d'éviter tout problème potentiel dans l'outil ou de reproduire le problème sur un autre système pour identifier le problème sous-jacent.
Tous les outils automatisés d'application de patch mentionnés précédemment stockent leurs sorties dans /a/var/opt/SUNWuce/agent/logs/ :
# ls -l /a/var/opt/SUNWuce/agent/logs/
total 33032
-rw-r--r-- 1 root root 5610478 Feb 20 17:12 error.log
-rw-r--r-- 1 root root 10485681 Feb 20 13:15 error.log.ad_bak
-rw-r--r-- 1 root root 94418 Feb 20 13:28 job.log
-rw-r--r-- 1 root root 15478 Feb 19 11:02 job_50007101.tgz
-rw-r--r-- 1 root root 11377 Feb 20 13:04 job_50011801.tgz
-rw-r--r-- 1 root root 12189 Feb 20 13:15 job_50012001.tgz
-rw-r--r-- 1 root root 12185 Feb 20 13:28 job_50012002.tgz
-rw------- 1 root root 323598 Feb 19 10:53 last_nco_file.xml
-rw-r--r-- 1 root root 30730 Feb 20 13:28 last_seeking.tgz
-rw-r--r-- 1 root root 16602 Feb 20 13:28 nco.log
-rw-r--r-- 1 root root 253666 Feb 20 13:28 resolve.log
-rw-r--r-- 1 root root 1434 Feb 20 09:29 uce_agent.log
# gzcat /a/var/opt/SUNWuce/agent/logs/job_50012002.tgz | tar tvf -
drwxr-xr-x 0/0 0 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/
-rwx------ 0/0 4466 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/Task.out
-rw-r--r-- 0/0 167297 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
2/copy_inventory
-rw-r--r-- 0/0 497 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_basket
-rw-r--r-- 0/0 17 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_policy
Le fichier journal le plus important est Task.out. Il contient les résultats des commandes patchadd qui ont été exécutées. Cependant, il est recommandé de copier tous les fichiers /a/var/opt/SUNWuce/agent/logs en dehors du système pour un éventuel examen ultérieur. Copier également le résultat de ls -ltr of /a/var/opt/SUNWuce/agent/logs. Ces données sont capturées par patchanalysis_gather.txt.
D'autres fichiers journaux qui doivent être examinés
Cette section répertorie les données importantes qu'il peut être utile de capturer, il s'agit de toutes celles collectées par le script patchanalysis_gather.
patchadd -R /a -p
pkginfo -R /a -p
pkginfo -R /a
df -k /a et tous les autres points de montage sous /a
/a/var/adm/messages*
/a/var/sadm/system/admin/CLUSTER
/a/var/sadm/install/contents (ce fichier peut être volumineux)
/a/etc/system
/a/etc/vfstab
/a/release
Le contenu du répertoire /a/var/sadm/system/logs/
Le contenu du répertoire /a/var/sadm/install_data/
S'il existe des zones non globales, ce qui suit peut être utile :
/a/etc/zones/*
Ces données sont capturées par patchanalysis_gather.txt.
Le répertoire suivant dans chaque zone non globale contient les journaux des patchs et peut contenir des données utiles pour l'analyse des problèmes des zones non globales. Remarque : Actuellement, le script patchanalysis_gather.txtne peut pas recueillir ces données, car ce répertoire n'est pas de nature à contenir des données importantes concernant les problèmes de réinitialisation d'un système.
<zonepath>/root/var/sadm/patch/*
Examiner les fichiers journaux et de sortie
Une fois les données précédentes rassemblées, il est recommandé de commencer par un examen de la sortie de la commande patchadd. Puis, examiner également les journaux patchadd, qui ont été extraits de /var/sadm/patch/*/log.
Chercher les erreurs et avertissements dans ces journaux, et en particulier les sorties patchadd qui peuvent contenir des références à des défaillances pkgadd, avec un autre fichier journal correspondant stocké dans /var/tmp.
Si tel est le cas, récupérer ce fichier journal dans /a/var/tmp et l'examiner, car il est très utile pour déterminer ce qui est à l'origine de l'erreur.
Examiner également les sorties patchadd pour détecter si un script de patch, tel que prepatch ou postpatch, a échoué ou a généré des messages inattendus. Comparer les sorties patchadd pour connaître les sorties nominales patchadd depuis un système sur lequel l'application des patchs a réussi et rechercher des messages additionnels ou omis.
S'il existe des zones non globales sur le système concerné, examiner les sorties patchadd à la recherche d'erreurs propres à la présence de zones non globales. Celles-ci peuvent se présenter de la manière suivante :
Failed to boot non-global zone <zone-name>
Ce message indique que la zone non globale en question a été arrêtée et que patchadd n'a pu faire évoluer la zone touchée vers un état interne utilisé pour la maintenance logicielle. Si cela se produit, regrouper les fichiers /a/etc/xml zones/*. ainsi que /a/etc/vfstab. Ces fichiers permettront aux ingénieurs de déterminer l'état du système et la configuration de zone avant l'application du patch.
Si la sortie de la commande df -k indique que l'espace disponible dans le système de fichiers racine ou dans /var atteint un remplissage de 100%, il est recommandé de contacter le service de support Sun, car en fonction du patch en cours d'installation et de la partie de l'installation du patch qui a échoué, certaines étapes manuelles peuvent être nécessaires à la restauration de la cohérence du système.
Par exemple, si après l'exécution du patch 137137-09, l'espace disponible dans /platform atteint 100%, il se peut que, lors de la réinitialisation, le système ne puisse probablement pas s'initialiser au-delà de l'invite OK, et que des erreurs indiquent alors que le chargement de l'initialisation a échoué. Dans ce type de situation, il est possible que le système puisse être secouru relativement facilement sans aucun dommage durable, à condition qu'il reste suffisamment d'espace pouvant être récupéré pour permettre à l'archive d'initialisation d'être reconstruite.
Donc, comme vous pouvez le constater, il est essentiel de bien cibler le problème, car cela peut vous permettre de déterminer les mesures à prendre.
Problèmes potentiels et solutions
Problème : Impossible d'ouvrir /etc/path_to_inst.
Pour réparer, exécuter boot -ar et lorsque vous êtes invité à reconstruire /etc/patch_to_inst, choisir yes.
Problème : Des problèmes du bloc d'initialisation surviennent (qui sont propres à des systèmes Solaris 10 basés sur SPARC ayant été patchés avec le patch de mise à jour du noyau niveau 137137-09). En général, ces problèmes peuvent être identifiés par une erreur similaire aux suivantes :
The file just loaded does not appear to be executable.
Boot load failed. The file just loaded does not appear to be executable.
Il est recommandé de contacter le support technique de Sun avec les informations suivantes pour plus d'instructions. Vous pouvez obtenir $ROOTFSTYPE de df -n /a | awk '{print $3}' (si la racine est montée sur . /a) :
ls -l /platform/`uname -m`/boot_archive
ls -l /platform/`uname -m`/lib/fs/$ROOTFSTYPE/bootblk
Depuis la version de Solaris 10 10/08 pour les plates-formes SPARC ou si le patch de mise à jour du noyau 137137-09 a été appliqué, un nouveau bootblk est installé. Ce nouveau bootblk utilise une boot_archive pour initialiser votre système, par opposition au chargement par ufsboot, comme c'était le cas dans les mises à jour antérieures à la version Solaris 10 10/08 ou lorsque 137137-09 n'a pas été appliqué.
Il est donc d'une importance primordiale de comprendre quel bootblk est approprié. Installer le mauvais bootblk rend le système impossible à réinitialiser jusqu'à ce que le correct bootblk soit installé. Il est recommandé d'obtenir plus d'instructions de la part du support Sun.
Si le système de fichiers racine est à court d'espace dans /platform pendant la construction de la boot_archive, cela peut entraîner l'erreur suivante :
The file just loaded does not appear to be executable.
Une nouvelle fois, il est recommandé de contacter le support technique de Sun si cela se produit, car le système doit être analysé afin de déterminer la meilleure solution à long terme pour libérer de l'espace et construire la boot_archive avec la commande bootadm .
Il est important de noter que lorsque l'on utilise des outils tels que installboot lors de l'initialisation à partir d'un média pour installer un bloc d'initialisation, il faut utiliser installboot à partir du média approprié. Pour installer bootblk sur un système patché au niveau 137137-09 ou un système exécutant le SE Solaris 10 10/08, vous devez avoir initialisé en dehors du SE Solaris 10 10/08 ou ultérieur, ou vous devez utiliser installboot à partir du système monté.
Ainsi, par exemple, si le système est initialisé à partir du réseau ver une image Solaris 5/08, vous devez exécuter ceci :
#/a/usr/sbin/installboot
Mais pas cela :
#/usr/sbin/installboot
Mais si vous initialisez le système à partir du SE Solaris 10 10/08 ou ultérieur, il est possible de lancer les éléments suivants :
#/usr/sbin/installboot
Il faut donc être prudent lorsque l'on utilise des utilitaires système en initialisant à partir d'un média pour apporter des modifications à un système monté. Il est conseillé d'utiliser la dernière image de mise à jour Solaris disponible en tant qu'image d'initialisation.
Print-friendly Version
