Anda di halaman 1dari 56

Módulo 13: Detección de problemas en el sistema operativo

Índice

Descripción general ................................................................................................................................2


13.1 Identificación y Localización de Síntomas y Problemas ....................................................3
13.1.1 Problemas de Hardware ..................................................................................................3
13.1.2 Problemas del Kernel.......................................................................................................4
13.1.3 Software de aplicaciones ................................................................................................5
13.1.4 Configuración ....................................................................................................................6
13.1.5 Error del usuario ...............................................................................................................7
13.1.6 Uso de utilidades del sistema y uso de herramientas de estado del sistema.......8
13.1.7 Programas y procesos que no responden.................................................................12
13.1.8 Cuándo iniciar, detener o reiniciar un proceso ...............................................................12
13.1.8 Solución de problemas persistentes...........................................................................13
13.1.9 Examen de los archivos log..........................................................................................14
13.1.10 El comando dmesg ....................................................................................................17
13.1.11 Detección de problemas basándose en el feedback del usuario ......................18
13.2 Errores de Arranque de LILO.................................................................................................21
13.2.1 Códigos de error .............................................................................................................21
13.2.2 Arranque de un sistema Linux sin LILO .....................................................................24
13.2.3 Sistema de arranque de emergencia...........................................................................25
13.2.4 Uso de un disco de arranque de emergencia en Linux ...........................................26
13.3 Reconocimiento de Errores Comunes .................................................................................33
13.3.1 Diversas razones para los problemas de dependencia de los paquetes .............33
13.3.2 Soluciones a problemas de dependencia de paquetes ...........................................34
13.3.3 Errores de backup y restauración ...............................................................................39
13.3.4 Fallos de aplicaciones en servidores Linux...............................................................41
13.4 Detección y Resolución de Problemas de Red ..................................................................43
13.4.1 Pérdida de conectividad ................................................................................................43
13.4.2 Error del operador ..........................................................................................................44
13.4.3 Uso de utilidades TCP/IP ...............................................................................................46
13.4.4 Directrices para resolver problemas ...........................................................................52
13.4.5 Herramientas de diagnóstico de Windows 2000 .......................................................53
Resumen .................................................................................................................................................56

1
Módulo 13: Detección de problemas en el sistema operativo

Descripción general

Detectar y resolver problemas en un sistema que ha manifestado algún nivel de fallo puede ser uno
de los trabajos más estresantes en informática. Cuando la oficina IT central de una compañía
grande llama por teléfono a un administrador de sistemas a las 3:00 de la mañana para quejarse
por conectividad de networking perdida, nadie está contento. También es un problema cuando un
vicepresidente corporativo no puede imprimir el informe en el que ha venido trabajando por
semanas a tiempo para una reunión a las 7:00 de la mañana en un desayuno con el CEO. Todas
las partes no desean más que resolver el problema eficaz y rápidamente.

Los administradores de sistemas experimentados confían en una metodología probada y


sistematizada para resolver problemas del sistema. Deben poder reconocer condiciones de error
comunes y conocer sus causas usuales. Deben aprender a evaluar síntomas de manera tal que
puedan aislar su probable origen. Luego es necesario aplicar su experiencia en conocer qué clase
de pruebas ejecutar y qué avenidas explorar para verificar hipótesis relativas al problema, o reunir
más datos. Necesitan saber qué hacer para arreglar el problema, o adónde dirigirse para obtener
asistencia rápidamente, luego seguir adelante y hacerlo. Deberán documentar lo que aprenden por
el camino para hacer más fácil atacar cualquier recurrencia del problema. Finalmente, necesitan
educar a los usuarios de manera que se evite que el problema vuelva a ocurrir, o al menos
permitirles proporcionar feedback significativo si lo hace.

2
Módulo 13: Detección de problemas en el sistema operativo

13.1 Identificación y Localización de Síntomas y Problemas

13.1.1 Problemas de Hardware

Cuando un usuario afligido experimenta problemas de sistema, no es suficiente para él o ella


lamentarse, "¡Esta computadora no funciona!" El problema puede ser real, y las emociones
expresadas sobre él ser sinceras, pero no se ha proporcionado la suficiente información para
permitir al técnico que la arregla saber por dónde empezar.

Aunque unos pocos problemas se deben a una combinación de factores, la mayoría puede aislarse
en uno de los siguientes orígenes:

• Hardware Un componente de hardware del sistema ha funcionado mal, o se lo espera


pero no está presente.
• Kernel Un bug o falta de funcionalidad en el kernel del sistema a veces causa problemas
de origen ambiguo.
• Software de aplicaciones El software de aplicaciones o utilidades de comandos a nivel
del usuario pueden comportarse extrañamente, o simplemente colapsarse.
• Configuración Los servicios del sistema o el software de aplicaciones puede estar mal
configurado.
• Error del usuario Una de las más frecuentes fuentes de condiciones de error es causada
por usuarios de computadoras intentando hacer algo de la manera equivocada.

Cada tipo de condición de error puede categorizarse de una de dos maneras, consistente o
inconsistente. Un problema consistente es uno que de forma demostrable y positivamente ocurre
una y otra vez. Los problemas inconsistentes son aquéllos que ocurren sólo esporádicamente, o
bajo condiciones indeterminadas.

El último tipo es mucho más difícil de atacar, porque factores desconocidos causan el problema.
Antes de poder encontrar una solución, es necesario tener una clara definición de todas las
condiciones que pueden estar relacionadas. Por ejemplo, si el usuario de una pieza de software de
oficina selecciona una opción del menú y el programa se cae cada vez, dejando una extracción del
núcleo, se trata de un problema reproducible. Por otro lado, si el usuario selecciona esa opción y a
veces funciona, mientras que otras se cae, eso sugiere que algo desconocido podría estar
involucrado acerca del camino que tomó el usuario para llegar a ese estado. Es necesaria más
información para ver qué más podría haber hecho que puede haber causado el problema.

Algunos errores de hardware serán obvios. Si una unidad de disco comienza a sacudirse o deja de
escucharse en absoluto, si se detecta humo, o las luces del equipo no se están encendiendo como
lo hacen normalmente, es probable que haya un problema del dispositivo físico. Si un trabajo de
impresión en una impresora que ha estado funcionando bien resulta desteñido, en blanco, o con
colores extraños, la impresora podría necesitar un nuevo cartucho, no diferente software de
controladores.

Otro hardware deja rastros que el kernel detecta y registra. Suponiendo que un error es tal que no
hace caer el sistema, podría quedar evidencia en el archivo log /var/log/messages, con el
mensaje prefijado por la palabra oops. Un ejemplo de este archivo log se muestra en la Figura .
La presencia de tal mensaje no es necesariamente un error de hardware, aunque existe la
posibilidad.

Es importante comprender lo que está localizado dentro del directorio /dev al tratar cómo detectar
problemas de hardware en Linux. El directorio /dev contiene archivos especiales conocidos como
archivos de dispositivos, que se usan para acceder a todos los tipos diferentes de hardware de un

3
Módulo 13: Detección de problemas en el sistema operativo

sistema Linux. Por ejemplo, el archivo /dev/mouse es para leer entradas del mouse. Organizando
el acceso a los dispositivos de hardware de esta manera, Linux eficazmente hace parecer la
interfaz de un dispositivo de hardware como cualquier otra pieza de software. El directorio /dev es
un buen lugar para empezar a mirar al detectar problemas de hardware.

13.1.2 Problemas del Kernel

Los kernels Linux lanzados son considerablemente estables, a menos que se usen versiones
experimentales o se hagan modificaciones individuales. Los módulos de kernel descargables se
consideran parte del kernel también, al menos durante el periodo durante el que se los descarga. A
veces éstos también pueden ocasionar dificultades. La buena noticia con respecto a los módulos
es que pueden desinstalarse y reemplazarse por versiones fijas mientras el sistema aún está
funcionando.

Los problemas con los módulos a menudo se identifican en el transcurso del uso de una aplicación
que los llama. Por ejemplo, si un usuario intenta reproducir un archivo de sonido que requiere un
módulo que no ha sido cargado, el kernel informará que el controlador o una función a la que llama
no está presente en la memoria y necesita cargarse.

4
Módulo 13: Detección de problemas en el sistema operativo

13.1.3 Software de aplicaciones

Los errores en paquetes de aplicaciones son más identificables por el hecho de que ocurren
solamente cuando se ejecuta la aplicación. Esto, en contraste a las condiciones de hardware o
kernel que afectan a todo el sistema. Algunas señales comunes de bugs en aplicaciones son el
fallo al ejecutar y la caída del programa.

Fallo al ejecutar
El programa no iniciará en absoluto, sugiriendo que su archivo principal podría no tener permiso
para su ejecución. O puede parecer iniciar, pero no inicializa enteramente, y se cierra o se queda a
mitad de camino, a veces con un mensaje de error mostrado en una ventana, en la línea de
comandos, o en un archivo log.

Caída del programa


Cuando un programa en ejecución se cae, usualmente lo hace sin guardar los datos o archivos en
los que está trabajando un usuario. A veces se registran mensajes de error en uno de los lugares
de costumbre. En otros momento queda un archivo del núcleo, lo cual es una señal definida de que
la aplicación en sí sufrió un fallo catastrófico. Un archivo del núcleo puede examinarlo con un
debugger alguien que conozca la aplicación y que tenga código fuente disponible. En situaciones
de emergencia, no obstante, los archivos del núcleo son generalmente de poco uso.

Una variante de este caso es un programa bloqueado. La aplicación sigue ejecutándose, pero no
procede hacia ningún sitio. Esto requiere que el proceso se elimine con kill desde una línea de

5
Módulo 13: Detección de problemas en el sistema operativo

comandos. A veces eliminarlo con señal 3 (SIGQUIT) hará que termine y deje una imagen de su
memoria en un archivo del núcleo. Este archivo puede enviarse al fabricante del software con una
descripción del problema en espera de obtener una respuesta y solución a largo plazo. La realidad
es, no obstante, que la mayoría de los fabricantes de software no responden a las necesidades de
usuarios desafortunados que han sido víctimas de su software fallido.

Algunas aplicaciones están diseñadas para mostrar una memoria al recibir ciertas señales, que
pueden ser informativas, a veces incluso sin la disponibilidad del código fuente.
Desafortunadamente, éste tiene que conocerse antes de que el problema surja.

Agotamiento de recursos
Los recursos del sistema se refieren principalmente al tiempo de la CPU, memoria, y espacio en
disco. Una aplicación puede consumir demasiada memoria del sistema y en última instancia
comenzar a intercambiar tanto que todo el sistema se ve afectado. Puede entrar en un bucle que
consume mucho espacio en el tiempo de la CPU. Puede comenzar a escribir archivos que se
hacen muy grandes y hacer que el sistema de archivos se quede sin espacio. Tal mal
comportamiento es generalmente un fallo de la aplicación, no del sistema.

Mal comportamiento específico de un programa


Algunos errores son causados por cosas que tienen que ver con la ejecución del programa en sí.
Por ejemplo, si un procesador de texto tiene una función que permite al usuario saltar hasta una
cierta página del documento, y se le indica que vaya a la página 999999999999 y se cae, a la
aplicación probablemente le falta código para verificar desbordes de enteros.

13.1.4 Configuración

6
Módulo 13: Detección de problemas en el sistema operativo

Muchos paquetes pueden y debe ajustarse para una instalación local antes de ser usados.
Simplemente instalar el software en el sistema no es suficiente. Los problemas de configuración
tienden a afectar a subsistemas enteros, como subsistemas de gráficos, impresión, o networking.
Por ejemplo, si una costosa terminal SVGA se conecta a una placa adaptadora gráfica de alta
potencia en un sistema de escritorio y muestra solamente los gráficos de baja resolución más
granulados, es probable que el subsistema de gráficos X esté mal configurado. Tal vez el programa
Xconfigurator necesite ejecutarse. Programas que dependen de servicios de networking son
particularmente responsables de causar problemas. Si el sistema se reinicia y un sistema de
archivos remoto que una vez estuvo presente no lo está, el primer lugar donde buscar es en el
archivo de configuración /etc/fstab para ver si se supone que el sistema de archivos se monte en
el momento del arranque. Un ejemplo del archivo /etc/fstab se muestra en la Figura . Si se está
enviando e-mail, pero mailq muestra que el correo saliente simplemente espera en una cola y
nunca sale del sistema, podría ser necesario investigar la configuración para el agente de
transporte de correo.

Allí donde un problema de configuración ocurre en software de aplicaciones, deberá determinarse


si ocurre en todo el sistema, o a solamente un usuario. La mayoría del software configurable
incluye archivos de configuración del sistema por defecto y permite a los usuarios individuales
personalizar el comportamiento del programa según sus gustos. Por ejemplo, si un navegador del
sistema funciona bien para todo el mundo excepto para un usuario que ve tanto el texto como el
fondo del mismo color. Es probable que esta persona haya estado experimentando con las
propiedades del navegador y puede necesitar un poco de asistencia para restaurar una
funcionalidad razonable.

13.1.5 Error del usuario

7
Módulo 13: Detección de problemas en el sistema operativo

Es perdonable cometer un error al usar un programa informático o ignorar la forma correcta de


hacer algo. Lo que es imperdonable es insistir en permanecer tozudamente así. Hay más para
conocer acerca de los detalles intrincados de operar casi cualquier paquete de software que lo que
los usuarios cotidianos jamás se preocupen o intenten aprender. A menos que un usuario tenga un
particular interés en un programa y una cantidad extra de tiempo para explorar funciones a las que
puede nunca dar uso, tendrá que conformarse con lo que funciona.

