eMartos

Sí, Linux también falla, pero a diferencia de Windows, se puede arreglar. Además, en favor de Linux, debo decir que no parece un error de software, sino de hardware.

Resumiendo: Ayer, cuando me disponía a apagar el equipo, donde tengo instalado un Kubuntu 10.04.1 LTS, empecé a notar una lentitud extrema en los procesos y, como colofón, un bloqueo de escritura en disco. Esto no suele anticipar nada bueno. Sólo conozco cuatro causas por las que se bloquea la escritura en disco en Linux:

1. No queda suficiente espacio libre en disco.
2. Se ha rebasado el número de punteros de disco permitidos.
3. La versión de Linux instalada tiene un error a nivel de core que bloquea la escritura a disco arbitrariamente.
4. El disco tiene sectores defectuosos.

La mía fue la cuarta. Esta mañana, al reiniciar el equipo, me encontré sin modo gráfico ni línea de comandos: Me recibió un sobrio mensaje de error de disco.

El primer reflejo fue reiniciar en modo recuperación, pero el resultado final fue el mismo. Tras varios intentos fallidos, di con la tecla, aunque no garantizo que le sirva a todo el mundo:

1. Arrancar con un live CD.
2. Ejecutar, en una terminal, el siguiente comando:

   sudo fsck -f /etc/sdb1

   (reemplazar sdb1 por el disco duro afectado)
3. Desinstalar el driver de vídeo:

   sudo dpkg --purge fglrx

   (los propietarios de nVidia deben reemplazar //fglrx// por //nvidia//)
4. Instalar el driver de vídeo:

   sudo apt-get install fglrx

   (los propietarios de nVidia deben reemplazar //fglrx// por //nvidia//)

Con estos sencillos pasos, he conseguido estabilizar el sistema. Gracias a la nube y a los backups programados, en ningún momento he temido por mis datos, y en caso de catástrofe extrema, la mayor parte del software que utilizo también reside en la nube (creo que se salvan Spotify, Eclipse, OpenOffice y los propios navegadores).

Anoche estaba trabajando en este sitio web que usted lee ahora mismo. Desde entonces hasta este preciso instante en que yo escribo, todo ha sido un cúmulo de despropósitos que intentaré resumir de una manera amena:

• Síntoma: Mi instancia de Drupal empieza a hacer cosas raras, entre ellas hablarme mal de su propio sistema de caché con mensajes que no voy a repetir por su escasa utilidad. Dando por buenas sus quejas, limpio la caché y entonces todo deja de tener sentido: Drupal se deteriora gravemente.
• Intento nº 0: Reinicio MySQL. La parada muy bien, pero el arranque me deja tirado. Lo intento tres veces más sin éxito.
  Compruebo que el disco tiene suficiente espacio libre. 15 GB no es gran cosa, pero tampoco es para que se agobie. Pensando que se trata de un bloqueo transitorio del disco duro marca Debian, decido reiniciar.
  • Resultado: Pésima idea, sobre todo si se pretende terminar un trabajo a las tres de la mañana: El sistema no arranca, no es capaz de montar las particiones y aparece la shell de BusyBox ("la navaja suiza de Linux").
• Intento nº 1: Arranco desde un live cd y trato de abrir la unidad de disco.
  • Resultado: No es posible abrir la unidad de disco. Salta el siguiente mensaje de error:
    
    

    mount: wrong fs type, bad option, bad superblock on /dev/sda1

    
    
    Nota: Sustituya sda1 por el dispositivo que corresponda.
    

• Intento nº 2: Teniendo ya presente que los descriptores del disco se han ido a paseo, intento profundizar en la cuestión:
  
  

  dmesg | tail

  • Resultado: Obtenemos, entre otras cosas, este mensaje:
    
    

    EXT3-fs: group descriptors corrupted!

• Intento nº 3: Como lo importante no es tener todas las respuestas, sino saber encontrarlas, se va uno a Google y busca la maldita frase. Entre los resultados encontramos uno que parece bueno.
  • Resultado final: Si seguimos los pasos descritos por nuestro sysadmin de cdbarra, y esperamos pacientemente a que el proceso de fsck.ext3 termine, de momento ya podremos acceder al disco duro. A continuación, le recomiendo almacenar la información importante en un sistema de almacenamiento externo (o mejor, en la red si dispone de un canuto medio decente) y tras ello, reiniciar. Lo más probable es que haya perdido información temporal y poco más. En mi caso, alegremente, puedo decir que no he perdido ni un bit, aunque lo cierto es que mi copia de seguridad funciona religiosamente todos los días.

Sea como fuere, hay que dar las gracias al autor del artículo que ha salvado nuestro disco duro. ¡Gracias, sysadmin de cdbarra!

Hace unos días, tras hacer algo inofensivo en una Ubuntu Intrepid, GDM dejó de funcionar y, como consecuencia, el inicio de sesión en el sistema se fue a tomar viento fresco. Concretamente, tras introducir usuario y password correctos (si son incorrectos, muestra un error), aparecía un mensaje en consola y volvía a solicitar las credenciales.

Dado que confío en el poder de regeneración de Linux, entré en modo de recuperación, realicé todas las verificaciones pertinentes, creé un nuevo usuario... Nada funcionó. Las búsquedas en Google fracasaron, pero aun así, seguí insistiendo. Probé, por ejemplo, a reconstruir el fichero /etc/passwd, pero tampoco sirvió de nada. Estaba a punto de desistir cuando recordé haber visto, justo antes de la catástrofe, un segmentation fault que no venía a cuento. Nuevamente en modo recuperación, ejecuté un passwd como root, que generó un lindo segmentation fault. Así las cosas, googleé lo siguiente:

passwd segmentation fault cannot login tty1

Y por fin, tras días de ardua indagación, llegué hasta este foro, donde un acertadísimo mould resolvió mis problemas: Elimina el paquete libpam-smbpass y tu vida volverá a ser satisfactoria. Así lo hice, y aunque no me ha bajado la hipoteca ni he ganado la lotería, hace un rato pude acceder nuevamente a mi Ubuntu Intrepid, que estuvo a punto de convertirse en una Kubuntu Jaunty Jackalope.

Estoy acostumbrado a configurar servidores Apache, al menos para mis necesidades. El fichero httpd.conf es muy fácil de configurar, ya que está autodescrito. Sin embargo, siempre se agradecen las capas visuales. En Barrapunto hablan de dos de ellas: Kochizz y Sioux, que todavía no tiene sitio web.

Ya no hay excusas para dejar un Apache sin configurar.