Resolución de problemas de clientes sin disco

En esta sección, se describen los problemas que se detectan en la gestión de clientes sin disco y las posibles soluciones.

Resolución de problemas de instalación de clientes sin disco

El comando smosservice add no instala ningún paquete designado ARCH=all en los sistemas de archivos root (/) o /usr. Por lo tanto, estos paquetes se omiten. No aparece ningún mensaje de advertencia o error. Debe agregar manualmente estos paquetes al servicio del SO de Oracle Solaris recién creado. Este comportamiento se da a partir del sistema operativo Solaris 2.1. Dicho comportamiento afecta a los clientes SPARC y x86. Tenga en cuenta que la lista de paquetes faltantes varía según la versión de Oracle Solaris que se esté ejecutando.

Cómo localizar e instalar paquetes `ARCH=all` faltantes

En este procedimiento, se muestra cómo localizar e instalar paquetes ARCH=all faltantes después de haber creado el servicio del SO de Oracle Solaris en el servidor. Los ejemplos que se brindan en este procedimiento corresponden al sistema operativo Solaris 10 6/06.

Localice todos los paquetes con el parámetro ARCH=all.
1. Cambie los directorios al directorio Product de los medios para la imagen de Oracle Solaris 10. Por ejemplo:
```
% cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
```
2. Enumere todos los paquetes en el archivo pkginfo que tienen el parámetro ARCH=all.
```
% grep -w ARCH=all */pkginfo
```
  Si aparece un mensaje de error que indica que la lista de argumentos es demasiado larga, alternativamente, puede ejecutar el siguiente comando para generar la lista:
```
% find . -name pkginfo -exec grep -w ARCH=all {} /dev/null \;
```
  Tenga en cuenta que la ejecución de este comando tarda más en producir resultados.
  La salida es similar a la siguiente:
```
./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
```
  La información que se proporciona en esta lista le permite determinar qué paquetes se instalan en el sistema de archivos /usr y qué paquetes se instalan en el sistema de archivos root (/).
3. Compruebe el valor del parámetro SUNW_PKGTYPE en la lista de paquetes que ha generado.
  Los paquetes que pertenecen al sistema de archivos /usr se designan como SUNW_PKGTYPE=usr en el archivo pkginfo. Los paquetes que pertenecen al sistema de archivos root (/) se designan como SUNW_PKGTYPE=root en el archivo pkginfo. En la salida anterior, todos los paquetes pertenecen al sistema de archivos /usr.
Conviértase en superusuario o asuma un rol similar.
Los roles incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Configuración de RBAC (mapa de tareas) de Guía de administración del sistema: servicios de seguridad.
Cree los archivos temporales de administración de la instalación.
Debe crear un archivo independiente de administración de la instalación para los paquetes que están instalados en el sistema de archivos root (/) y otro para los paquetes que están instalados en el sistema de archivos /usr.
- Para los paquetes ARCH=all que están instalados en el sistema de archivos /usr, cree el siguiente archivo temporal de administración de la instalación:
```
# 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
#
```
- Para los paquetes ARCH=all que están instalados en el sistema de archivos root (/), si existe alguno, cree el siguiente archivo temporal de administración de la instalación:
```
# 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
#
```
Instale los paquetes ARCH=all faltantes.
1. Si el directorio actual no es el directorio Product de los medios para la imagen de Oracle Solaris 10, cambie los directorios a ese directorio. Por ejemplo,
```
# cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
```
  Puede ejecutar el comando pwd para determinar el directorio actual.
2. Instale los paquetes ARCH=all faltantes en el sistema de archivos /usr.
```
# pkgadd -R /export/Solaris_10 -a /tmp/admin_usr -d `pwd` [ package-A package-B ...]
```
  Se pueden mostrar varios paquetes cuando se ejecuta el comando pkgadd.
3. Compruebe que los paquetes ARCH=all se hayan instalado.
```
# pkginfo -R /export/Solaris_10 [package-A package-B ...]
```
4. Instale los paquetes ARCH=all faltantes en el sistema de archivos root (/).
  Tenga en cuenta que es posible que no exista ninguno de estos paquetes.