Por lo tanto es raramente una sorpresa cuando los usuarios se quedan atascados en el software o
simplemente encuentran que son incapaces de ir del punto A al punto B. Supongamos: "no puede
llegar allí desde aquí". A veces un poco de instrucción es todo lo necesario para ayudar a alguien a
superar un problema.

13.1.6 Uso de utilidades del sistema y uso de herramientas de estado del sistema

Los sistemas operativos Linux proporcionan diversas utilidades del sistema y herramientas de
estado del sistema. Estas herramientas son útiles para ayudar a identificar o diagnosticar ciertos
problemas del sistema operativo. Las siguientes utilidades devuelven información acerca de la
configuración actual del sistema y en algunos casos permiten cambiar la configuración si necesita
arreglarse. También es importante saber que estas utilidades son útiles a un grado que devolverán
información acerca de cómo el sistema o un archivo "deberían" configurarse, pero no proporcionan
información sobre qué archivo o configuración del sistema exactos están mal configurados.

8
Módulo 13: Detección de problemas en el sistema operativo

• setserial Esta utilidad proporciona información y configura opciones para los puertos serial
del sistema. Los puertos serial en un sistema Linux son por lo común /dev/ttyS0 y
/dev/ttyS1. Introduciendo el comando setserial -a /dev/ttyS0 en el shell, el sistema
devolverá información detallada incluyendo el tipo de hardware que está conectado al
puerto serial en particular, la velocidad del puerto, y los recursos de hardware usados por
el puerto. Un ejemplo de la salida del comando setserial -a /dev/ttyS0 se muestra en la
Figura .
• lpq Este comando ayuda a resolver problemas de impresión. El comando mostrará todos
los trabajos que están esperando para ser impresos. Es de ayuda porque puede usarse
para determinar si hay un problema en la cola de impresión, o determinar si el sistema
Linux no puede encontrar la impresora en absoluto. Si el trabajo de impresión que se envió
desaparece de la cola, hay algo mal en la cola de impresión. No obstante, si el trabajo de
impresión permanece en la cola entonces el problema más probable es que el sistema
tiene problemas para encontrar la impresora. Un ejemplo de la salida de este comando se
muestra en la Figura .
• ifconfig Esta utilidad y sus usos se tratarán en más detalle posteriormente en este
capítulo. No obstante, este comando puede introducirse en el shell para que devuelva la
configuración de interfaz de red actual del sistema. Este comando devolverá la dirección IP
actual del sistema, la máscara de subred, el gateway por defecto, el servidor DNS, el
servidor DHCP, la IRQ que usa la placa de red, etcétera. Un ejemplo de la salida del
comando ifconfig se muestra en la Figura .
• route Esta utilidad y sus usos también se tratarán en más detalle en este capítulo. Este
comando muestra o configura la información acerca del enrutamiento del sistema, que
utiliza para enviar información a direcciones IP en particular. Este comando puede ser útil
para obtener información que puede ser de ayuda en la resolución de problemas de
conectividad de red. Un ejemplo de la salida del comando route se muestra en la Figura .

Hay varios otros tipos de utilidades del sistema y herramientas de estado que pueden usarse para
examinar problemas en un sistema Linux que ya se han tratado a lo largo de este curso. Éstas
incluyen comandos como las utilidades para disco rígido du y df, el comando top, así como la
utilidad del sistema de archivos fsck.

9
Módulo 13: Detección de problemas en el sistema operativo

10
Módulo 13: Detección de problemas en el sistema operativo

11
Módulo 13: Detección de problemas en el sistema operativo

13.1.7 Programas y procesos que no responden

A veces hay programas o procesos que por diversas razones pueden no responder o "bloquearse".
A veces solamente el programa o proceso en sí se bloquea y otras veces pueden ocasionar que
todo el sistema deje de responder. Un método para identificar y localizar el programa que no
responde y resolver eficazmente el problema es eliminar o reiniciar el proceso o programa. Algunos
de los temas tratados en esta sección han sido tratados en otros capítulos, no obstante hay otras
consideraciones de resolución de problemas a tener en cuenta en el caso de programas y
procesos que no responden.

13.1.8 Cuándo iniciar, detener o reiniciar un proceso

Como se mencionó en capítulos anteriores, a veces es necesario terminar el proceso que no


responde a sus funciones normales. Cuando un proceso no responde puede realmente hacer
mucho daño a un sistema informático. Lo más importante, estos procesos "colgados" pueden
consumir todos los recursos del sistema tomando control del tiempo de la CPU. Eventualmente
estos procesos que no responden pueden hacer que todo el sistema se caiga si no se los trata
apropiadamente. Es importante estar seguros de que un proceso se ha bloqueado antes de
eliminarlo aunque parezca bloqueado, porque algunos procesos se cuelgan un breve tiempo
cuando están procesando datos. Otras razones por las cuales se necesita terminar procesos que

12
Módulo 13: Detección de problemas en el sistema operativo

no responden son si comienza a quedar fuera de control y está consumiendo espacio en disco,
memoria y RAM del sistema.

Lo más fácil para terminar un programa es usar el comando kill, Otros procesos necesitan
terminarse editando el script de inicio Sys V que se trató en el Capítulo 10. La razón por la cual
algunos programas y procesos necesitan detenerse editando el script de inicio Sys V en lugar de
simplemente usar el comando kill, es que, algunos programas usan otros archivos llamados
archivos de bloqueo. Los archivos de bloqueo indican que el programa está usando un recurso que
no debería. Si un programa se termina usando el comando kill, el archivo de bloqueo quedará y
cuando el programa se ejecute nuevamente, lo más probable es que falle. Si esto ocurriera, se
generará un mensaje de error. Los archivos log del sistema pueden verse para determinar la
presencia de un archivo de bloqueo. Si se muestra un mensaje de error, entonces se recomienda
verificar la documentación del programa para determinar dónde está almacenado el archivo de
bloqueo. Los archivos de bloqueo pueden simplemente borrarse y el problema se soluciona. Al
reiniciar un programa, servicio, o daemon lo mejor es consultar primero la documentación porque
diferentes programas tienen que reiniciarse de maneras diferentes. Algunos soportan el uso del
comando restart, algunos necesitan detenerse completamente y luego iniciarse otra vez, y
otros pueden simplemente releer sus archivos de configuración sin necesitar detenerse y volverse
a iniciar, o reiniciarse.

13.1.8 Solución de problemas persistentes

Programas que ocasionan problemas persistentes y necesitan reiniciarse constantemente podrían


generar llamadas para la resolución de problemas recurrentes. Esto usualmente significa que el
programa tiene algún problema o bug interno. Una de las primeras cosas que pueden hacerse es
verificar con el fabricante y ver si se ha lanzado alguna actualización o patches. Otro problema que
puede estar causando que un programa tenga problemas recurrentes es un problema de hardware.
Problemas con la CPU, la RAM, el motherboard, y otros componentes de hardware pueden causar
problemas para algunos programas. En algunos casos de un fallo de hardware todo el sistema o el
sistema de archivos del sistema operativo puede caerse.

La mejor forma de arreglar programas que se caen repetidamente es reemplazarlos con nuevo
software o con un tipo diferente de software que realice la misma tarea. El software reemplazante
puede no ser una opción o ni siquiera estar disponible, sin embargo. La solución a esto es mucho
más dificultosa. De ser posible, intente usar el software de manera diferente o si hay una tecla o
comando en particular que hace que el programa falle, deje de usarlos. La mayoría de las veces
habrá software de reemplazo disponible. Si se trata de un daemon que se cae regularmente intente
usar otros métodos para iniciarlo y ejecutarlo. Los diversos métodos para iniciar daemons en un
sistema Linux se describieron en el Capítulo 10.

13
Módulo 13: Detección de problemas en el sistema operativo

13.1.9 Examen de los archivos log

Los archivos log se mencionaron por primera vez y se introdujeron en la sección 11.4.4 del
Capítulo 11. Las diversas actividades de un servidor Linux, el kernel del sistema operativo, y las
utilidades del sistema se registran en archivos log. También se mencionó en la sección 11.4.4 del
Capítulo 11 que la mayoría de archivos log se localizan en el directorio /var/log o en un
subdirectorio. Algunos de los archivos log más importantes en un sistema Linux son los archivos
log /var/log/messages, /var/log/secure, y /var/log/syslog. La Figura muestra todos los archivos
log que están ubicados en el directorio /var/log. Examinar los archivos log puede ser de ayuda en
la identificación de varios problemas en un servidor Linux. Los archivos log del sistema pueden
usarse para monitorear cargas del sistema tales como cuántas páginas ha servido un servidor web.
También pueden verificar rupturas de la seguridad tales como intentos de intrusión, verificar que el
sistema esté funcionando apropiadamente, y anotar cualquier error que podría ser generado por el
software o los programas. Hay varios diferentes tipos de información que es bueno saber, que hará
de la identificación de problemas usando los archivos log algo un poco más fácil. Algunas de estas
cosas se enumeran a continuación.

Monitoreo de Cargas del Sistema


Los servidores están diseñados y construidos para aceptar solicitudes entrantes de otros usuarios
de la red de área local (LAN) o externamente de usuarios remotos o de Internet. El servidor
necesita estar construido de manera tal que pueda manipular estas solicitudes de manera eficiente.
Los archivos log pueden usarse para determinar qué solicitudes se están haciendo que podrían
hacer que el servidor se ralentice. Si el servidor recibe un gran incremento en la cantidad de
solicitudes entrantes o los archivos transferidos se incrementan en tamaño, entonces será
necesario tomar las medidas apropiadas para incrementar la capacidad del servidor para manejar
la carga. Esto podría incluir el agregado de otro servidor, router, o switch, en lugar de solamente

14
Módulo 13: Detección de problemas en el sistema operativo

mejorar un servidor existente. Tenga en cuenta que estos archivos log mantendrán un rastreo de
incrementos de carga solamente en los programas específicos del servidor. Esto significa que
solamente registrarán los eventos de los programas y servicios que se ejecutan en el servidor y no
cualquier problema ocasionado por un incremento en las demandas de la estación de trabajo. No
obstante, puede ser fácil determinar si las demandas de la estación de trabajo se incrementarán
porque un administrador del sistema sabría si los usuarios van a usar programas más intensivos en
materia de recursos.

Intentos de Intrusión y su Detección


Puede ser difícil detectar una intrusión a una red o servidor. Un examen apropiado de los archivos
log del sistema puede ayudar a descubrir cómo y dónde ocurrió la intrusión, así como qué cambios
hizo el atacante en el sistema o la red. Cuando una persona irrumpe en un sistema, intentará
modificar herramientas y utilidades del mismo. Esto afecta el desempeño o la confiabilidad. Los
intrusos pueden tan sólo borrar archivos importantes y borrar archivos log para hacer difícil
averiguar qué daño han hecho al sistema. Por esta razón es una buena idea monitorear
continuamente los archivos log para que cualquier cambio o entrada inusual llame la atención.

Funcionamiento Normal del Sistema


Los archivos log también pueden examinarse para asegurarse de que el sistema está funcionando
en un estado normal. Si hay algo mal en el sistema, la información de los archivos log puede
ayudar a identificar y eliminar posibles problemas. Por ejemplo, un sistema Linux puede estar
configurado como servidor DHCP en el cual es posible distribuir direcciones IP a estaciones de
trabajo cliente. Los archivos log pueden examinarse para ver si el servidor está recibiendo
solicitudes y está distribuyendo préstamos de direcciones IP. Si las solicitudes se están recibiendo
el problema puede reducirse a un problema del lado del cliente y no a un problema con el servidor.

Entradas Faltantes
Si a cualquiera de los archivos log le faltan entradas, esto puede indicar que algo en el servidor no
está funcionando apropiadamente o está mal configurado. Entradas faltantes en archivos log
también pueden indicar un problema en otro lugar que no sea el servidor. Por ejemplo, un servidor
de archivos está configurado para ejecutar Samba para que los clientes que usan Microsoft
Windows puedan acceder al servidor Linux, y Samba está configurado para registrar intentos de
acceso al servidor. Supongamos que el log se verifica después para ver quién está intentando
acceder al servidor y se descubre que faltan entradas. Estas entradas faltantes pueden indicar que
hay un error de configuración en el daemon Samba del servidor. También podría significar que hay
un problema externamente a la red con un router o firewall que está evitando el acceso. Lo cual
significa que el servidor podría no ser el problema en absoluto.

Mensajes de Error
Muchos de los archivos log de un sistema Linux contendrán diversos mensajes de error que
pueden usarse para ayudar a localizar e identificar cualquier problema o mala configuración del
servidor. Por ejemplo, un archivo log puede contener información sobre un error de autenticación.
Este mensaje de error sería de utilidad porque le indica a un administrador del sistema dónde
deberían comenzar los esfuerzos de detección de problemas. Muchos programas y utilidades del
servidor pueden configurarse para que registren información específica, lo cual puede ayudar
también en los esfuerzos de detección de problemas. Se recomienda consultar la documentación
de los programas en cuanto a las opciones de configuración que están disponibles porque pueden
variar dependiendo del programa en particular.

Uso de tail y head


