El problema que había no era ni más ni menos que un problema con las licencias de cPanel… y mientras lo intentaban arreglar hubo caídas en el servidor.

Bueno. Por lo menos sabemos que no había fantasmas…  Se solucionará a lo largo de este fin de semana (espero)… así que las pruebas tendrán que esperar.

Llevo desde septiembre desarrollando mi trabajo con WordPress, y he descubierto que no sólo es bueno para hacer blogs, sino que también es un CMS muy potente para cualquier otro contenido -prueba de ello son los cinco portales que ya tengo “online”, versus uno sólo que ha conseguido desarrollar mi compi el webmaster alias “http“.

Afortunadamente, ayer departí un poquito con mi jefe acerca de esto y despejó mis dudas: no será un CMS para uso exclusivo y restrictivo, porque podremos seguir teniendo la libertad de desarrollar -al menos a priori- en otras plataformas. No van a cortarnos las alas…

Menos mal. Suspiré aliviado. Porque no es lo mismo comprarte un coche “de serie”, que personalizarlo con las cosas con las que a tí “te gusta conducir”…

La anatomía es la siguiente: estás trabajando tan tranquilamente, de repente suspira tu disco duro y tu ventilador, y aparece el pantallazo, con BAD_POOL_CALLER como cabecera y luego, en la explicación técnica o  STOP aparece lo siguiente:

****STOP: 0X000000C2 (0X00000007, …)

Después de instalar ciertas versiones de Windows XP desatendidas, es común que el sistema instale “drivers de más”, o detecte algún driver mal instalado… pero al ser desatendido el proceso, “se le tapa la boca” y no puede gritar para decirnos que está malito.

Tras mucho hurgar, he encontrado una solución, que ha sido válida para mí y entiendo que para muchos lo será, ya que gran parte de estos fallos se solucionan así:

Mi PC > Propiedades > Hardware > Administrador de dispositivos. Una vez aquí, he hallado dos dispositivos, con drivers erróneos, marcados con una exclamación amarilla, que eran los que provocaban el error cada vez que navegaba con Firefox, utilizaba GTalk, o trabajaba con Picasa.

Así que la solución, si no queréis eliminarlos, es deshabilitar esos dispositivos con error. Pasarán de estar marcados con una exclamación amarilla a estar cruzados con un aspa roja y serán ignorados por el sistema. No hay que tener miedo al hacer esto, ya que el driver en cuestión impedia al dispositivo funcionar correctamente y por tanto no estaba en uso. Si por el contrario queremos utilizarlo porque consideramos que es un dispositivo que necesitamos, lo que habría que hacer es buscar el driver correcto del fabricante e instalarlo.

A partir de este momento, es cuestión de observar. Yo llevo ya un buen rato trabajando con los programas que al correrlos detectaba el error y ahora todo marcha de maravilla.

De nada, espero que os haya sido útil.

El tema es el siguiente: cuando Win provoca un BSoD, Ubuntu es “incapaz” de montar la unidad si no se ha realizado un “clean shutdown“, es decir, un apagado correcto.

Ni que decir tiene que antes podías tocar la tecla “ESC” como comodidad para evitar que se comprobara la integridad de la unidad… pero ojo, esto sólo funciona si lo que había sucedido era un “unclean shutdown” en Linux… no en otros sistemas.

Tras mucho indagar, he hallado la solución, y es bien sencilla… eso sí, debes realizarla bajo tu propia responsabilidad, ya que puede haber sucedido un error grave que sí requiera del testeo por parte de Linux, con lo que te tocaría hacerlo manualmente después.

La solución es bien sencilla: hay que modificar el archivo fstab.

Mediante la orden gedit /etc/fstab editas el archivo fstab, que es donde se guardan los datos de montaje de todas las unidades, tanto unidades de Linux como de otros sistemas -incluyendo lectoras de CD y pendrives.

Lo importante es modificar los últimos dos parámetros de cada entrada. Pongo por ejemplo mi archivo.

# /etc/fstab: static file system information.
#
#  — This file has been automaticly generated by ntfs-config –
#
# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0
# Entry for /dev/sdb1 :
UUID=xxxxxxxxxxxxxxxxxxxxxx / ext3 relatime,errors=remount-ro 0 0
# Entry for /dev/sdb5 :
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxx none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
/dev/sda1 /media/xxxx\xxx ntfs-3g defaults,locale=es_ES.UTF-8 0 0

Como podréis ver he puesto dos campos en rojo: los valores dump y pass.

El valor dump en activado (1) indica que se  realiza un respaldo del sistema de archivos. Si está activado (1), se hará una copia con las opciones. Lo normal es que siempre esté (0) desativado, ya que este error no debe suceder.

El valor pass es el que más nos interesa. Pass controla el comando fsck, que es el equivalente al CHKDSK de Windows.  Si se encuentra activado (1) realizará un chequeo cada X veces que se haya desmontado el sistema (da igual si se cerró de forma correcta o incorrecta) o si el dispositivo se ha montado incorrectamente. Si está desactivado esta verificación no se realizará nunca. Lo recomendable es tenerlo activado (1) pero en lo que a mí respecta, debido al uso racional y consciente que hago de mi sistema, lo que yo quiero es tenerlo desactivado. Así que el valor que debo poner es (0) para evitar que fsck haga su trabajo.

