Dépannage des problèmes des clients sans disque

Cette section décrit les problèmes qui surviennent lors de la gestion des clients sans disque et les solutions possibles.

Dépannage des problèmes d'installation des clients sans disque

La commande smosservice add n'installe aucun des packages désignés comme ARCH=all dans le système de fichiers racine (/) ou /usr. Par conséquent, ces packages sont ignorés. Aucun message d'avertissement ou d'erreur ne s'affiche. Vous devez ajouter ces packages au nouveau service du système d'exploitation Solaris Oracle manuellement. Ce comportement date du SE Solaris 2.1. Il s'applique aux clients SPARC comme aux clients x86. Notez que la liste des packages manquants varie en fonction de la version Solaris exécutée.

Localisation et installation des packages `ARCH=all` manquants

Cette procédure vous indique comment localiser et installer les packages ARCH=all manquants une fois que vous avez créé le service du SE Oracle Solaris sur le serveur. Les exemples fournis dans cette procédure s'appliquent au SE Solaris 10 6/06.

Localisez tous les packages dotés du paramètre ARCH=all.
1. Modifiez les répertoires pour le répertoire Product du support pour l'image d'Oracle Solaris 10. Par exemple :
```
% cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
```
2. Répertoriez tous les packages du fichier pkginfo dotés du paramètre ARCH=all.
```
% grep -w ARCH=all */pkginfo
```
  Si un message d'erreur signalant que la liste d'arguments est trop longue s'affiche, vous pouvez également exécuter la commande suivante pour générer la liste :
```
% find . -name pkginfo -exec grep -w ARCH=all {} /dev/null \;
```
  Notez que l'exécution de cette commande met plus de temps à produire des résultats.
  La sortie se présente de la manière suivante :
```
./SUNWjdmk-base/pkginfo:ARCH=all
./SUNWjhdev/pkginfo:ARCH=all
./SUNWjhrt/pkginfo:ARCH=all
./SUNWjhdem/pkginfo:ARCH=all
./SUNWjhdoc/pkginfo:ARCH=all
./SUNWmlibk/pkginfo:ARCH=all
```
  Les informations fournies dans cette liste vous permettent de déterminer quels sont les packages installés dans le système de fichiers /usr et ceux qui sont installés dans le système de fichiers racine (/).
3. Vérifiez la valeur du paramètre SUNW_PKGTYPE dans la liste des packages générée.
  Les packages appartenant au système de fichiers /usr sont désignés comme SUNW_PKGTYPE=usr dans le fichier pkginfo. Les packages appartenant au système de fichiers racine( /) sont désignés comme SUNW_PKGTYPE=root dans le fichier pkginfo. Dans la sortie ci-dessus, tous les packages appartiennent au système de fichiers /usr.
Connectez-vous en tant que superutilisateur ou endossez un rôle équivalent.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour plus d'informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Créez les fichiers d'administration d'installation temporaires.
Vous devez créer un fichier d'administration d'installation séparé pour les packages installés dans le système de fichiers racine (/) et un autre pour les packages installés dans le système de fichiers /usr.
- Pour les packages ARCH=all installés dans le système de fichiers /usr, créez le fichier d'administration d'installation temporaire suivant :
```
# cat >/tmp/admin_usr <<EOF
mail=
instance=unique
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
basedir=/usr_sparc.all
EOF
#
```
- Pour les packages ARCH=all installés dans le système de fichiers racine (/), le cas échéant, créez le fichier d'administration d'installation temporaire suivant :
```
# cat >/tmp/admin_root <<EOF
mail=
instance=unique
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
EOF
#
```
Installez les packages ARCH=all manquants.
1. Si le répertoire courant n'est pas le répertoire Product du support pour l'image Oracle Solaris 10, modifiez les répertoires par celui-ci. Par exemple :
```
# cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
```
  Vous pouvez exécuter la commande pwd pour déterminer le répertoire courant.