Los comandos tail y head Linux pueden ser de ayuda para examinar archivos log del sistema.
Algunos archivos log contienen numerosas páginas de información y texto. Usando los comandos
tail y head es posible procesar solamente una parte del archivo log para mostrar solamente la
información o texto que se especifiquen, en lugar de todo el archivo log de una sola vez. Por
ejemplo, si deseara ver unas pocas líneas del principio o final del archivo log, usar el comando

15
Módulo 13: Detección de problemas en el sistema operativo

head enviaría las primeras 10 líneas y el comando tail enviaría las últimas 10 líneas a la salida
estándar.

También es posible manipular más allá la salida deseada usando las diversas opciones del
comando. Visite las páginas man de los comandos tail y head para ver una lista más abarcativa de
las opciones disponibles. Se puede cambiar la cantidad de líneas que estos comandos envían a su
salida estándar con la opción -n. Para instruir a head o tail que usen bytes en lugar de líneas se
usaría la opción -c en lugar de -n. Por ejemplo, para mostrar los primeros 200 caracteres del
archivo log, use el comando head -c 200 file, o use el comando -c 200 file para mostrar los últimos
200 caracteres. Otras opciones incluyen agregar una b (por bloques) después de 200, lo que
multiplicaría el valor por 512. De manera similar, k (por kilobytes) multiplica el número dado por
1024, y m (por megabytes) multiplica el número dado por 1048576 bytes.

Algunos archivos log continuarán procesando los datos y continuarán agregando datos mientras
está instruyendo a head o tail para que lean datos del archivo específico. Un ejemplo de esto
serían los archivos log para el servidor web Apache. Es enteramente posible que mientras se
intenta ver inicios de sesión exitosos o fallidos al sitio web los usuarios, al mismo tiempo, estarán
intentando acceder al sitio web. Usar la opción -f le indica a tail que siga leyendo los datos del
archivo especificado y alimente esos datos a su propia salida estándar. Esta opción es perfecta
para monitorear logs del sistema. Por ejemplo, tail -f /var/log/access.log ejecutado en una ventana
terminal separada, seguirá imprimiendo nuevas entradas de inicio de sesión de acceso a Apache a
medida que son agregadas después de cada intento hasta que lo detiene con Ctrl-C.

Examinar archivos log puede ser útil para identiifcar diversos problemas como problemas en el
kernel, aplicaciones, configuración y también problemas del usuario. Los archivos log pueden ser
de mucha ayuda al intentar identificar y localizar problemas de software con el kernel, servidor,
herramientas de inicio de sesión del usuario, y otras utilidades del sistema.

16
Módulo 13: Detección de problemas en el sistema operativo

13.1.10 El comando dmesg

Parte de la información más importante y de más ayuda registrada en los archivos log que puede
ser útil para detectar e identificar problemas son los mensajes de inicio del kernel. Estos mensajes
pueden ser de particular ayuda al identificar problemas de hardware y del kernel. El comando
dmesg puede usarse para mostrar los mensajes recientes del kernel, también conocidos como
buffer anillo del kernel. Un ejemplo de la salida de este comando se muestra en la Figura . Note
que cuando el sistema arranca y Linux está comenzando a cargarse, una serie de mensajes del
buffer anillo del kernel se deslizan por la pantalla a medida que el sistema está inicializando los
dispositivos y servicios. Estos mensajes contienen información importante acerca del hardware
instalado en el sistema y los controladores. La información de estos mensajes se relaciona con si
los controladores se están cargando exitosamente y qué dispositivos están controlando los
controladores, como controladores [controllers] EIDE o SCSI, por ejemplo.

Hay diversas instancias en las cuales el comando dmesg puede ser muy útil. Pensemos en un
servidor que contiene dos placas Ethernet, una de las cuales no están funcionando. Tipeando el
comando, dmesg | less, después del inicio del sistema puede verse información acerca de las
dos placas Ethernet que están instaladas en el sistema. Mirando los mensajes del kernel en el
archivo log puede determinarse si hay una entrada para la placa no funcional o no. Si no hay una
entrada para la placa, el problema podría ser que el controlador no se está cargando o podría ser
el controlador equivocado para la placa. Si hay una entrada para la placa pero aún así no funciona,
el problema reside en algún lugar de la configuración de red de la placa. Use variables con el
comando dmesg para reducir la cantidad de mensajes que se muestran. Por ejemplo, usando el
comando grep, se mostrarán solamente las líneas que pertenecen a la placa Ethernet no

17
Módulo 13: Detección de problemas en el sistema operativo

funcional. El comando usado para llevar a cabo esta operación sería dmesg | grep ethX,
donde X es el dispositivo Ethernet en cuestión.

La información contenida en dmesg es tan valiosa para un sistema Linux que la mayoría de las
distribuciones automáticamente envían la salida al archivo log /var/log/boot.messages . Si la
distribución no hace esto, puede arreglarse colocando la línea , /font> dmesg >
/var/log/boot.messages en el script /etc/rc.d/rc.local.

13.1.11 Detección de problemas basándose en el feedback del usuario

A veces la mejor forma de identificar un problema con una computadora es localizar a la persona
que usa el sistema más a menudo o la persona que usó el sistema cuando se informó acerca del
problema. No todos los usuarios tienen la capacidad de entregar apropiadamente la información
correcta acerca de cuál es el problema o qué estaban haciendo cuando comenzaron a
experimentarlo. Por lo tanto, cualquier información que se obtenga de los usuarios deberá usarse
como punto de partida pero se recomienda que el problema se investigue y reproduzca para
asegurarse de cuál es el problema. Muchos problemas que los usuarios informan provienen
simplemente de su falta de comprensión y conocimiento de cómo funcionan los sistemas
informáticos. Hay varios tipos diferentes de problemas que los usuarios reportan. Algunos de los
más comunes se describen en esta sección.

Problemas de Inicio de Sesión


Uno de los tipos más comunes de problemas de los cuales se quejan los usuarios es que no

18
Módulo 13: Detección de problemas en el sistema operativo

pueden iniciar sesión en el sistema. Frecuentemente cuando esto ocurre no se debe a que haya
ocurrido ningún problema sino más bien a que han olvidado su contraseña, la han tipeado
incorrectamente, o la contraseña ha expirado. Recuerde que las contraseñas de un sistema Linux
son sensibles al uso de mayúsculas y minúsculas. Si la contraseña ha expirado entonces es
necesario re-habilitarla, para que el usuario pueda cambiar la contraseña o una nueva pueda
asignarse.

Problemas de Permisos de Archivos


Los problemas de permisos de archivos no son tan comunes como los problemas de inicio de
sesión, no obstante podría haber un usuario que tenga problemas para acceder a un archivo
compartido. Éste no es normalmente un problema si el usuario trabaja con archivos en sus propios
directorios, pero sí puede serlo cuando los usuarios necesitan acceso a archivos en otros
directorios. En algunos casos, puede ser necesario explicar cómo funcionan los permisos del
sistema Linux para evitar estos tipos de problemas.

Problemas con Medios Removibles


Linux maneja los medios removibles de manera muy diferente a otros sistemas operativos, como
Windows. Los usuarios muy a menudo tendrán muchas quejas. Incluso aunque la interfaz GUI
puede hacer parecer que se puede acceder a medios removibles como disqueteras y CD-ROMs
simplemente insertando el medio y buscando los archivos, no puede hacerse. Aún tienen que
montarse y desmontarse. Es importante señalar esto a los usuarios y explicarles cómo usar
apropiadamente los comandos mount y umount. Por defecto solamente la cuenta superusuario
puede usar los comandos mount y umount. Puede ser una buena idea modificar el archivo
/etc/fstab para que los usuarios puedan montar y desmontar los medios removibles por sí
mismos. Un ejemplo del archivo /etc/fstab se muestra en la Figura . La disquetera puede
eyectarse sin desmontarla primero, lo cual puede conducir a archivos corrompidos. La mayoría de
los dispositivos, no obstante, como los CD-ROMs, se bloquearán para que no puedan eyectarse a
menos que hayan sido desmontados primero. Los otros tipos de medios que no pueden eyectarse
a menos que hayan sido desmontados pueden conducir a muchas llamadas de resolución de
problemas innecesarias a menos que se haya explicado a los usuarios cómo montar y desmontar
apropiadamente unidades de medios removibles.

Problemas con el E-mail


El e-mail deberá funcionar para los usuarios cuando ha sido configurado correctamente. Esto es
particularmente cierto si todo lo que el usuario tiene que hacer es extraer su correo del servidor
SMTP localmente. No obstante, si hay usuarios remotos podría ser una buena idea instruirlos
respecto a cómo configurar sus cuentas de correo para que éste pueda ser recuperado sin
problemas.

Errores en los Programas


Los usuarios informarán a menudo que un programa se cayó. La mejor opción es enfocar esto
caso por caso porque cada programa requerirá un diferente enfoque para resolver sus problemas.
Obtenga tanta información del usuario como sea posible en cuanto a cualquier mensaje de error
que puede haber aparecido o a qué estaba haciendo cuando el programa se cayó para recrear los
eventos que ocasionaron el error.

Problemas de Apagado
Linux siempre deberá apagarse usando el comando shutdown. Esto se explicó en capítulos
anteriores. No obstante, solamente el usuario raíz puede usar este comando. A los usuarios que
experimentan problemas al apagar debería mostrárseles cómo usar la opción de apagado de la
GUI que permitirá el apagado del usuario no raíz de un sistema Linux. Es importante que los
usuarios sepan cómo apagar el sistema Linux apropiadamente porque un apagado inapropiado
puede ocasionar diversos problemas como procesos de inicio prolongados, seria corrupción de
archivos del sistema, y pérdida de datos. Si los usuarios se quejan de tales problemas puede
hacerse la sugerencia de que el sistema debe apagarse apropiadamente.

19
Módulo 13: Detección de problemas en el sistema operativo

20
Módulo 13: Detección de problemas en el sistema operativo

13.2 Errores de Arranque de LILO

13.2.1 Códigos de error

El cargador de arranque LILO fue mencionado por primera vez en el Capítulo 9, por lo cual debería
haber una firme comprensión de qué hace el cargador Linux (LILO) en un sistema Linux. El
cargador de arranque LILO es la primera pieza de código que toma control de proceso de arranque
desde el BIOS. Carga el kernel Linux, y luego cede el control enteramente al kernel Linux. Hay
muchas instancias que ocasionarán errores de arranque de LILO. El sistema BIOS para la mayoría
de las computadoras impulsadas por el procesador x86 fue diseñado en primer lugar para sistemas
en los cuales la capacidad del disco rígido era de meramente 40 MB. Para estos sistemas, los
programas y sistemas operativos de 32 bits o incluso de 64 bits que se están haciendo disponibles
eran cosa de fantasía y ciencia ficción. No obstante, hoy sabemos que la tecnología de hardware
de computadoras evolucionó a velocidades sorprendentes, y como resultado la tecnología BIOS ha
evolucionado también. Los cambios en la tecnología combinados con las necesidades de LILO
pueden desafortunadamente conducir a que LILO no funcione apropiadamente. Cuando LILO no
funciona correctamente puede ser frustrante porque usualmente significa que el sistema no
arrancará. Los mensajes de error o códigos que produce LILO pueden ser difíciles de interpretar.
Comprender cómo arreglar y sortear estos problemas puede ayudar a reparar el error de LILO y
regresar el sistema a un orden funcional. Es importante que se comprenda cómo se instala y
configura LILO antes de proceder con esta sección, así que podría ser una buena idea repasar la
sección en particular del Capítulo 9. También es importante mencionar que incluso aunque otros
cargadores de arranque pueden usarse para arrancar Linux, LILO se trata aquí porque es el que se
usa en los sistemas x86. Éstos son los sistemas que se usarán en este curso y es el cargador de
arranque que se instala en este curso. LILO no se usa en sistemas procesadores no x86.

El primer paso en la comprensión de los errores de arranque de LILO es poder comprender e


interpretar los diversos códigos de error de LILO que pueden generarse. Cuando hay un problema
con LILO, se mostrará un código de error. Algunos de los diversos códigos de error que pueden
mostrarse se enumeran y explican abajo.

• Ninguno
• L código-error
• LI
• LI101010…
• LIL-
• LIL?
• LILO

Ninguno
Si no hay ningún código de error esto significa que LILO no se ha cargado. Esto puede deberse a
que LILO no se instaló o puede haberse instalado en la ubicación equivocada. Verifique el archivo
/etc/lilo.conf y asegúrese de que la configuración sea correcta, luego use el comando lilo para
instalar LILO. Para obtener una mejor comprensión de qué significan las líneas del archivo
/etc/lilo.conf es una buena idea mirar la página man de lilo.conf, que también se muestra en la
Figura . LILO puede haber sido instalado en una partición diferente, en cuyo caso esa partición
en la que está instalado LILO deberá hacerse la partición de arranque. Todos estos tópicos se
tratan en el Capítulo 9.

L código-error
Esto significa que LILO ha comenzado a arrancar pero no puede arrancar el cargador de arranque
de la segunda etapa. El código-error generado es un número de dos dígitos que es generado por
el BIOS. Los códigos que estos números representan se detallan en la documentación de LILO. La
mayoría de los códigos de error representan fallos de hardware como un disco rígido defectuoso o

21
Módulo 13: Detección de problemas en el sistema operativo

una discrepancia en cómo LILO y el BIOS acuerdan tratar las direcciones de disco. Si el disco
rígido está defectuoso, tome las medidas apropiadas para confirmar si el disco rígido falló. Si las
configuraciones de LILO y el BIOS son diferentes en cómo tratan las direcciones de disco, haga los
cambios necesarios en el BIOS o en el archivo /etc/lilo.conf.