Así que ya sabéis, basta con editar este archivo, marcar los valores dump y pass de cada unidad a 0-0… y olvidarse del tema. Ahora quizá alguno se me eche al cuello y me diga que lo que estoy haciendo no se debe hacer. Lo sé, y no me importa. A mí me es útil. Tan útil como desactivar el CHKDSK en Windows.

Para saber más | Acabó mi guerra personal con el CHKDSK

Actualización: Antonio aporta una solución menos drástica en su comentario, que reproduzco. Tiene mucha razón en lo que dice, ya que facilita que el sistema chequee los archivos únicamente una vez al mes (opción que yo tenía activada con anterioridad a todos mis problemas). Su solución, básicamente, te ahorra el tener que soportar el chequeo automática cada 30 ó 35 arranques (cosa que puede suceder con bastante más frecuencia que una vez al mes). Así que tenedla en cuenta y analizad vuestro caso concreto y vuestras circunstancias antes de hacer nada, porque como digo, lo que hagáis es responsabilidad vuestra, y lo quvaloréis los datos que archivéis en vuestro disco duro, también. Aquí va:

SKaRCHa dijo:

Yo lo que hago es ponerle que me chequee los sistemas de ficheros cada mes, de forma que en total ocurre 12 veces al año; una cantidad que veo bastante razonable.

El comando para hacer eso es el siguiente:

<code>tune2fs -c 0 -i 1m <dispositivo></code>

Para más información:

<code>man tune2fs</code>

Creo que tendremos que seguir muy de cerca a este personaje y su acción de gobierno. No olvidemos que se trata de la “primera potencia mundial”…

Enlace | Nueva web de la Casa Blanca.

Esta mañana me voy a dedicar a documentar todo esto… y la verdad es que, aunque parece un lío bastante grande, sé que en el futuro nos va a ahorrar muchos quebraderos de cabeza. Así, de paso, podré investigar y averiguar acerca de ciertos errores de WordPress con los que nos hemos encontrado y que, aunque nos permitan trabajar con cierta soltura,  no dejan de ser inquietantes.

Ya se encuentra disponible el archivo corregido. La traducción la he rehecho empleando la oficial, que a todas luces es magnífica, con lo que la he “repasado” y modificado introduciendo exactamente los cambios que indiqué más abajo. Ha costado lo suyo pero en principio, funciona con normalidad.

Llevo un buen rato re-traduciendo la traducción de WordPress 2.7 publicada en TodoWordPress.com, que a su vez viene de Carrero.es. La he traducido simple y llanamente porque la he bajado, y he encontrado cosas que no me han gustado en absoluto… muchas sentencias estaban incompletas, o en inglés, o con un español de dudosa procedencia; y estoy bastante harto de ir cogiendo traducciones por ahí que no me convencen.

Puedes bajarla aquí. Pruébala, y si te gusta, quédatela. No pierdes nada. Hay otras muchas que quizá te convenzan más.

Qué te vas a encontrar:

• Esta traducción se ha realizado en español informal.
• Se han corregido las mayúsculas en medio de las frases. En español, es incorrecto salvo que se trate de nombres propios.
• Se ha sustituído el anglicismo “e-mail” por “correo-e“. Porque yo lo valgo.
• Se mantiene “Tablero” como traducción a “Desktop“. Escritorio incita a confusión con el escritorio de los S.O.
• Se mantiene “nightly builds“, “Press This“, “widgets“, “trackbacks” y “pingbacks“en inglés ya que la gran mayoría de gente se refiere a estos términos en inglés.
• El término bitácora se transforma en “blog“
• Impersonalización de mensajes de sistema no referidos al usuario

Traducción | wp27-es_es – WordPress 2.7 en Español de España

Por favor, deja tus comentarios, errores que veas, sugerencias, preguntas, etc…

Con Wordle puedes crear una nube de etiquetas tan chula como la mía… Ya no tienes ninguna excusa para que nadie sepa de qué se habla en tu blog.

Briefly unavailable for scheduled

maintenance. Check back in a minute.

Menos mal que era un localhost, que todo estaba “respaldado” y que no ha pasado nada… porque hoy nos acaba de dar un buen susto WordPress. Al actualizar el core, la nueva fórmula ideada por  Matt y sus chicos… el sistema me ha escupido este feo mensaje, que obviamente requiere una reinstalación… ya que no sólo aparece en el frontend, sino también en el backend.

Me pregunto si la opción de “hacer backup automático” no se habrá contemplado por algún sitio… creo que es bastante arriesgada esta fórmula de actualización, (http://localhost/wordpress/wp-admin/update-core.php?action=do-core-upgrade) con la que nos vamos a encontrar probablemente a partir del miércoles que viene, cuando sea publicado WP 2.7…

Que Dios nos coja confesaos…

Actualización: Aparentemente, volviendo “atrás” con el botón del navegador, y volviendo a introducir la URL que he puesto arriba, detecta automáticamente que ha fallado y lo intenta de nuevo. Menos mal… parece que “hasta esto” lo tenían previsto.