```
# pkgadd -R /export/root/clone/Solaris_10/sun4u -a /tmp/admin_root -d `pwd` [ package-X package-Y ...]
```
5. Compruebe que los paquetes ARCH=all se hayan instalado.
```
# pkginfo -R /export/root/clone/Solaris_10/sun4u [ package-X package- ...]
```
Una vez que termine de agregar los paquetes ARCH=all faltantes, elimine el archivo temporal de administración de la instalación.
```
# rm /tmp/administration-file
```

Ejemplo 7-10 Localización e instalación de paquetes ARCH=all faltantes

En este ejemplo, se muestra cómo instalar el paquete ARCH=all, SUNWjdmk-base, en el sistema de archivos /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

Resolución de problemas generales de clientes sin disco

Esta sección muestra algunos problemas habituales que pueden surgir con los clientes sin disco y sus posibles soluciones.

Problema: El cliente sin disco dice Owner of the module /usr/lib/security/pam_unix_session.so.1 is not root (El propietario del módulo /usr/lib/security/pam_unix_session.so.1 no es root) cuando se intenta iniciar sesión. El sistema de archivos /usr es propiedad de nobody.

Solución: Para corregir el problema, siga esta solución:

Mediante un editor de texto, modifique el archivo server:/export/root/client/etc/default/nfs del cliente sin disco.

Cambie la línea #NFSMAPID_DOMAIN=domain a lo siguiente:

NFSMAPID_DOMAIN=the_same_value_as_in_server's_/var/run/nfs4_domain

Asegúrese de que el servidor del SO y el cliente sin disco tengan el mismo dominio nfsmapid. Para verificar esta información, revise el archivo /var/run/nfs4_domain.

Precaución - Si el archivo nfs4_domain del cliente sin disco contiene un valor diferente del valor del archivo /var/run/nfs4_domain del servidor del SO, no podrá iniciar sesión en el sistema después de que el cliente sin disco haya iniciado.

Reinicie el cliente sin disco.

Para obtener más información, consulte el Capítulo 3, NFS Tunable Parameters de Oracle Solaris Tunable Parameters Reference Manual y la página del comando man nfsmapid(1M).

Problema: El servidor del SO no puede realizar lo siguiente:

Responder a solicitudes RARP (Reverse Address Resolution Protocol) de clientes
Responder a solicitudes bootparam de clientes
Montar un sistema de archivos root (/) de clientes sin disco

Solución: Las siguientes soluciones se aplican en un entorno de archivos.

Compruebe que files aparezca como primera fuente para hosts, ethers y bootparams en el archivo /etc/nsswitch.conf, en el servidor del SO.
Compruebe que la dirección IP del cliente aparezca en el archivo /etc/inet/hosts.

Nota - Si no ejecuta al menos Solaris 10 8/07, también debe verificar que la dirección IP del cliente aparezca en el archivo /etc/inet/ipnodes.
En esta versión de Oracle Solaris, el archivo /etc/inet/hosts es un archivo único que contiene entradas IPv4 e IPv6. No es necesario mantener entradas de IPv4 en dos archivos hosts que siempre requieren sincronización. Para conseguir la compatibilidad con versiones anteriores, el archivo /etc/inet/ipnodes se ha reemplazado con un enlace simbólico, con el mismo nombre, con el archivo /etc/inet/hosts. Para obtener más información, consulte la página del comando man hosts(4).
Compruebe que la dirección Ethernet del cliente aparezca en el archivo /etc/ethers.
Compruebe que el archivo /etc/bootparams contenga las siguientes rutas a las áreas de intercambio y el directorio root (/) del cliente.
```
client root=os-server:/export/root/
client swap=os-server:
/export/swap/client 
```
El tamaño de intercambio varía según se especifique o no la opción -x tamaño_intercambio al agregar el cliente sin disco. Si especifica la opción -x volcado al agregar el cliente sin disco, aparece la línea siguiente.
```
dump=os-server:/export/dump/client
 dumpsize=512
```
El tamaño de volcado varía según se especifique o no la opción -x tamaño_volcado al agregar el cliente sin disco.
Compruebe que aparezca la dirección IP del servidor del SO en el archivo /export/root/cliente/etc/inet/hosts.

Problema: El servidor del SO no puede realizar lo siguiente:

Responder a solicitudes RARP de clientes
Responder a solicitudes bootparam de clientes
Montar un sistema de archivos root (/) de clientes sin disco

Solución: Las siguientes soluciones se aplican en un entorno de servicio de nombres.

Compruebe que la dirección Ethernet y la dirección IP del servidor del SO y del cliente estén asignadas correctamente.
Compruebe que el archivo /etc/bootparams contenga las rutas a las áreas de intercambio y el directorio root (/) del cliente.
```
client root=os-server:/export/
root/client swap=os-server:/export/
swap/client swapsize=24
```
El tamaño de intercambio varía según se especifique o no la opción -x tamaño_intercambio al agregar el cliente sin disco. Si especifica la opción -x volcado al agregar el cliente sin disco, aparece la línea siguiente:
```
dump=os-server:/export/dump/
client dumpsize=24
```
El tamaño de volcado varía según se especifique o no la opción -x tamaño_volcado al agregar el cliente sin disco.

Problema: El cliente sin disco entró en estado de alerta.

Solución: Verifique lo siguiente:

Que la dirección Ethernet del servidor del SO esté correctamente asignada a su dirección IP. Si movió físicamente un sistema de una red a otra, puede que haya se olvidado volver a asignar la nueva dirección IP del sistema.
Que el nombre de host del cliente, la dirección IP y la dirección Ethernet no existan en la base de datos de otro servidor en la misma subred que responda a las solicitudes RARP, TFTP (Trivial File Transfer Protocol) o bootparam del cliente. A menudo, los sistemas de prueba se configuran para instalar el sistema operativo desde un servidor de instalación. En estos casos, el servidor de instalación responde a la solicitud RARP o bootparam del cliente devolviendo una dirección IP incorrecta. Por esta dirección incorrecta, puede que se descargue un programa de inicio para una arquitectura inadecuada o que no se pueda montar el sistema de archivos root (/) del cliente.
Las solicitudes TFTP del cliente sin disco no reciben una respuesta de un servidor de instalación (o servidor del SO anterior) que transfiera un programa de inicio incorrecto. Si el programa de inicio es de una arquitectura diferente, el cliente entra en estado de alerta inmediatamente. Si el programa de inicio carga desde un servidor que no es de sistema operativo, puede que el cliente obtenga su partición root del servidor que no es de sistema operativo y su partición /usr partición del servidor del SO. En esta situación, el cliente entra en estado de alerta si las particiones root y /usr son de arquitecturas o versiones conflictivas.
Si utiliza tanto un servidor de instalación como un servidor del SO, verifique que la siguiente entrada exista en el archivo /etc/dfs/dfstab:
```
share -F nfs -o -ro 
/export/exec/Solaris_version- \
instruction-set.all/usr
```
Donde versión= 8, 9, 10 y conjunto_instrucciones=sparc o i386.

Que las particiones de root (/), /swap y /dump (si se especifica) del cliente sin disco tienen entradas compartidas:

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

En el servidor del SO, escriba el comando siguiente para verificar qué archivos se comparten:
```
% share
```
El servidor del SO debe compartir /export/root/cliente y /export/swap/nombre_cliente (valores predeterminados), o las particiones root, /swap y /dump que especificó cuando agregó el cliente sin disco.
Que las entradas siguientes existan en el archivo /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
```

Problema: El servidor del SO no responde a la solicitud RARP del cliente sin disco.

Solución: Desde el servidor del SO previsto del cliente, ejecute el comando snoop como superusuario (root) con la dirección Ethernet del cliente:

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

Problema: El programa de inicio descarga, pero entra en estado de alerta en una fase temprana del proceso.

Solución: Utilice el comando snoop para verificar que el servidor del SO esté respondiendo a las solicitudes TFTP y NFS del cliente.

Problema: El cliente sin disco se bloquea.

Solución: Reinicie los siguientes daemons en el servidor del SO:

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

Problema: Un servidor incorrecto responde a la solicitud RARP del cliente sin disco.

Solución: Reinicie los siguientes daemons en el servidor del SO:

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

Omitir V�nculos de navegaci�n
Salir de la Vista de impresi�n
	Guía de administración del sistema: administración básica