LI
Esto significa que LILO ha iniciado y los cargadores de la primera y segunda etapa se han cargado,
pero el cargador de la segunda etapa no funciona. Este tipo de código de error es usualmente el
resultado de los mismos síntomas que la condición L código-error.

LI101010…
Esto significa que LILO ha sido cargado y se está ejecutando apropiadamente pero no puede
localizar la imagen en el kernel. Este código de error usualmente se verá cuando un nuevo kernel
se ha cargado o actualizado y el comando lilo nunca se usó para reinstalar LILO.

LIL
Esto significa que los cargadores de la primera y segunda etapa han sido cargados exitosamente y
están funcionando de manera apropiada. No obstante, LILO es incapaz de leer la información que
necesita para funcionar. Este código de error es usualmente el resultado de algún fallo en el
hardware o incoincidencia en la geometría del disco entre LILO y el BIOS. Este problema puede
arreglarse configurando o corrigiendo la opción necesaria en /etc/lilo.conf o haciendo los cambios
necesarios en el BIOS. Un ejemplo del archivo /etc/lilo.conf se muestra en la Figura .

LIL?
Esto significa que el cargador de arranque de la segunda etapa ha sido cargado correctamente
pero se encuentra en una dirección incorrecta. Este problema puede ser ocasionado al mover
/boot/boot.b, que es el archivo cargador de arranque de la segunda etapa, sin usar el comando
lilo para reinstalar LILO o por una incoincidencia en la geometría del disco entre LILO y el BIOS.

LIL-
Esto significa que la tabla descriptora del disco (/boot/map) está corrompida. Este problema puede
ser ocasionado al mover /boot/map, que es el archivo del cargador de arranque de la segunda
etapa, sin usar el comando lilo para reinstalar LILO o por una incoincidencia en la geometría del
disco entre LILO y el BIOS.

LILO
Esto significa que LILO se ha cargado exitosamente y está funcionando. En este punto no debería
haber ningún problema con LILO que haga que el sistema no arranque. Si el sistema aún no
arranca apropiadamente en este punto, el problema reside en alguna otra parte, posiblemente en el
kernel, sus controladores o archivos de configuración del sistema.

Note que la mayoría de estos errores son el resultado de que LILO no puede leer archivos que han
sido modificados o movidos. Cualquier cambio en LILO que incluya el movimiento o cambio de
archivos debe seguirse por el comando lilo para reinstalar LILO para que cualquiera de los
cambios tenga efecto. Otros medios para arrancar Linux sin LILO se describen a continuación.

22
Módulo 13: Detección de problemas en el sistema operativo

23
Módulo 13: Detección de problemas en el sistema operativo

13.2.2 Arranque de un sistema Linux sin LILO

Podría haber algunos casos en los cuales LILO no puede usarse en absoluto para arrancar la
computadora porque ha fallado del todo. Cuando esto ocurre es necesaria otra forma de arrancar
el sistema. Hay unos pocos métodos por medio de los cuales es posible arrancar el sistema sin
LILO. Usar el Sistema de Arranque de Emergencia y usar un Disco de Arranque de Emergencia
para arrancar el sistema en lugar de LILO se tratan en las siguientes dos secciones. No obstante,
podría probarse primero algo más simple. Hay unas pocas opciones enumeradas a continuación
que pueden usarse.

• LOADLIN
• Kernel "en crudo" en un diskette
• LILO en un diskette

Estas opciones se tratan en más detalle en los siguientes párrafos.

LOADLIN
Ésta es una utilidad DOS que puede usarse para arrancar Linux. Esta utilidad usualmente viene
con los CDs de instalación y está ubicada en el directorio dosutils. Para usar LOADLIN use una
partición DOS o un disco de arranque DOS, una copia de LOADLIN.EXE, y una copia del kernel
Linux. Primero arranque DOS y luego tipee LOADLIN VMLINUZ root=/dev/rootdevice ro, donde
VMLINUZes el nombre del kernel y root=/dev/rootdevice es el nombre de la partición raíz como
/dev/hda1.

Kernel "en crudo" en un diskette


Es posible arrancar Linux si el kernel Linux "en crudo" está escrito en un diskette. Si se elige este
método, copie el kernel al diskette usando el comando dd if=vmlinuz of=/dev/fd0, donde
nuevamente vmlinuz es el nombre del kernel. Una vez que el kernel ha sido copiado al diskette,
simplemente inserte el diskette en la unidad y encienda la computadora. Asegúrese de que el BIOS
esté configurado para arrancar desde la disquetera. Hay otro paso necesario para confirmar que
esto funcione. Primero configure el kernel para que sepa la ubicación de la partición raíz. Para
hacerlo use el comando rdev /dev/fd0 /dev/dispositivoraíz, donde /dev/dispositivoraízes el
nombre de la partición raíz. Tenga en cuenta que estos discos parecerán no formateados en DOS
o Windows y no podrán montarse en Linux porque no tienen ningún sistema de archivos.

LILO en un diskette
Éste es uno de los métodos preferidos porque es el más rápido. Es mucho más rápido que usar el
método de LOADLIN o el método del kernel "en crudo" en un diskette porque el kernel aún está en
la computadora. Para poder instalar LILO en un diskette edite el archivo lilo.conf. La línea de
arranque en el archivo deberá cambiarse a boot=/dev/fd0. Después de esto, tipee lilo para que
LILO se reinstale. Tenga en cuenta que esta línea necesitará volver a editarse para instalar LILO
nuevamente en el disco rígido.

Hay algunas reglas generales e información extra que es de ayuda al usar estas técnicas para
arrancar un sistema Linux sin LILO. La técnica de LOADLIN es generalmente considerada como la
más flexible porque permite la creación o modificación de un disco de arranque usando DOS,
usando un kernel por defecto desde un CD de instalación Linux. El método de kernel "en crudo" en
un diskette es una técnica simple porque no requiere ninguna configuración para que sepa dónde
se ubica la partición de arranque. No obstante, si la configuración del sistema cambia
específicamente dónde está ubicada la partición de arranque del sistema, será necesario hacer
modificaciones en el kernel del diskette. Si esto no se hace el sistema no arrancará con la
configuración del disco. Usar el método de LILO en un diskette es el menos útil pero puede ayudar
en algunos casos. Por ejemplo, algunas personas prefieren configurar la partición de arranque para

24
Módulo 13: Detección de problemas en el sistema operativo

que arranque en un sistema operativo no Linux. Entonces cuando el sistema necesita arrancarse a
Linux todo lo que necesitan es insertar el diskette que tiene LILO en él. La Figura muestra un
ejemplo de la página de configuración de LILO que se presenta al usuario durante la instalación.
Desde esta pantalla un diskette de arranque LILO puede crearse que puede usarse para arrancar
Linux desde LILO usando el diskette.

13.2.3 Sistema de arranque de emergencia

Linux proporciona una copia del sistema de emergencia de LILO, que puede usarse para arrancar
Linux en el caso de que el cargador de arranque LILO tenga errores o no esté funcionando. Esto se
conoce como Sistema de Arranque de Emergencia. Para poder usar esta copia de LILO deben
efectuarse cambios en la configuración en lilo.conf. Los pasos a dar para hacer estos cambios son
los siguientes.

• Primero, cambie el lugar donde la partición raíz de los discos regulares está montada. Se
recomienda montarla en algún lado del sistema de arranque de emergencia como
/mnt/std. La Figura muestra un ejemplo de la pantalla de configuración de la GUI en la
cual se puede efectuar este procedimiento.
• Segundo, asegúrese de que el directorio /boot esté en su propia partición. Móntelo en
lugar de o además de la partición raíz.
• Los últimos cambios de configuración que necesitan hacerse son cambiar las imágenes del
kernel y otras opciones de arranque respecto a lo que es normal. Por ejemplo, las opciones
boot y root deberán señalar al disco rígido regular.

25
Módulo 13: Detección de problemas en el sistema operativo

Una vez completos estos pasos necesita usarse el comando lilo para volver a cargar LILO. Si todo
se configuró correctamente, el cargador de arranque deberá instalarse a sí mismo normalmente.
Es posible que esto no funcione. Si la versión de LILO que usa el sistema de emergencia es
diferente a la versión que está actualmente instalada en el sistema regular, la instalación de LILO
puede no funcionar. Si esto ocurriera use el método de LOADLIN, que se explica en la sección
anterior y luego reinstale LILO usando las herramientas regulares del sistema.

13.2.4 Uso de un disco de arranque de emergencia en Linux

Hay algunos otros casos en los cuales un sistema Linux no arrancará. Hay varias razones y errores
que pueden ocasionar que un sistema Linux no arranque, además de problemas de LILO. Por
ejemplo, el archivo /etc/fstab que se usa para mapear particiones al sistema de archivos pueden
estar corruptos. Errores del script de inicio pueden hacer que el sistema se bloquee o se apague en
ocasiones. Otras razones incluyen un fallo en el disco rígido y reemplazo del disco desde un
backup. Todos estos son errores comunes que aparecerán en un sistema Linux de tiempo en
tiempo, y LILO no es responsable. Para sortear estos tipos de problemas y arrancar exitosamente
el sistema obtenga o cree un Disco de Arranque de Emergencia. Un disco de arranque de
emergencia habilitará el sistema para que arranque sin usar ninguna parte de la partición principal.
Los discos de arranque de emergencia pueden ser un único diskette que contenga una cantidad
mínima de archivos del sistema con los cuales arrancar el sistema, o instalaciones Linux completas
que están almacenadas en medios removibles de alta capacidad como CD-ROMs. Un
administrador de sistemas debe saber cómo crear apropiadamente un disco de arranque de
emergencia para que puedan responder a las llamadas de resolución de problemas necesarias.

26
Módulo 13: Detección de problemas en el sistema operativo

También es importante saber qué herramientas están en el disco y cómo usarlas para resolver
problemas apropiadamente en un sistema Linux que no puede arrancar.

Búsqueda de un Disco de Emergencia


Hay varias opciones de las cuales escoger en lo que se refiere a buscar un disco de arranque de
emergencia ya preparado para Linux, la mayoría de los cuales están disponibles para descargar de
Internet. Los siguientes discos de arranque de emergencia de Linux son fáciles de usar y a menudo
no requieren configuración para usarlos. Algunos de los discos de arranque de emergencia más
populares disponibles para Linux se enumeran a continuación.

Los Discos de Instalación de Linux


Uno de los lugares más obvios para buscar es en los discos o medios de instalación que se usaron
para instalar el sistema operativo en primera instancia. La mayoría de las distribuciones incluyen un
sistema de disco de arranque de emergencia al que se puede tener acceso como opción al cargar
los medios de instalación. Por ejemplo, al iniciar el programa instalador para cargar Red Hat Linux,
el comando linux rescue se tipearía en el prompt lilo:. Si se usa una distribución diferente,
consulte la documentación relativa a cómo usar el disco de emergencia incluido con los medios de
instalación.

Disco Raíz/de Arranque de Tom


El nombre oficial para esta distribución de disco de emergencia es tomsrtbt, que significa "el
diskette de Tom, que tiene un sistema de archivos raíz y también es booteable". Éste puede
descargarse de Internet y puede entrar en un único diskette. Es un sistema Linux booteable
completo que solamente puede usarse desde la línea de comandos. La GUI no se soporta. Éste
viene en paquetes para DOS también. Para obtener una copia y averiguar más acerca del Disco
Raíz/de Arranque de Tom, diríjase a http://www.toms.net/rb.

ZipSlack
Esto está disponible para Slackware Linux. Puede instalarse en una partición pequeña o en una
unidad removible como un disco zip porque los 100 MB de tamaño de este disco de arranque de
emergencia es mayor que la capacidad de un diskette, que tiene solamente 1,4 MB. La ventaja de
tener una versión más grande de Linux que la que está disponible en un único diskette es que es
más fácil de personalizar con herramientas de backup comerciales y controladores para el kernel
personalizados.

Demo Linux
Ésta es una de las mejores utilidades de disco de arranque de emergencia disponibles porque es la
más completa. Es más grande que los 100 MB de ZipSlack y debe quemarse en un CD-R. El
archivo de 650 MB puede descargarse desde la web en http://www.demolinux.org. Ofrece una
versión completa de Linux con la cual trabajar que incluso permite que la X GUI se ejecute en la
mayor parte del hardware de video.

SuSE Evaluation
Ésta es muy similar a Demo Linux en que es de alrededor del mismo tamaño y debe quemarse en
un CD-R. No obstante, ésta es una versión de evaluación de SuSE Linux que puede descargarse
desde la web en http://www.suse.com.

Tenga en cuenta que éstas son solamente algunas de las opciones disponibles para discos de
arranque de emergencia de un sistema Linux. Para averiguar qué otras están disponibles diríjase a
http://www.linux.org/dist/english.html. Esta página y la página web para Raíz/Arranque de Tom
contienen otros vínculos para encontrar distribuciones pequeñas y especializadas para usar en
discos de arranque de emergencia.

27
Módulo 13: Detección de problemas en el sistema operativo

Creación de un Disco de Arranque de Emergencia


En su mayor parte, los discos de arranque de emergencia que se mencionan antes serán
suficientes para cualquier propósito. No obstante, hay algunos casos en los cuales será necesario
hacer un disco de arranque de emergencia personalizado. Por ejemplo, si el sistema en el cual se
trabaja contiene hardware que necesita controladores especiales, o usa un sistema de archivos
especial, funciones de networking especiales, o cualquier otra configuración que no se soportaría
normalmente en cualquiera de los discos de arranque de emergencia comunes, necesitarán un
disco de arranque personalizado.

