En uno de los sitios de mis clientes, el técnico local apagó su servidor Solaris 10 x86, desconectó las entradas de energía, lo movió y ahora no arranca correctamente. Se inicia y luego presenta un mensaje que le permite iniciar sesión. Esto parece ser un hito de usuario único (o equivalente).
Profundizando en ello, creo que SMF no permite que el sistema sea multiusuario. SMF estaba generando un montón de errores en autofs, después de jugar un poco con él, logré que generara errores en inetd y nfs/client. Todo esto me dice que el problema está en algún archivo de estado SMF o base de datos que necesita ser reparado/eliminado/recreado o algo así, pero no sé cuál es el problema real.
Por "generar errores", me refiero a que cada segundo recibo un mensaje en la consola que dice "Se agotó el tiempo de espera para la salida del método o servicio". Contrato de asesinato <#>”. Esto dificulta la interacción con la computadora.
La ejecución de svcs –xv muestra el servicio como "habilitado", en estado "deshabilitado", motivo por el cual "el método de inicio se está ejecutando". Hacer trampa con svcadm en el servicio no hace nada, excepto confirmar que el servicio no está en estado de Mantenimiento.
Los inicios de sesión /lib/svc/log/$SERVICE solo le indican que este bucle ha estado ocurriendo una vez por segundo. Los inicios de sesión en /etc/svc/volatile/$SERVICE confirman que en el arranque se intenta iniciar el servicio y se detiene inmediatamente, sin más entradas. Tenga en cuenta que el registro del sistema no se inicia porque el registro del sistema depende de autofs, por lo que no tengo syslog ni dmesg.
Buscar en Google todos estos términos termina diciéndome cómo depurar/arreglar autofs o nfs/client o inetd o rpc/gss (que era la dependencia que SMF estaba usando como excusa para evitar que nfs/client "inicie", afirmaba ese rpc/gss estaba “indefinido”, lo cual es incorrecto ya que todo esto solía funcionar. Lo volví a habilitar con inetadm, pero inetd aún no se inicia correctamente). Pero creo que el problema es SMF en general, no los servicios individuales.
Hacer un recovery_repository al “manifest_import” no hace nada para mejorar, o incluso cambiar de manera detectable, la situación. No utilicé una copia de seguridad de arranque porque los últimos arranques no fueron útiles.
Le dije al cliente que, dado que los directorios de datos valiosos están en un sistema de archivos separado (que fsck está limpio, por lo que está intacto), podríamos simplemente reinstalar Solaris 10 en la partición /. Pero parece una solución muy parecida a la de Windows para solucionar este problema.
Entonces. ¿Alguna idea de qué pieza está rota y cómo podría arreglarla?
Actualización 1: Probablemente debería mencionar que este sistema tiene dos sistemas de archivos, / y /export. Ambos fsck se limpian y se montan correctamente.
Respuesta1
Una causa común de este tipo de problema es un problema al montar sistemas de archivos debido a cierta corrupción del sistema de archivos. Esto se está volviendo bastante raro, especialmente para los locales, pero su cliente no puso las probabilidades de su lado al deshabilitar el registro ufs (que evita la mayoría de las corrupciones del sistema de archivos causadas por un apagado abrupto) y al no usar ZFS (que no puede ser corrupto en primer lugar por diseño).
Puede habilitar el inicio detallado de smf editando /boot/grub/menu.lst. La forma precisa depende de su versión y actualización de Solaris, pero generalmente esto se hace reemplazando console=graphicspor console=text -v -m verboseen la línea que carga el kernel.
Si desea comenzar en modo de usuario único, utilice console=text -v -m verbose,milestone=single-user.
Para habilitar el modo de depuración smf, useconsole=text -v -m debug
Tenga en cuenta que puede utilizar el modo de edición de grub para configurar temporalmente estas opciones.