2. Installez les packages ARCH=all manquants dans le système de fichiers /usr.
```
# pkgadd -R /export/Solaris_10 -a /tmp/admin_usr -d `pwd` [ package-A package-B ...]
```
  Plusieurs packages peuvent être répertoriés lorsque vous exécutez la commande pkgadd.
3. Vérifiez si les packages ARCH=all ont bien été installés.
```
# pkginfo -R /export/Solaris_10 [package-A package-B ...]
```
4. Installez les packages ARCH=all manquants dans le système de fichiers racine (/).
  Notez qu'il est possible qu'aucun de ces packages n'existe.
```
# pkgadd -R /export/root/clone/Solaris_10/sun4u -a /tmp/admin_root -d `pwd` [ package-X package-Y ...]
```
5. Vérifiez si les packages ARCH=all ont bien été installés.
```
# pkginfo -R /export/root/clone/Solaris_10/sun4u [ package-X package- ...]
```
Une fois l'ajout des packages ARCH=all manquant terminé, supprimez le fichier d'administration d'installation temporaire.
```
# rm /tmp/administration-file
```

Exemple 7-10 Localisation et installation des packages ARCH=all manquants

Cet exemple montre comment installer un package ARCH=all manquant, SUNWjdmk-base, dans le système de fichiers /usr.

% uname -a
SunOS t1fac46 5.10 Generic_118833-02 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

% cat /etc/release
                  Oracle Solaris 10 8/11 s10x_u10wos_08 X86
  Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
                           Assembled 28 February 2011
% cd /net/ventor/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
% grep -w ARCH=all */pkginfo
Arguments too long

% find . -name pkginfo -exec grep -w ARCH=all {} /dev/null \;
./SUNWjdmk-base/pkginfo:ARCH=all
./SUNWjhdev/pkginfo:ARCH=all
./SUNWjhrt/pkginfo:ARCH=all
./SUNWjhdem/pkginfo:ARCH=all
./SUNWjhdoc/pkginfo:ARCH=all
./SUNWmlibk/pkginfo:ARCH=all

% grep -w SUNW_PKGTYPE=usr ./SUNWjdmk-base/pkginfo ./SUNWjhdev/pkginfo ...
./SUNWjdmk-base/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdev/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhrt/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdem/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdoc/pkginfo:SUNW_PKGTYPE=usr

% grep -w SUNW_PKGTYPE=root ./SUNWjdmk-base/pkginfo ./SUNWjhdev/pkginfo ...
% su
Password: xxxxxx # cat >/tmp/admin_usr <<EOFmail=
instance=unique
partial=nocheck
runlevel=nocheck
idepend=nochec> k
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
basedir=/usr_sparc.all
EOF

# pwd
/net/ventor/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product

# pkginfo -R /export/Solaris_10 SUNWjdmk-base 
ERROR: information for "SUNWjdmk-base" was not found

# pkgadd -R /export/Solaris_10 -a /tmp/admin_usr -d `pwd` SUNWjdmk-base


Processing package instance <SUNWjdmk-base> </net/ventor/export/Solaris/s10u2/combined.s10s_u2wos...


Java DMK 5.1 minimal subset(all) 5.1,REV=34.20060120
Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Using </export/Solaris_10/usr_sparc.all>
## Processing package information.
## Processing system information.

Installing Java DMK 5.1 minimal subset as <SUNWjdmk-base>

## Installing part 1 of 1.
2438 blocks

Installation of <SUNWjdmk-base> was successful.

# pkginfo -R /export/Solaris_10 SUNWjdmk-base
application SUNWjdmk-base Java DMK 5.1 minimal subset

# rm /tmp/admin_usr

Dépannage des problèmes généraux des clients sans disque

Cette section présente des problèmes courants susceptibles de se produire avec des clients sans disque et les solutions possibles.

Problème : Le client sans disque renvoie le message Owner of the module /usr/lib/security/pam_unix_session.so.1 is not root lors d'une tentative de connexion, le système de fichiers /usr est détenu par nobody.

Solution : Pour corriger le problème, appliquez cette solution :

À l'aide d'un éditeur de texte, modifiez le fichier server:/export/root/client/etc/default/nfs du client sans disque.