La creación de un disco de arranque de emergencia personalizado puede ser una tarea fácil o
difícil dependiendo de los requisitos del sistema que necesita arrancarse y cómo se enfoca la tarea
de crear el disco. El método más simple y recomendado para crear un disco de arranque de
emergencia personalizado para adaptarse a las necesidades de un sistema informático individual
es modificar uno de los discos de arranque existentes. El disco existente puede modificarse de
modo tal que las funciones especiales que un sistema puede requerir puedan agregarse. El disco
de arranque ZipSlack es una de las mejores opciones a elegir al crear un disco de arranque de
emergencia personalizado. ZipSlack actúa de manera muy semejante a una distribución de Linux
regular, no obstante le faltan algunas funciones como una GUI. ZipSlack también permite a un
usuario recompilar su kernel, agregar cualquier herramienta necesaria, o configurar muchos otros
aspectos para adaptar al sistema Linux que necesita arrancarse. Otra función que hace de
ZipSlack una buena opción es que hay cierto espacio para hacerle adiciones en un disco Zip de
100 MB. También es posible sacar cualquier programa que no será necesario lo que libera un poco
más de espacio. Otra opción sería usar un disco de Zip de 250 MB para guardar ZipSlack en el
cual dejaría mucho espacio para cualquier programa adicional o cambios de configuración que sea
necesario efectuar.

No se recomienda el uso de ninguna de las otras opciones de discos de arranque de emergencia


para hacer un disco de arranque personalizado por diversas razones. El disco Raíz/de Arranque de
Tom es demasiado pequeño para ello. Con este disco de arranque de emergencia entrando en un
pequeño diskette de 1,4 MB, no hay mucho espacio para agregar nada o hacer ningún cambio.
Otro problema es que porque estas distribuciones son tan pequeñas, muchos de los archivos de
programa ya han sido cambiados para optimizarlos para esta pequeña cantidad de espacio. Esto
hace el cambiar o agregar cualquier cosa un proceso muy difícil porque es casi imposible hacerlo
sin exceder el tamaño máximo en el disco. Las distribuciones que pueden quemarse en un CD son
difíciles para crear un disco de emergencia personalizado debido al hecho de que no se pueden
hacer cambios en los archivos de un CD. Para hacer un disco de emergencia personalizado con
una de las distribuciones que se queman en un CD, el contenido debe copiarse en un disco rígido
de un sistema funcional, y luego los cambios deben efectuarse antesde quemar el CD nuevamente.

Herramientas de Recuperación
Independientemente del disco de arranque de emergencia que se use, hay varios tipos de
herramientas de recuperación que deberán incluirse que pueden ayudar en el proceso de
reparación. La siguiente lista de herramientas de recuperación es relativamente estándar y serán
programas de Linux familiares. Tenga en cuenta que en el caso de que el sistema en particular que
se está arrancando con el disco de arranque de emergencia puede haber algún programa especial
instalado o configuración que puede requerir una herramienta de recuperación especial además de
una que se nombre a continuación.

Controladores
Es importante recordar que los controladores para cualquier hardware y sistemas de archivos que
son soportados en el sistema Linux debe incluirse en el disco de arranque de emergencia. Puede
ser difícil incluirlos a todos en una de las distribuciones que encajan en un único diskette porque los
controladores tienden a consumir más espacio en disco que lo que se permite en un diskette.
Incluir controladores para el hardware y los sistemas de archivos soportados es importante porque
serán necesarios para usar o resolver problemas en cualquier pieza de hardware o el sistema de

28
Módulo 13: Detección de problemas en el sistema operativo

archivos después de arrancar el sistema con el disco de arranque de emergencia. Esto es


particularmente importante si el sistema tiene adaptadores SCSI y discos rígidos o algún otro
hardware inusual.

Un editor de textos
Es importante que alguna clase de editor de textos como vi se incluya para que los archivos de
configuración puedan verse y editarse apropiadamente. Cada distribución de disco de emergencia
deberá incluir un editor de textos y vi es una buena opción porque no es muy grande. Algunas de
las distribuciones más grandes de los discos de arranque de emergencia tienen editores de textos
más grandes de los cuales elegir.

Utilidades de Disco
El disco de arranque de emergencia deberá tener las utilidades de disco necesarias como fdisk,
mkfs, y fsck, que pueden usarse para formatear un disco rígido para poder instalar Linux en él.
Las Figuras , , y muestran ejemplos de estas tres utilidades. Un disco de arranque de
emergencia con estas utilidades puede ser valioso en el caso de un fallo en el sistema de archivos
o un problema en el cual el disco rígido o las particiones necesiten borrarse y prepararse para la
instalación de Linux. La utilidad fsck puede usarse para reparar sistemas de archivos dañados.

Software de Backup
Siempre es importante incluir alguna clase de utilidad de software de backup. Si un cambio o
reparación a algunos de los archivos de configuración necesita hacerse podría ser una buena idea
primero hacer un backup. La mayoría de las distribuciones mencionadas antes vienen con algún
tipo de utilidad de backup como tar, restore, cpio, y posiblemente otras. Las páginas man de estas
tres utilidades se muestran en las Figuras , , y . En el caso de que se use un software de
backup diferente, comercial o de terceros será necesario incluirlo en el disco de arranque de
emergencia.

Software de Red
Tener software o utilidades de red incluidos en el disco de arranque de emergencia es necesario si
necesita establecerse una conexión de red. Algunas redes tendrán datos almacenados a los que
puede accederse mediante una conexión de red y descargarlos del servidor puede restaurar los
datos. Tanto controladores serán necesarios para el hardware de red que está instalado en el
sistema como para el paquete de cliente o servidor de red.

Una última cosa que es importante mencionar acerca de arrancar un sistema con un disco de
arranque de emergencia es que algunos métodos de disco de recuperación requieren funciones
inusuales para acceder a disco de arranque en sí. Por ejemplo, si se está usando ZipSlack desde
una unidad zip, que está conectada mediante un puerto paralelo, debe arrancarse desde un kernel
almacenado en un diskette de arranque. Ese kernel debe incluir soporte para unidades zip
paralelas.

29
Módulo 13: Detección de problemas en el sistema operativo

30
Módulo 13: Detección de problemas en el sistema operativo

31
Módulo 13: Detección de problemas en el sistema operativo

32
Módulo 13: Detección de problemas en el sistema operativo

13.3 Reconocimiento de Errores Comunes

13.3.1 Diversas razones para los problemas de dependencia de los paquetes

Las dependencias de los paquetes se trataron en capítulos anteriores, por lo tanto ya hay una
comprensión del concepto. Cuando un paquete está instalado en un sistema Linux podría haber
otros paquetes que es necesario instalar para que ese paquete en particular funcione
apropiadamente. El paquete de dependencia puede tener ciertos archivos que necesitan estar en
su lugar o puede ejecutar ciertos servicios que necesitan iniciarse antes de que el paquete que ha
de instalarse pueda funcionar. En cualquier caso, este proceso usualmente se ejecuta sin
problemas. Linux a menudo notificará al usuario si está instalando un paquete que tiene
dependencias para poder instalarlas también. Hay algunas veces cuando este proceso no procede
como debiera y ocurren problemas. Usualmente el problema se relaciona con dependencias
insatisfechas o conflictos entre paquetes. Esto es más probable que ocurra al instalar paquetes de
diferentes fabricantes. Como administrador de sistemas, es importante comprender cómo
reconocer estos errores y saber cómo resolverlos apropiadamente.

Hay varias razones por las cuales dependencias y conflictos pueden surgir en un sistema Linux con
paquetes RPM, Debian y tarball. Solamente los paquetes RPM y Debian tienen la capacidad para
notificar al usuario sobre problemas de dependencia, tarballs no tiene esta capacidad. Unos pocos
ejemplos de eventos que pueden ocasionar problemas de dependencia y conflictos se enumeran a
continuación.

Librerías o programas de soporte faltantes


Este problema resulta ser uno de los tipos más comunes de problemas que son la causa de la
mayoría de los problemas de dependencia. Las librerías son un tipo de código de soporte que
puede ser usado por muchos programas diferentes en un sistema Linux. Todos los diferentes
programas pueden usar las librerías como si fueran parte del programa en sí. Cuando o si las
librerías faltan, los programas instalados no funcionan. Los paquetes de soporte funcionan de
manera muy similar a las librerías. Por ejemplo, todos los programas de KDE se basan en un
programa de soporte llamado Qt, que es un programa de soporte sobre el cual están construidos
todos los programas de KDE. Si el paquete de soporte Qt no está instalado ningún paquete KDE
puede instalarse usando RPMs.

Librerías o programas de soporte incompatibles


Es importante comprender que hay diferentes versiones de las librerías y programas de soporte
disponibles. Estas diferentes versiones corresponden a las versiones actual y pasadas de
programas instalados. Si una librería o programa de soporte está instalado necesita ser la versión
actual que corresponde a los programas que se están ejecutando en el sistema Linux. Es posible
tener varias versiones de librerías y programas de soporte instalados, para permitir el soporte para
programas con requisitos competentes. Por ejemplo, si un programa requiere Qt 2.2, pero la
versión Qt 1.4 está instalada, entonces es necesario instalar la versión 2.2. Recuerde mantener la
versión 1.4 para que otros programas instalados todavía puedan ejecutarse.

Archivos o funciones duplicados


A veces dos paquetes diferentes incluirán los mismos archivos exactamente o un paquete que está
a punto de ser instalado incluirá archivos o funciones que pueden ya estar instalados en el sistema.
Cuando esto ocurre, puede causar ocasionalmente que los programas no funcionen correctamente.

Encontrar la causa exacta de un error de dependencia de un paquete puede ser difícil. Puede
haber un mensaje de error que se produce que puede ser útil al determinar qué paquete está
ocasionando el problema y a qué categoría pertenece el problema. A veces estos problemas no
causarán ningún daño pero algunos pueden ser muy reales y serios. Tener librerías y programas
de soporte faltantes puede hacer que varios programas fallen y hacer que el sistema no responda.
Al instalar paquetes RPM o Debian, el proceso de encontrar la causa exacta para el problema de

33
Módulo 13: Detección de problemas en el sistema operativo

dependencia del paquete puede ser un poco más fácil a causa del mensaje de error que se
produce.

Tarballs no produce ningún mensaje de error cuando se ha detectado un error de dependencia de


paquete. El problema solamente se verá cuando el sistema intenta ejecutar el programa. Por esta
razón, el problema puede manifestarse inmediatamente y producir un mensaje de que es incapaz
de localizar una librería o archivo específico. Pueden causar que los programas se caigan o no
respondan. Por esta razón, al instalar paquetes tarball, lo mejor es usar la opción "mantener-
archivos-antiguos" [keep-old-files] para que no se sobreescriban archivos existentes. Usar esta
opción permitirá al paquete ser desinstalado y restaurar el sistema a su condición de
funcionamiento original.

13.3.2 Soluciones a problemas de dependencia de paquetes

Ahora que los diversos errores que causan los problemas de dependencia de paquetes se han
identificado, es el momento de tratar los pasos a dar para proporcionar soluciones a problemas de
dependencia de paquetes. Hay varias formas de proporcionar una solución, no obstante la correcta
a tomar dependerá de la situación. Repase todas las posibilidades antes de tomar una decisión
acerca de qué enfoque adoptar ya que algunas soluciones funcionan mejor que otras. Algunas de
las soluciones posibles que se tratarán incluyen la instalación forzada, modificación del sistema
para que cumpla con la dependencia, reconstrucción del paquete del problema a partir del código
fuente, y encontrar una versión diferente del paquete problemático.

Instalación Forzada
Tal solución para resolver problemas de dependencia de paquetes es simplemente ignorar el

34
Módulo 13: Detección de problemas en el sistema operativo

mensaje de error e instalar el paquete por la fuerza de todos modos. Aunque puede ser arriesgado,
hay casos en que hacerlo es apropiado. Si el error está en un paquete en el cual el usuario ha
compilado manualmente el código fuente, puede forzarse la instalación. Para forzar la instalación
del paquete e ignorar dependencias fallidas con paquetes RPM, use el parámetro – nodeps Para
forzar la instalación sobre otros errores, como conflictos con paquetes RPM existentes, use el
parámetro –forcePor ejemplo, la sintaxis para estos parámetros se muestra en la Figura .

NOTA:

The xxxxxxxx.rpm representa a cualquier paquete rpm.

También es importante notar que estas opciones de parámetros serán levemente diferentes para
los paquetes Debian. Los paquetes Debian están identificados por dpkg en lugar de rpm. Al usar
paquetes Debian use los siguientes parámetros mostrados en la Figura para forzar la instalación
de paquetes.

NOTA:

Donde paquete es el nombre del paquete

Modificación del Sistema


El método correcto y recomendado para proporcionar soluciones a problemas de dependencia es
modificar el sistema para que tenga las dependencias necesarias para ejecutarse apropiadamente.
Por ejemplo, si el paquete que se está instalando requiere una librería o programa de soporte
actualizado entonces la versión actualizada debe instalarse. Si Qt 1.44 está actualmente instalado
y el paquete requiere Qt 2.2 entonces la versión actualizada debe instalarse. Localice la versión
actualizada en los CDs de instalación de la distribución si es ahí donde el paquete se está
instalando. El CD de instalación deberá tener librerías y programas de soporte actualizados que los
paquetes requieren para esa distribución. Todo lo que necesita hacerse es instalar las librerías y
programas de soporte desde el CD.

Hay unas pocas precauciones a tener en cuenta al adoptar este enfoque. Preste particular atención
a qué paquetes y modificaciones se están haciendo y asegúrese de que cualquier paquete y/o
actualización que esté instalado esté de hecho pensado para la versión de distribución particular
que se está usando. Por ejemplo, programas que usan librerías y paquetes de soporte para Red
Hat 6 no necesariamente funcionarán con las librerías y paquetes de soporte de Red Hat 7. Un
paquete que contiene actualizaciones para librerías y paquetes de soporte y se instala para una
distribución en particular tendrá determinados requisitos que lo hacen compatible solamente con
los programas de esa distribución específica. Si la distribución A (Red Hat 6) está actualmente en
ejecución, pero se instala una actualización que fue construida para la distribución B (Red Hat 7),
los programas producirán un mensaje de error enunciando los problemas de dependencia que
tienen en términos de los archivos, librerías y paquetes de soporte de la distribución B, cuando
realmente se están ejecutando en la distribución A. Las actualizaciones de la versión apropiada
pueden de hecho no estar disponibles para la distribución A, pero si la versión de la distribución B
de librerías y paquetes de soporte está instalada; puede haber conflictos con los otros paquetes
que ya están instalados en la distribución A. En algunos casos si las actualizaciones apropiadas no
están instaladas para la versión de la distribución correcta, en un principio no habrá problemas. No
obstante, podría haber problemas en el futuro cuando se instalen otros programas o cuando la
distribución particular de Linux que se está usando se actualice. Cuando ése es el caso, las
librerías y paquetes de soporte incorrectos que fueron actualizados ya no serán reconocidos y en
algunos casos ni siquiera se podrán actualizar a la versión de la nueva distribución.

Esto puede parecer un tanto confuso pero es realmente un concepto simple. En otras palabras, si
el sistema va a ser modificado de cualquier manera, como que las librerías y paquetes de soporte

35
Módulo 13: Detección de problemas en el sistema operativo

están siendo actualizados, entonces es necesario asegurarse de que las actualizaciones correctas
estén instaladas. Esto significa que si Red Hat 6 se está usando, las actualizaciones para Red Hat
6 son las que deberán usarse y no para otra versión de Red Hat, como Red Hat 7. En el caso de
que las actualizaciones no estén disponibles para la distribución que se está usando, podría ser
una mejor idea simplemente actualizar toda la versión de la distribución. Hacerlo aseguraría que
las actualizaciones necesarias estén instaladas.

Reconstrucción del Paquete Problemático a partir del Código Fuente


En algunos casos puede ser necesario reconstruir el paquete a partir del código fuente si aparecen
mensajes de error de dependencia. No obstante, es importante comprender que las condiciones de
dependencia que resultan de necesitar hacerlo en oposición a otras condiciones de dependencia
en las cuales no sería necesario reconstruir el paquete en sí. Por ejemplo, algunas dependencias
son el resultado de las librerías y paquetes de soporte que están actualmente instaladas en la
computadora, y no de los requisitos de los otros paquetes y software del sistema. Esto a menudo
resulta cuando el software de un sistema Linux se ha recompilado. Cuando el software se
recompila, esto hará que las dependencias para diversos programas cambien. Por lo tanto, es
mucho más fácil reconstruir el paquete a partir del código fuente para sobreponerse a este cambio
que lo que sería intentar instalar por la fuerza nuevos paquetes o modificar el sistema de cualquier
forma.

Es realmente un proceso bastante simple reconstruir un paquete RPM. Para reconstruir un RPM
llame al rpm mediante el comando – rebuild. La sintaxis del comando usado para reconstruir un
paquete RPM es como sigue.

Es posible reconstruir tarballs a partir del código fuente, no obstante es un proceso mucho más
difícil. En lugar de tener que ejecutar un comando simple como arriba, alrededor de diez diferentes
comandos tendrán que introducirse para configurar los scripts de compilación, el software tendrá
que recompilarse, y después el software puede instalarse. También habrá algunos archivos de
configuración que tendrá que editarse manualmente. Por esta razón es mejor no intentar hacer
esto con los paquetes tarball. En cualquier caso lea la documentación del paquete que viene con el
mismo para obtener más información acerca del paquete.

# rpm rebuild nombrepaquete-version.src.rpm

nombrepaquete-version.src.rpm es el nombre del RPM que es necesario reconstruir. Este comando


extrae el código fuente y ejecuta cualesquiera comandos sean necesarios para construir un nuevo
paquete o a veces varios paquetes. Dependiendo de la velocidad de la computadora y del tamaño
del paquete que se está reconstruyendo, el proceso para recompilar el paquete puede llevar de
unos segundos a unas horas. Una vez que el proceso está completo, habrá varios RPMs en forma
binaria ubicados en/usr/src/nombredist/RPMS/arch, donde nombredist es el código que
representa la distribución del sistema, como RedHat o OpenLinux. arch representa la arquitectura
de la CPU del sistema, como i386, i586, x86, o ppc. Una vez que estos archivos se han colocado
en/usr/src/nombredist/RPMS/arch, pueden moverse a cualquier ubicación y luego instalarse
como cualquier otro paquete RPM.

Otra cosa que es bueno saber si un paquete va a recompilarse para reconstruirlo es que será
necesario un compilador apropiado para el software. Esto vale para cualquier tipo de paquete que
se esté recompilando (RPM o Tarball). Usualmente el Compilador C de GNU (GCC) funcionará
bien. Algunos programas también necesitarán tener instalados los archivos de encabezado
apropiados instalados, para que recompilen apropiadamente. Éste es usualmente el caso para la
mayoría de los programas basados en X. Los archivos encabezado son archivos especiales que se
necesitan al compilar un programa para que el programa use las librerías y paquetes de soporte
correctos. En algunos casos varias librerías pueden instalarse en un sistema Linux y el programa
necesitará saber cuál se supone que use. Los paquetes de archivos encabezado pueden instalarse
como cualquier otro paquete, no obstante, es necesario que los archivos encabezado que se

36
Módulo 13: Detección de problemas en el sistema operativo

instalen coincidan con la librería que usa el programa compilado. Si las versiones del archivo
encabezado no coinciden con las versiones de la librería entonces no compilará o no funcionará
una vez compilado.

Reconstruir un programa o paquete a partir del código fuente no es el método más fácil y no
siempre funciona. Hay varias razones por las cuales el programa puede no funcionar una vez
compilado. Los archivos encabezado apropiados pueden faltar, o el compilador apropiado y otras
herramientas de desarrollo pueden ser los equivocados o faltar del todo. Otras veces el código
fuente se basa en funciones que no están presentes en las librerías que se instalan en el sistema.
Si cualquiera de estos problemas se identifican, aparece un mensaje de error cuando el sistema
está recompilando el paquete. Si esto ocurre la mejor idea es intentar por otro medio arreglar el
problema de dependencia.

Búsqueda de una Versión Diferente