Modifiez la ligne #NFSMAPID_DOMAIN=domain comme suit :

NFSMAPID_DOMAIN=the_same_value_as_in_server's_/var/run/nfs4_domain

Assurez-vous que le serveur de SE et le client sans disque ont le même domaine nfsmapid. Pour vérifier ces informations, consultez le fichier /var/run/nfs4_domain.

Attention - Si le fichier nfs4_domain du client sans disque contient une valeur différente du fichier /var/run/nfs4_domain du serveur de SE, vous ne pourrez pas vous connecter au système une fois le client sans disque initialisé.

Redémarrez le client sans disque.

Pour plus d'informations, reportez-vous au Chapitre 3, NFS Tunable Parameters du Oracle Solaris Tunable Parameters Reference Manual et à la page de manuel nfsmapid(1M).

Problème : Le serveur de SE ne parvient pas à effectuer les opérations suivantes :

Répondre aux requêtes du protocole RARP (Reverse Address Resolution Protocol) du client
Répondre aux requêtes bootparam du client
Monter un système de fichiers racine (/) pour le client sans disque

Solution : Les solutions suivantes s'appliquent dans un environnement de fichiers.

Vérifiez que files est répertorié en tant que première source pour hosts, ethers et bootparams dans le fichier /etc/nsswitch.conf sur le serveur de SE.
Vérifiez que l'adresse IP du client apparaît dans le fichier /etc/inet/hosts.

Remarque - Si vous n'exécutez pas au moins la version Solaris 10 8/07, vous devez également vérifier si l'adresse IP du client apparaît dans le fichier /etc/inet/ipnodes.
Dans cette version d'Oracle Solaris, le fichier /etc/inet/hosts est un fichier unique qui contient les entrées IPv4 et IPv6. Vous ne devez pas conserver les entrées IPv4 dans deux fichiers hosts qui requièrent toujours une synchronisation. Pour garantir la compatibilité ascendante, le fichier /etc/inet/ipnodes est remplacé par un lien symbolique du même nom vers le fichier /etc/inet/hosts. Pour plus d'informations, reportez-vous à la page de manuel hosts(4).
Vérifiez si l'adresse Ethernet du client s'affiche dans le fichier /etc/ethers.
Vérifiez si le fichier /etc/bootparams contient les chemins d'accès suivants au répertoire racine (/) et aux zones de swap du client.
```
client root=os-server:/export/root/
client swap=os-server:
/export/swap/client 
```
La taille de la zone de swap varie selon que vous spécifiez l'option -x swapsize ou non lors de l'ajout du client sans disque. Si vous spécifiez l'option -x dump lors de l'ajout du client sans disque, la ligne suivante est présente.
```
dump=os-server:/export/dump/client
 dumpsize=512
```
La taille du volume de vidage varie selon que vous spécifiez l'option -x dympsize ou non lors de l'ajout du client sans disque.
Vérifiez si l'adresse IP du serveur du système d'exploitation apparaît dans le fichier /export/root/ client/etc/inet/hosts.

Problème : Le serveur de SE ne parvient pas à effectuer les opérations suivantes :

Répondre aux requêtes RARP du client
Répondre aux requêtes bootparam du client
Monter un système de fichiers racine (/) pour le client sans disque

Solution : Les solutions suivantes s'appliquent dans un environnement de service de noms.

Vérifiez si l'adresse Ethernet et l'adresse IP du serveur de SE et du client sont correctement mappées.
Vérifiez si le fichier /etc/bootparams contient les chemins d'accès au répertoire racine (/) et aux zones de swap du client.
```
client root=os-server:/export/
root/client swap=os-server:/export/
swap/client swapsize=24
```
La taille de la zone de swap varie selon que vous spécifiez l'option -x swapsize ou non lors de l'ajout du client sans disque. Si vous spécifiez l'option -x dump lors de l'ajout du client sans disque, la ligne suivante est présente.
```
dump=os-server:/export/dump/
client dumpsize=24
```
La taille du volume de vidage varie selon que vous spécifiez l'option -x dympsize ou non lors de l'ajout du client sans disque.