La forma más fácil de arreglar problemas de dependencia de los paquetes es ubicar una versión
diferente del paquete que está causando los problemas. Otra opción es buscar una versión más
nueva del paquete. También es posible buscar una versión más antigua e incluso otra opción sería
usar la misma versión del paquete pero una construida para la distribución Linux específica que se
está usando. Para buscar otros paquetes que pueden sustituirse por alternativos visite RPM
Find(http://www.rpmfind.net) o el sitio de listado de paquetes de Debian en
(http://www.debian.org/distrib/packages). Estos dos sitios web pueden ser de ayuda en localizar
versiones alternativas de paquetes a usar. Otras ubicaciones a verificar están en los CDs de
Instalación y en el sitio Web o FTP de la distribución particular.

Esta opción usualmente funciona bien y es más fácil que reconstruir el paquete recompilando el
software. No obstante, un problema es que a veces el único paquete aceptable es el que no
funciona. El paquete puede contener características especiales que es necesario instalar o puede
ser un patch que tiene como objetivo arreglar bugs importantes del software, en cuyo caso sería
casi imposible hallar un reemplazo. Otras versiones podrían no estar disponibles, así que en este
punto puede ser mejor simplemente probar un software diferente.

37
Módulo 13: Detección de problemas en el sistema operativo

38
Módulo 13: Detección de problemas en el sistema operativo

13.3.3 Errores de backup y restauración

Otro tipo de error común que es importante poder reconocer y resolver eficazmente son los errores
de backup y restauración. Proporcionar una estrategia de backup confiable será una de las tareas
más importantes de cualquier administrador de sistemas. Sin un sistema de backup confiable, los
datos de la compañía podrían estar en riesgo de verse comprometidos en cualquier momento. Esto
no solamente incluye datos valiosos y a menudo irreemplazables y/o costoso tiempo de inactividad
del servidor o Internet, sino también robo o falla, e incluso error humano. Una cosa cierta es que
estos problemas no son completamente evitables. No obstante, con un estrecho y confiable
programa de backup y restauración implementado, estos problemas no son permanentes. Otra
cosa desafortunada e inevitable sobre los backups es que no son inmunes a los errores en sí. Es
importante comprender cómo identificar estos errores así como las soluciones a errores de backup
y restauración para que estén listos para usar en caso de que se necesiten los backups. También
es importante notar que el peor momento para descubrir que el plan de backup y restauración tiene
errores es cuando necesitan usarse en una situación crítica. Por esta razón siempre es buena idea
probar los procedimientos de backup y restauración antes de un caso real en el que sea necesario
usarlos.

Existen diversos métodos y tipos de medios disponibles para los procedimientos de backup y
restauración. Los backups a cinta son el tipo más común encontrado en un sistema Linux y otros
grandes entornos de servidores a causa de su facilidad de uso. Y pueden reutilizarse una cantidad
de veces hasta que se estropean. Por esta razón la mayoría de los problemas y soluciones de esta
sección se aplican a backups de cinta. Hay varias otras formas de hacer backup y restaurar los
datos como CD-R, CD-RW, DVD-R, DVD-RW, así como diversas tecnologías RAID que hacen
backup de los datos directamente a otros discos rígidos. Otra razón por la cual los backups de cinta
se usan a veces es porque las tecnologías RAID tienden a ser bastante caras. Los backups a cinta
proporcionan un medio confiable y costeable para proporcionar una solución de backup. La primera
cuestión a comprender acerca de los backups a cinta es que ahorrarán mucho tiempo y ayudarán a
evitar errores de backup y restauración y que los backups a cinta deberán reemplazarse después
de haber sido usados 100 veces. Esto evitará que se vuelvan poco confiables.

Los errores de Backup y Restauración pueden ocurrir en diferentes puntos. Algunos errores
ocurren cuando el sistema está realmente llevando a cabo el backup. Esto significa que el backup
del sistema puede ni siquiera funcionar. Otras veces los errores ocurren durante el proceso de
restauración cuando el sistema está intentando recuperar los datos. Algunos de los tipos más
comunes de problemas se enumeran a continuación.

Problemas con los Controladores


Como cualquier otra pieza de hardware del sistema, los dispositivos de backup necesitan tener los
controladores apropiados instalados. Sea cuidadoso acerca de los diversos problemas con los
controladores que se han tratado en este curso con los sistemas Linux. Usualmente el dispositivo
de backup a cinta EIDE/ATAPI o SCSI requerirá soporte de un controlador o adaptador de host. Si
los controladores están instalados como módulos entonces los controladores o el dispositivo
necesitan cargarse en la memoria cuando se lleva a cabo el backup, de otro modo el sistema será
incapaz de hacer cualquier backup.

Errores de Acceso a la Unidad de Cinta


Un dispositivo de backup a cinta usualmente usará los archivos /dev/ht0 o /dev/nst0 para
proporcionar acceso a la unidad de cinta. Un usuario raíz deberá poder usar estos archivos para
acceder al dispositivo de backup a cinta tanto para lectura como para escritura. Si por alguna razón
no puede accederse al dispositivo, probablemente haya un error en los archivos de dispositivo
usados o en los archivos de controladores que han sido cargados.

39
Módulo 13: Detección de problemas en el sistema operativo

Errores de Acceso a los Archivos


Los permisos de acceso a los archivos pueden ser algo complicado y los backups no son
diferentes. El tipo de backup que alguien puede hacer en un sistema Linux dependerá de qué tipo
de acceso a los archivos tiene. Por ejemplo, cualquier usuario podrá hacer backups de sus propios
archivos porque tendrá acceso tanto de lectura como de escritura a ellos. No obstante, para poder
hacer un backup de todo el sistema de archivos en la computadora una persona necesita tener
acceso de lectura completo a todos los archivos. Ésta es la razón por la cual la mayoría de los
backups se hacen como raíz. Un usuario no raíz que está haciendo un backup podrá hacerlo de la
mayoría de los archivos del sistema, pero no de los archivos de otras personas y ciertamente no de
archivos protegidos como /etc/shadow. Esto funciona de igual forma con la restauración de un
sistema. Para llevar a cabo una restauración de todo el sistema el usuario necesitará ser raíz
también porque necesitará tener acceso completo de lectura y escritura a todos los directorios que
se están restaurando. Solamente la cuenta raíz tendrá tales derechos de acceso a los archivos en
un sistema Linux.

Errores de los Medios


Uno de los peores tipos de errores de backup es cuando el medio real desarrolla errores. A veces
el backup a cinta, CD-R, DVD-R, o unidad de disco rígido secundaria reales se dañan y cualquier
intento por restaurar los datos no funcionará. Hay varias cosas que pueden dañar un backup a
cinta, CD, o disco rígido. Muchas veces el medio de backup se dañará cuando ha estado en
almacenamiento mucho tiempo. Éste es especialmente el caso cuando las condiciones
ambientales del cuarto de almacenamiento no son las apropiadas para un almacenamiento de
medios de backup apropiado. Una de las peores cosas para cualquier tipo de medio de backup es
un cuarto de almacenamiento que no tiene la regulación de temperatura o circulación de aire
apropiados para mantener el cuarto en una temperatura confortable. Otra idea a prueba de fallos
sería hacer un backup de los medios de backup, en caso de que un medio falle, habrá otro.

Errores de Archivos No Encontrados [Files not Found]


Éste es otro tipo de error que puede a veces estar asociado con hacer backup y restauración de
datos en un sistema Linux. En sistemas Linux, al restaurar los datos de los backups usando la
utilidad de línea de comandos tar, ésta a veces será incapaz de restaurar archivos específicos.
Esto se debe a que la utilidad de línea de comandos tar almacena archivos sin la / al comienzo, lo
que significa que al restaurar archivos con tar la / al comienzo no deberá incluirse al restaurar
archivos y directorios específicos. (Si se usa el parámetro -P (-rutas-absolutas) con tar, ésta hará
un backup de los archivos e incluirá la / al comienzo). Por esta razón se recomienda que el usuario
siempre se encuentre en el directorio raíz (/) al restaurar cualesquiera datos. Si el archivo que es
necesario restaurar no puede encontrarse pero ha sido incluido en el backup y está en el medio de
backup, entonces usar el parámetro -t (-list) con tar enumerará el contenido y permitirá una
búsqueda manual del archivo. Esto puede consumir mucho tiempo y si hay muchos archivos en el
medio de backup, llevará mucho tiempo hacer la búsqueda. Una alternativa sería usar una
herramienta de compresión y backup más sofisticada que tar que proporcione funciones
adicionales de búsqueda cuando un archivo necesite hallarse manualmente. Algunas de estas
funciones adicionales incluyen cosas como un índice de los archivos del medio de backup, junto
con otras funciones que permitirán restaurar solamente los archivos seleccionados, lo cual evitará
cosas como tipear mal el nombre de archivo y luego tener que buscar manualmente a través de un
backup entero sin encontrar el archivo.

Hay diversos tipos de errores que pueden ocurrir al hacer backup y restaurar un sistema
informático Linux. Estos errores pueden estar asociados con el proceso de backup en sí, el
hardware involucrado en el procedimiento de backup, o el medio de backup. Por esta razón es
importante que después de haber efectuado cualquier backup o restauración de datos el backup o
restauración se verifiquen también. En un sistema Linux es posible usar una opción de verificación
del tiempo de backup que llevará a cabo una verificación justo después de que los datos se han
llevado a backup. Es posible que durante esta verificación algunos archivos se devuelvan con
errores, pero pueden ser archivos que han cambiado legítimamente y por lo tanto el mensaje de

40
Módulo 13: Detección de problemas en el sistema operativo

error puede ignorarse. Muchos dispositivos de backup incluyen una opción de verificación que
verificará los datos inmediatamente después de haber sido reescritos. No obstante, aún es
importante correr una verificación completa después de haber realizado un backup de todos los
datos.

Otras técnicas de verificación incluyen comparar la información en la unidad o backup contra


cualquier información de resumen disponible. Por ejemplo, después de una restauración es
importante verificar que los mismos paquetes estén instalados como antes comparándolos con la
base de datos RPM. (Recuerde de capítulos anteriores que algunos administradores de paquetes
como Red Hat y Debian tienen bases de datos que almacenan información acerca de los paquetes
almacenados o instalados en un sistema Linux). Para ello, use el comando rpm -Va. Tenga en
cuenta que podría haber variaciones legítimas debidas al hecho de que algunos cambios pueden
haberse efectuado.

13.3.4 Fallos de aplicaciones en servidores Linux

Entre las muchas organizaciones que desarrollan normas para redes de computadoras, el Instituto
de Ingenieros Eléctricos y Electrónicos (IEEE) ha estado muy activo en la definición de normas
para LANs. A través de sus grupos de trabajo "802", que comenzaron a reunirse en febrero (mes 2)
de 1980 (el "80" de 802), el IEEE ha publicado normas para las LANs más ampliamente
implementadas. Éstas incluyen Ethernet Ethernet (802.3), Token Ring (802.5), redes de fibra óptica
(802.8), LANs inalámbricas (802.11), y otras. El IEEE también ha definido una norma para
proporcionar control de errores y control de flujo sobre diferentes tipos de LAN en su especificación
para el Control de Enlace Lógico (LLC, 802.2).

41
Módulo 13: Detección de problemas en el sistema operativo

Las normas para LANs del IEEE son ahora centrales para las LANs usadas hoy. Dispositivos como
las placas de interfaz de red (NICs) que se conforman a las normas IEEE permiten que equipos
construidos y vendidos por diferentes fabricantes interoperen en la misma LAN.

42
Módulo 13: Detección de problemas en el sistema operativo

13.4 Detección y Resolución de Problemas de Red

13.4.1 Pérdida de conectividad

A pesar de los mejores esfuerzos preventivos, es inevitable que un administrador encuentre


problemas en la red. Éstos van desde ralentizamientos graduales que molestan a los usuarios
hasta una completa pérdida de conectividad en toda la red que hace que el trabajo de miles de
empleados se detenga.

Todos los productos que se han tratado pueden usarse para detectar y resolver problemas de red.
Puesto que la mayoría de las redes modernas corren en TCP/IP, varias utilidades de detección y
resolución de problemas están disponibles en cada sistema Linux. Pueden usarse sin la necesidad
de adquirir, instalar y aprender un producto de administración de red complejo y costoso.

Esta sección trata algunos conceptos básicos de detección y resolución de problemas, cómo usar
los archivos log en la detección y resolución de problemas y las herramientas y utilidades TCP/IP
incluidas en la mayoría de las distribuciones de Linux. Esta sección también trata el uso de estas
herramientas en la detección y resolución de problemas de conectividad de red. Finalmente, se
proporcionan directrices detalladas para detectar y resolver problemas en la red, que pueden ser
usadas por un administrador de red para rastrear y resolver problemas de conectividad y
desempeño de la red.

El problema más básico del networking es la incapacidad de una computadora de comunicarse con
otra. La pérdida de conectividad puede estar relacionada con el hardware y/o software. La primera
regla de detectar y resolver problemas es verificar la conectividad física. Esta explicación simple
nunca debería pasarse por alto. Más de un profesional del networking ha pasado horas
reconfigurando protocolos, reinstalando software, e incluso reinstalando el sistema operativo,
solamente para descubrir que la razón por la cual la computadora no podía comunicarse a través
de la red era que el cable había sido desconectado de la NIC. Por lo tanto, antes de embarcarse en
una compleja misión de detección de problemas, asegúrese de que los cables estén
apropiadamente enchufados en ambos extremos, que el adaptador de red esté funcionando
verificando la luz de enlace de la NIC, que las luces de estado del hub estén encendidas, y que el
problema de comunicación no sea un simple mal funcionamiento del hardware.

43
Módulo 13: Detección de problemas en el sistema operativo

13.4.2 Error del operador

Otra causa común de problemas en la red es el error del operador. Tal vez la razón por la cual la
estación de trabajo no puede ver al resto de la red es que el usuario inició sesión en la máquina
local y no se conectó a la red. Asegúrese de que los usuarios estén usando el nombre de usuario y
contraseña correctos y de que sus cuentas no estén restringidas en una forma que evite que
puedan conectarse a la red. Por ejemplo, los tiempos de inicio de sesión podrían estar limitados a
horas de negocios en días de la semana, o el usuario podría estar restringido para iniciar sesión
solamente desde una estación de trabajo especificada.

NOTA:

Una de las razones más comunes por las cuales la contraseña de un usuario no funciona es
debido a la naturaleza sensible al uso de mayúsculas y minúsculas en la mayoría de los sistemas
operativos. Presionar accidentalmente la tecla Bloq Mayús antes de introducir la contraseña hará
que se la rechace.

Los problemas de hardware son relativamente fáciles de tratar una vez descubiertos. Los
problemas de software pueden ser mucho más difíciles de rastrear y remediar. La mala
configuración del software es un responsable común. Las configuraciones de software podrían
haber sido cambiadas por la rutina de instalación de un programa recientemente instalado, o el
usuario podría haber estado experimentando con las configuraciones. Archivos faltantes o
corruptos pueden causar problemas de muchos tipos, incluyendo problemas de conectividad de
red. Los usuarios accidentalmente o a propósito, borran archivos, y picos de energía o apagados

44
Módulo 13: Detección de problemas en el sistema operativo

abruptos de la computadora pueden dañar los datos de los archivos. Los virus también pueden
dañar archivos del sistema o datos del usuario.

Cualquiera sea el origen sospechado del problema, seguir un conjunto de pasos para cada caso de
resolución de problemas asegura que todas las bases queden cubiertas. Las siguientes secuencias
de pasos de detección de problemas se recomiendan para una resolución de problemas eficiente.
Aunque los primeros cuatro pasos podrían parecer de sentido común, muchos profesionales de red
saltean el paso 5, y pueden también no proporcionar feedback al usuario. La secuencia de pasos
de detección de problemas mostrados en la Sección 13.4.4 se recomiendan para una resolución de
problemas más eficiente. Una vez arreglado el problema, creen que el trabajo ha terminado. No
obstante, los últimos dos pasos son críticos en un entorno de networking.

Después de pasar dos días detectando un problema y finalmente resolviéndolo, olvidar los detalles
parecería imposible. Pero la vida de un administrador de red es una vida ocupada, y es probable
que cuando el mismo problema vuelva a ocurrir, tal vez un año después, lo único que cualquiera
recordará es que ocurrió antes y que el problema se resolvió de alguna manera. Documentar los
pasos de resolución del problema no sólo ahorrará tiempo en el futuro, sino que también evitará
mucha frustración.

Proporcionar feedback a los usuarios también es importante. Los usuarios deberán ser educados
cada vez que sea posible. Éste es un elemento clave en la prevención de problemas. El usuario
puede no parecer preocuparse por lo que estaba mal, una vez que ha sido arreglado. No obstante,
la mayoría de la gente aprecia la información, especialmente si esa información puede ayudar a
cambiar sus hábitos o permitirles comprender qué señales de problemas buscar e informar antes
de que el problema empeore. El feedback al usuario siempre deberá proporcionarse en un lenguaje
que sea apropiado para el conocimiento técnico del usuario.

NOTA:

El feedback siempre deberá incluir instrucciones para el usuario si el problema vuelve a ocurrir. Si
es una cuestión simple y el usuario puede corregirla, deberán proporcionarse instrucciones paso a
paso, preferentemente por escrito.

45
Módulo 13: Detección de problemas en el sistema operativo

13.4.3 Uso de utilidades TCP/IP

En las siguientes secciones, se examinan varias categorías de utilidades TCP/IP. Hay aquéllas que
prueban la conectividad, aquéllas usadas para configuración, y aquéllas que proporcionan
información que puede ser útil en detectar problemas de red.

Utilidades para Probar la Conectividad


El primer paso en detectar problemas en una conexión perdida es determinar si en realidad está
perdida. Usuarios de red menos experimentados pueden suponer rápidamente que son incapaces
de conectarse a un sitio Web en particular con sus navegadores, cuando el servidor del sitio en sí
puede estar caído.

La herramienta TCP/IP más común hallada en sistemas Linux, UNIX y Windows que se usa para
probar la conectividad a otra máquina es el comando ping.

ping y pathping
La utilidad ping significa Buscador de Paquetes en Internetwork [Packet Internetwork Groper].
Este comando es una utilidad simple que envía un mensaje llamado Solicitud de Eco a una
computadora de destino designada usando el Protocolo de Control de Mensajes de Internet
(ICMP). La computadora de destino responde enviando una Respuesta de Eco ICMP.

El primer paso para verificar un problema de conectividad sospechado es hacer ping al host. Si la
conexión a Internet podría ser el problema, un host confiable en Internet, como
http://www.yahoo.com, es un buen blanco para el ping. Si se recibe una respuesta, la conexión
física entre las dos computadoras está intacta y funcionando. La respuesta exitosa también

46
Módulo 13: Detección de problemas en el sistema operativo

significa que el sistema que llama puede llegar a Internet. La Figura muestra un ejemplo de
solicitud y respuesta ping.

El orden preferido en el cual ejecutar el test en TCP/IP es el que sigue.

1. Nombre del host El primer paso en verificar un problema de conectividad sospechado es


hacer ping al host. Esto imprime el nombre del servidor de red. Si se recibe una
respuesta, la conexión física entre las dos computadoras está intacta y funcionando.
2. ipconfig Imprime la configuración TCP/IP actual. Los sistemas Linux/UNIX usan el
comando ifconfig más que el ipconfig. Anote la dirección IP y máscara de subred del
servidor de red para una futura referencia. Si la dirección IP del gateway por defecto se
muestra, anótela también.
3. Ping 127.0.0.1 Haga ping a la dirección loopback para ver si TCP/IP está instalado
correctamente. Si aparece cualquier mensaje de error, es hora de eliminar y reinstalar el
protocolo TCP/IP en el servidor de red.
4. Ping a la propia dirección IP Esto prueba que TCP/IP puede comunicarse con el
adaptador de red del servidor de red. La dirección IP del servidor de red se muestra en la
salida del comando IPCONFIG.
5. Ping al gateway por defecto Esto prueba que el servidor de red puede comunicarse
desde la red a otro sistema de la red, en este caso el router. La dirección IP del gateway
por defecto o router se muestra en la salida del comando ipconfig.
6. Ping al host remoto Un host remoto es una computadora del otro lado del gateway por
defecto o router. Esto prueba que el router está haciendo su trabajo y envía el paquete
TCP/IP a un sistema informático del otro lado del router.
7. Ping al propio nombre IP Esto prueba que el servidor de red puede resolver su propio
nombre IP.
8. Ping al nombre IP del host remoto Esto prueba que el servidor DNS está funcionando y
resolviendo el nombre IP de host de una computadora remota.

El comando ping puede emitirse usando la dirección IP del nombre de host DNS de la
computadora de destino. La dirección IP deberá usarse para probar la conectividad. Si un ping por
dirección IP tiene éxito, pero un ping por nombre no lo tiene, esto indica un problema con el
servidor o la configuración de resolución de nombres (DNS). Tal problema podría ocurrir cuando a
la computadora del usuario se le asigna una dirección IP estática, en lugar de obtener una
mediante DHCP, pero no tiene un servidor DNS definido en el archivo /etc/resolv.conf. Cuando la
estación de trabajo es un cliente DHCP, el servidor DHCP usualmente asigna la dirección del
servidor DNS.

El término tiempo de ping se refiere a la cantidad de tiempo que transcurre entre el envío de la
Solicitud de Eco y la recepción de la Respuesta de Eco. Un tiempo de ping bajo indica una
conexión rápida.

ping también puede usarse para probar si la pila TCP/IP está apropiadamente instalada y
funcional en la computadora. Para llevar a cabo la prueba, haga ping a la dirección de loopback
127.0.0.1, a la cual se da el nombre de host localhost en el archivo /etc/hosts. Si se recibe una
respuesta, la pila está funcionando.

Una versión de línea de comandos de ping se incluye con las pilas TCP/IP de todos los sistemas
operativos Windows y con las distribuciones UNIX y Linux. En un servidor NetWare, se incluyen
dos versiones, que se cargan como NLMs (Módulos Cargables de Netware) en la consola del
servidor.

47
Módulo 13: Detección de problemas en el sistema operativo

Pathping se incluye con Windows 2000, pero no con Windows 9x o NT. Combina las funciones
de ping con aquéllas de tracert y proporciona información adicional que no muestra ninguna de
esas utilidades. Con pathping, es posible detectar qué routers están causando problemas en la
red y medir cuántos paquetes se pierden en un router en particular.

Rastreo de Rutas de Paquetes


Las utilidades de rastreo se usan para descubrir la ruta tomada por un paquete hasta llegar a su
destino. La forma usual de determinar el enrutamiento de paquetes en sistemas UNIX es el
comando traceroute. La Figura muestra salida común de traceroute en un sistema UNIX.

traceroute muestra todos los routers a través de los cuales el paquete pasa mientras viaja a
través de la red desde la computadora emisora hasta la computadora de destino. Esto puede ser
útil para determinar en qué punto la conectividad se pierde o ralentiza.

Utilidades de Configuración
Los problemas de conectividad a menudo resultan ser problemas de configuración. Tal vez la
dirección IP asignada a la computadora no se encuentre en el rango de subred correcto, o tal vez
la máscara de subred, el gateway por defecto, la dirección DNS, u otras piezas de información de
configuración se introdujeron incorrectamente. Si cualquiera de estas entradas está equivocada, o
se la borra accidentalmente, la computadora no puede comunicarse apropiadamente en una red
TCP/IP.

ifconfig
/sbin/ifconfig, estándar en todos los sistemas UNIX más modernos, permite la visualización y
el cambio de configuración de una interfaz de red, como una dirección IP, dirección de hardware,
dirección de broadcast, y máscara de subred asociadas a un dispositivo ethernet determinado.

netstat
La utilidad netstat puede usarse para detectar problemas en la actividad de red mostrando las
conexiones que se han efectuado hacia y desde el servidor. Usar el comando netstat mostrará
conexiones TCP activas, puertos en los cuales la computadora está escuchando, estadísticas
Ethernet, la tabla de enrutamiento IP, estadísticas IPv4 (para los protocolos IP, ICMP, TCP, y
UDP), y estadísticas IPv6 (para los protocolos IPv6, ICMPv6, TCP sobre IPv6, y UDP sobre IPv6).
Usada sin parámetros, netstat muestra todas las conexiones TCP activas. La página man de
netstat enumera todos los parámetros que pueden usarse.

netconfig
Linux incluye la utilidad /usr/sbin/netconfig que permite a un administrador seleccionar la
configuración IP DHCP, o especificar una dirección IP estática junto con la máscara de red,
gateway y servidor de nombres principal asociados.

lsof
Aunque no es estrictamente una utilidad de networking, lsof puede identificar recursos relativos al
networking y qué procesos pueden estar bloqueándolos. lsof (LiSt Open Files) enumera
información sobre archivos que son abiertos por procesos en ejecución. Un archivo abierto puede
ser un archivo regular, un directorio, un archivo especial de bloque, un archivo especial de carácter,
una referencia a texto en ejecución, una librería, un stream, o un archivo de red (socket de Internet,
archivo NFS o socket de dominio Linux/UNIX).

Windows NT y Windows 2000 - ipconfig


El comando ipconfig se usa en Windows NT y Windows 2000 para mostrar la dirección IP,
máscara de subred, y gateway por defecto para los cuales está configurado un adaptador de red.
Ver Figura para información más detallada, se usa el switch/all. La Figura muestra los
resultados del uso del comando ipconfig /all en un servidor Windows NT.

48
Módulo 13: Detección de problemas en el sistema operativo

Si la computadora se configura como cliente DHCP, dos switches adicionales pueden usarse con
ipconfig. El primero es /renew. Éste ocasiona la renovación del préstamo de la dirección IP. El
segundo es el switch /release, que hace que la dirección IP se libere para que el servidor DHCP
pueda reasignarla.

Otras Utilidades TCP/IP


Probar la conectividad y verificar la información de configuración son los usos más comunes de
TCP/IP al detectar problemas de red. No obstante, los sistemas UNIX incluyen herramientas
adicionales, mostradas en la Figura , que puede usarse para reunir información específica.

49
Módulo 13: Detección de problemas en el sistema operativo

50
Módulo 13: Detección de problemas en el sistema operativo

51
Módulo 13: Detección de problemas en el sistema operativo

13.4.4 Directrices para resolver problemas

Detectar y resolver problemas en una red requiere habilidades para resolver problemas. El uso de
un método estructurado para detectar, analizar y tratar cada problema a medida que se lo
encuentra incrementa la probabilidad de tener éxito. La detección de problemas deberá efectuarse
siempre paso a paso. Las buenas habilidades para resolver problemas no son específicas del
networking de computadoras. Consideremos la forma en que un doctor encara un problema médico
complejo o la forma en que un investigador resuelve un crimen. Independientemente del campo,
los pasos son similares.

Reunir información
Un médico toma una historia clínica y pide al paciente que describa los síntomas. Un detective de
la policía hace preguntas a víctimas y testigos. Ambos se basan en sus propias observaciones y
podrían tener que referirse a libros u otros expertos para investigar hechos específicos
involucrados en el caso. Un detector de problemas de red deberá aprender a escuchar cuando los
usuarios describen sus experiencias. Las buenas preguntas son una parte esencial de reunir la
información necesaria para diagnosticar el problema.

Analizar la información
Aquí es donde la experiencia y el conocimiento entran en juego. Las causas posibles más obvias
deberán eliminarse primero. Si un paciente se queja de un dolor de cabeza, el doctor no comienza
llevando a cabo cirugía cerebral, sino que primero considera los factores más simples a partir de
los cuales los síntomas pueden originarse. A medida que se eliminan posibilidades, la búsqueda se
estrecha.

52
Módulo 13: Detección de problemas en el sistema operativo

Formular e implementar un plan de "tratamiento"


Cree un plan para rectificar el problema. Todo plan deberá incluir un plan de contingencia, en caso
de que el primer intento no funcione. Proceda con el plan organizadamente. Intente solamente una
solución por vez.

Probar para verificar los resultados del tratamiento


Es esencial que el éxito de las acciones de resolución de problemas se confirme. Es también
importante verificar que la "cura" no tuviera efectos colaterales que ocasionaran problemas
adicionales o diferentes.

Documentarlo todo
Los detalles del problema y los pasos dados para corregirlo deberán registrarse, idealmente con
una copia por escrito archivada. Esta documentación del proceso de ensayo y error podría ahorrar
a un futuro administrador mucho tiempo.

Objetivos y prioridades realistas son críticos durante el proceso de resolución de problemas y


optimización de la red. Un análisis de costo-beneficio puede ayudar a determinar qué problemas
deberán tener precedencia. Los costos no son siempre monetarios. Aunque las prioridades pueden
depender de problemas incluyendo presupuestos, eficiencia, presiones de tiempo y fechas de
entrega, incluso la política interna pueden ser factores de costo. Detectar y resolver problemas es
uno de los trabajos más difíciles del administrador de red. Es también el área en la cual un buen
administrador prueba lo que vale y se gana tanto su salario como su título.

13.4.5 Herramientas de diagnóstico de Windows 2000

53
Módulo 13: Detección de problemas en el sistema operativo

Las herramientas de diagnóstico de red de Microsoft Windows 2000 Server incluyen Ipconfig,
Nbtstat, Netstat, Nslookup, Ping, y Tracert, que son similares a sus contrapartes de
Windows NT. Windows 2000 Server también incluye los comandos Netdiag y Pathping, que no
estaban disponibles en Windows NT Server.

Netdiag
El comando de Windows 2000 Server netdiag ejecuta un conjunto estándar de pruebas en la red
y genera un informe de los resultados. El comando netdiag de Windows 2000 Server no es parte
de la instalación estándar de Windows 2000 Server. Debe instalarse desde el CD-ROM de
Windows 2000 Server desde la carpeta Herramientas de Soporte. El comando netdiag de
Windows 2000 tiene una característica muy buena, puede usarse sin ningún indicador en absoluto
y llevará a cabo un conjunto completo de pruebas en la red. Un especialista en hardware de
servidores tan sólo necesita analizar la salida del comando netdiag buscando la palabra "Falló"
para encontrar posibles problemas de red. Incluso aunque el comando netdiag puede usarse sin
ningún indicador, varios están disponibles. Los indicadores que pueden usarse con el comando
netdiag de Windows 2000 Server son como sigue en la Figura .

pathping
El comando pathping de Windows 2000 Server es una combinación del comando ping y del
comando tracert. Los indicadores que pueden usarse con el comando pathping de Windows
2000 son como sigue en la Figura .

54
Módulo 13: Detección de problemas en el sistema operativo

55
Módulo 13: Detección de problemas en el sistema operativo

Resumen

Detectar y resolver problemas en cualquier sistema operativo puede a veces ser un proceso muy
difícil y llevar mucho tiempo. Usualmente involucra dar muchos pasos y diferentes tareas para
encontrar el problema. El primer lugar donde comenzar es aislar como causa del problema una de
tres categorías. Estas categorías son relativas al hardware, relativas al software, o relativas al
Usuario. El siguiente paso lógico sería hacer una serie de preguntas para descartar aún más
opciones en la búsqueda de la causa del problema. ¿Hay algún componente específico que parece
causar problemas? Después de descubrir cuáles son los síntomas, ¿cuál podría ser la causa del
problema con esos síntomas? Para responder a estas preguntas es importante tener un
conocimiento extensivo acerca de cómo funcionan los diversos componentes, cómo están
instalados, y cómo configurarlos apropiadamente para un sistema Linux. Responder a estas
preguntas también significa que es necesario conocer cómo funcionan los diversos componentes
del sistema cuando están funcionando apropiadamente así como inapropiadamente.

Este capítulo trata muchos de los problemas comunes e importantes que pueden surgir en un
sistema Linux. También trata diversos temas acerca de cómo identificar, diagnosticar y arreglar
estos problemas comunes e importantes. ALgunos de estos problemas que se tratan en este
capítulo son errores de arranque de LILO, problemas y procesos de inicio y apagado, y diversos
otros fallos de software y aplicaciones. Los síntomas y soluciones de todos estos problemas se
trataron eficazmente en este capítulo.

Este capítulo también describe las diversas herramientas y recursos que están disponibles para
ayudar a diagnosticar y proporcionar soluciones que son importantes tener al detectar y resolver
problemas en un sistema Linux. Por ejemplo, en este capítulo se trataron las diversas formas de
arrancar un sistema sin LILO. Además, los diversos comandos Linux que pueden ser útiles al hacer
el debugging de un sistema se mencionaron en este capítulo. En todo este capítulo y en este curso
entero también, diversos lugares donde ir y encontrar ayuda para resolver estos problemas se han
mencionado cuando es posible. Es imposible pensar que cualquier administrador de sistemas
tendrá la respuesta para cada problema que surge o que será capaz de arreglar todos los
problemas por su cuenta. Saber dónde encontrar ayuda para los problemas que no pueden
manejarse individualmente es importante porque incluso el más conocedor administrador de
sistemas se encontrará con problemas que no puede arreglar.

56