Problème : Erreur grave du client sans disque

Solution : Vérifiez les éléments suivants :

L'adresse Ethernet du serveur de SE est correctement mappée avec l'adresse IP. Si vous avez physiquement déplacé un système d'un réseau à un autre, vous pouvez avoir oublié de remapper la nouvelle adresse IP du système.
Le nom d'hôte, l'adresse IP et l'adresse Ethernet du client n'existent pas dans la base de données d'un autre serveur sur le même sous-réseau qui répond aux requêtes RARP, TFTP (Trivial File Transfer Protocol) ou bootparam du client. Souvent, les systèmes de test sont configurés pour installer leur système d'exploitation à partir d'un serveur d'installation. Dans ces cas-là, le serveur d'installation répond aux requêtes RARP ou bootparam du client, en renvoyant une adresse IP incorrecte. Cette adresse incorrecte risque d'entraîner le téléchargement d'un programme d'initialisation de la mauvaise architecture ou l'impossibilité de monter le système de fichiers racine (/) du client.
Un serveur d'installation (ou un ancien serveur de SE) qui transfère un programme d'initialisation incorrect ne répond pas aux requêtes TFTP du client sans disque. Si le programme d'initialisation est d'une architecture différente, une erreur grave du client se produit immédiatement. Si le programme d'initialisation se charge à partir d'un serveur qui n'appartient pas au système d'exploitation, le client peut obtenir sa partition racine à partir de ce serveur et sa partition /usr à partir du serveur de SE. Dans ce cas, le client affiche une erreur grave si les partitions racine et /usr possèdent des architectures ou versions conflictuelles.
Si vous utilisez un serveur d'installation et un serveur de SE, vérifiez que l'entrée suivante figure dans le fichier /etc/dfs/dfstab :
```
share -F nfs -o -ro 
/export/exec/Solaris_version- \
instruction-set.all/usr
```
où version= 8, 9, 10 et instruction-set=sparc ou i386.

Vérifiez que les partitions racine (/), /swap et /dump (le cas échéant) du client sans disque disposent d'entrées partagées :

share -F nfs -o rw=client,root=client
 /export/root/client 
share -F nfs -o rw=client,root=client /export/swap/
client 
share -F nfs -o rw=client,root=client /export/dump/
client

Sur le serveur de SE, tapez la commande suivante pour vérifier quels fichiers sont partagés :
```
% share
```
Le serveur de SE doit partager /export/root/client et /export/swap/client-name (par défaut), ou les partitions racine, /swap et /dump spécifiées lors de l'ajout du client sans disque.
Vérifiez si les entrées suivantes figurent dans le fichier /etc/dfs/dfstab :
```
share -F nfs -o ro /export/exec/Solaris_version-
instruction-set.all/usr
share -F nfs -o rw=client,root=client /export/root/
client
share -F nfs -o rw=client,root=client /export/swap/
client
```

Problème : Le serveur de SE ne répond pas aux requêtes RARP du client sans disque

Solution : À partir du serveur de SE souhaité du client, exécutez la commande snoop en tant que superutilisateur (root) à l'aide de l'adresse Ethernet du client :

# snoop xx:xx:xx:xx:xx:xx

Problème : Le programme d'initialisation se télécharge mais une erreur grave se produit au début du processus

Solution : Utilisez la commande snoop pour vérifier si le serveur de SE souhaité répond aux requêtes TFTP et NFS du client.

Problème : Le client sans disque se bloque.

Solution : Redémarrez les démons suivants sur le serveur de SE :

# /usr/sbin/rpc.bootparamd
# /usr/sbin/in.rarpd -a

Problème : Un serveur incorrect répond aux requêtes RARP du client sans disque

Solution : Redémarrez les démons suivants sur le serveur de SE :

# /usr/sbin/rpc.bootparamd
# svcadm enable network/rarp

Ignorer les liens de navigation
Quitter l'aperu
	Guide d'administration système : administration de base