Últimas Publicaciones

Debian no reconoce mi Kindle Touch

Si, si lo reconoce. Incluso podrás montarlo con el comando mount manualmente después de enchufar el kindle al ordenador por USB. Pero no será reconocido automáticamente ni será detectado por Calibre aunque lo hagas.

Para que haga todo eso necesitas instalar las mtp tools (apt-get install mtp-tools mptfs libmtp8). Y con eso ya está. Ahora debería reconocerlo de forma automática tanto Debian como Calibre en cuanto lo conectes por USB.

Firefox y Thunderbird tienen letras feas en Ubuntu

Tras una actualización (generalmente de software KDE) algunos programas, y en especial Firefox y Thunderbird, muestran letras feas, grandotas y sin antialiasing en los menús y el contenido.

Para solucionarlo, borra el fichero .fonts.conf que está en tu $HOME.

Reinicia todos los programas afectados. De nada.

El asunto de los cuelgues del Samsung Galaxy S2 con Ice Cream Sandwich 4.0.3

Orange acaba de sacar la actualización oficial a Ice Cream Sandwich 4.0.4 a través de Samsung Kies. Compruébalo en tu Samsung Kies y actualízate, aunque no está claro actualmente que esta actualización solucione al completo el problema.

Si tienes un móvil Samsung Galaxy S2 y le has actualizado el software a ICS 4.0.3 utilizando Samsung Kies, (o sea, es una actualización oficial, has oído bien), es altamente probable que te vas a encontrar con un bug gigantesto que hace que tu móvil se cuelgue y falle frecuentemente cuando se intenta conectar al WiFi.

Los síntomas son los siguientes:

  • Cuando enciendes el WiFi a través del botón de las notificaciones, se queda verde oscuro, sin llegar a verde completo. Después ya no puedes desactivarlo ni llega a activarse nunca del todo. Y por supuesto, no se conecta.
  • A veces no puedes encender la pantalla del móvil. Aprietas el botón para encenderla pero no responde (tu no lo sabes, pero esto ocurre siempre después de que el WiFi se haya quedado atascado)
  • Algunas de las veces que el móvil está con la pantalla apagada y no responde, notas que está muy, muy caliente al tacto.
  • Si reseteas el móvil, notas que se ha comido media batería, como si hubiera estado horas encendido.

Enhorabuena, tienes el bug. Puedes quejarte todo lo que quieras, pero no hay solución alguna en la versión 4.0.3 de Android. No importa lo que te cuenten por ahí, tonterías de configurar parámetros estáticos en el WiFi, ajustar la banda de frecuencia a "Solo 2,4 GHz", hacer un hard reset, etc, etc... Créeme, no hay solución y tu móvil se seguirá colgando una y otra vez. Puede que tarde una hora o una semana, eso depende de cuánto uses el WiFi y del azar, pero se acabará colgando hagas lo que hagas.

Aún peor... Si no te das cuenta de que el WiFi se ha colgado, es posible que el bug acabe provocando un fallo de hardware y que el WiFi deje de encenderse nunca más. En ese caso, el botón WiFi ya no se pone ni verde oscuro... se queda en blanco. Y así seguirá aunque resetees el móvil o reinstales el sistema operativo. En otras palabras: WiFi kaput. Al parecer, esto es por culpa de que el calor producido internamente por el chip de WiFi es tan alto, que derrite no-se-que y lo funde físicamente. Si estás en ese caso, la única solución que tienes es enviar el móvil al servicio técnico para que cambien la placa madre.

Bien... te he dicho que no hay solución, y es verdad, pero hay que hacer un par de anotaciones al margen. La primera y la más importante, es que está saliendo ya al mercado la actualización de Android a la versión 4.0.4. Confirman en los foros, que esta versión corrige el bug y ya no se cuelga ni da problemas con el WiFi.

Repito: A fecha de hoy, 12/9/2012, Orange tiene disponible la actualización a la versión 4.0.4 de Android para el Samsung Galaxy S2 a través de Samsung Kies. Es una actualización oficial. Lo que soluciona el problema del bug entre otras cosas. Actualízate, actualízate ya y olvídate de todo lo que te estoy contando.

La segunda, y no menos importante, es que aunque no puedes evitar el bug, si puedes reducir mucho sus efectos hasta casi no tener cuelgues y no provocar fallos físicos. Para ello sigue estos consejos:

Consejos en caso de cuelgue

  1. Vigila tu WiFi. Cada vez que enciendes el WiFi, hay un cierto riesgo de que se cuelgue y no conecte, quedando el botón de las notificaciones en color verde oscuro. Si llega a encenderse y conectar, entonces ni el WiFi ni el móvil se colgarán y funcionarán perfectamente, así que puedes estar tranquilo. El riesgo existe solo cuando el WiFi se enciende y pasa de OFF a ON.
  2. Si has encendido el WiFi y se ha colgado (botón en color verde oscuro), no permitas que se quede así. Si lo haces, cuando la pantalla se apague es muy probable que el móvil entero se quede colgado y deje de responder, la batería empiece a consumirse a marchas forzadas, el móvil se caliente, y se acabe averiando de verdad. Insisto: si el WiFi se ha colgado, no permitas que se quede así. Puedes hacer varias cosas:
    • Hay gente que lo consigue desbloquear poniendo el modo avión y luego quitándolo, de tal forma que el WiFi vuelve a funcionar (no en mi teléfono).
    • Hay gente que lo consigue ajustando a "WiFi Direct" y luego quitándolo (no en mi teléfono).
    • Hay gente que teclea un código en el teléfono (*##526#*#*), que hace que se recargue el driver del WiFi (yo ni lo he intentado).
    • Reinicia el teléfono (en mi teléfono es lo único que funciona).
  3. Si no te has dado cuenta de que el WiFi se colgaba, tarde o temprano, mientras la pantalla está apagada, se colgará todo el teléfono. Pulsarás el botón de encendido y verás que no responde. Puede que notes que el teléfono empieza a calentarse. En ese caso solo tienes dos opciones:
    • Mantén pulsado el botón de encendido bastante rato, hasta que veas el que teléfono se reinicia (eso es lo que has hecho: forzar un reinicio). Es muy posible que entonces notes que de golpe se ha consumido un montón de batería.
    • Si lo prefieres, o si lo anterior no funciona, quita la tapa trasera y retira la batería. Espera un poquito, vuelve a ponerla, y enciende el móvil.

Consejos para reducir el número de cuelgues

Habíamos quedado en que hay riesgo de cuelgue cada vez que encendemos el WiFi, pero que una vez encendido, el WiFi era estable y ya no se colgaba. Bien... yo he reducido el número de cuelgues a (casi) nunca, sencillamente reduciendo a un mínimo el número de veces que el WiFi se enciende a lo largo del día:

Para ello tengo instalado Juice Defender Ultimate. Ahora bien, esto parece un contrasentido, porque Juice Defender ahorra batería precisamente activando y desactivando el WiFi cada vez que se enciende o apaga la pantalla, y hay que evitar eso. Por tanto, hay que hacer algunos ajustes. Vete a las opciones y activa "wifi" en "Controles -> Mantener activo". Vete a disparadores y activa también "Ubicación".  Entrénalo para que conozca todos los puntos de acceso Wifi a los que habitualmente te conectas.

Con esto ¿qué has conseguido?. Pues es muy sencillo, a partir de ahí, el móvil mantendrá el WiFi apagado continuamente, y solo lo encenderá cuando estés cerca de un punto de acceso conocido. En cuanto se conecte al punto de acceso WiFi, ya no lo volverá a apagar, ni siquiera con la pantalla apagada. Ciertamente, consumirá batería porque nunca cortará la conexión, pero consuélate pensando que el WiFi consume poca, realmente poca, comparado con el 3G. Así que con estos ajustes, es posible que, sin tener que hacer nada, tu WiFi solo se encienda dos o tres veces al día y el riesgo de cuelgue sea mucho más bajo.

Y espera. Pronto llegará a España la versión 4.0.4, que no tiene el bug, y podrás actualizar el móvil.

Muchísimas gracias al foro Android de Google, concretamente al hilo 28036, que son los que me han mantenido informado de todo esto. Léelo por ti mismo, si buscas más información.

Suerte...

No puedo logarme en mi QNAP NAS, solo me deja cambiar la contraseña

Un buen día, la página web de configuración de mi QNAP NAS 219P dejó de permitirme al acceso a la página de administración. Eso significa que no podía reconfigurarlo a través de la web. Solo me permitía cambiar la contraseña, nada más que eso.

Bien, cuando un usuario normal (no admin) del NAS accede a la página web, el único servicio al que tiene acceso es el cambio de contraseña. Solo cuando entra el usuario admin accederá no solo al cambio de contraseña, sino a todos los servicios de configuración del NAS.

En otras palabras, si accediendo como admin, tu NAS solo te ofrece el cambio de contraseña, significa que tiene un fallo en el sistema que le impide saber que el usuario admin tiene privilegios de administrador. Eso normalmente, se configura a través del grupo, que está contenido en el fichero /etc/config/group y contiene algo así:

administrators:x:0:admin
everyone:x:100:admin
guest:x:65534:guest
transmission:x:101:

Vale. Para solucionar esto, tendrás que acceder al QNAP usando SSH. Así que haz un "ssh admin@<ip_del_qnap" y lógate con tu contraseña. Comprueba que el fichero /etc/config/group contiene la primera entrada, la que se corresponde con "administrators:x:0:admin". No importa que esté en la primera línea o en la tercera, pero tiene que estar.

En mi caso, el fichero /etc/config/group solo contenía basura que parecía código html. Algún software había sobreescrito el fichero. En cambio, había un fichero llamado /etc/config/group_tmp que sí contenía las entradas correctas. Símplemente moví el fichero /etc/config/group_tmp a /etc/config/group y reseteé el QNAP. Eso solucionó el problema y ya pude logarme como admin.

Si tu no ves un fichero /etc/config/group_tmp al que echar mano, siempre puedes usar el fichero original de fábrica del QNAP, que es /etc/default_config/group. Cópialo (no lo borres) a /etc/config/group y reinicia.

Muy útil, que el QNAP te permita acceder por SSH. Ya son dos, los lios gordos de los que me ha sacado...

Muchas gracias a Phuture y NocturnalFilth, del QNAP NAS Community Forum, que encontraron la solución un año antes que yo. No me deis las gracias, dádselas a ellos. ;-)

Login remoto a otra máquina con VNC

En otro truco, hace días, os hablaba de VNC para acceder a otra máquina de tu red local.

Pero esto se queda un poco corto. Supongamos que quieres un verdadero login remoto, es decir, convertir la máquina remota en un verdadero ordenador multiusuario, de tal forma que un usuario pueda entrar en su escritorio  de forma remota, al mismo tiempo que otro usuario accede al suyo en la propia máquina remota.

Asumo que en tu máquina ya tienes un servidor VNC funcionando y configurado (por ejemplo, en mi caso, Xvnc4). No es muy complicado, de todas formas: solo tienes que instalar el paquete vnc4server con apt-get (en el caso de Ubuntu) y después arrancar el servidor con el comando vncserver. Te pedirá una contraseña para que protejas el acceso, así que dásela. Pero de todas formas, en el método que describo a continuación, se desactiva la autentificación propia de VNC porque usará la autentificación de tu propio escritorio.

Bien, para hacer un login remoto como usuario, hay que combinar XDMCP con VNC, de tal forma que se active el servidor VNC de la máquina remota bajo demanda, sin que tengas que hacerlo a mano cada vez (nada de SSH para activar el servidor).

Para ello, en primer lugar, debes crear un puerto específico destinado a VNC en la máquina remota echando mano del demonio xinetd. Edita el fichero /etc/services y añade una línea que diga esto:

vnc    5908/tcp   #Xvnc

Esto activa el puerto 5908 para el servicio VNC. Vale, ahora tienes que decirle al ordenador remoto lo que tiene que hacer cada vez que reciba una petición de acceso en ese puerto. Para ello crea un fichero /etc/xinetd.d/vnc que diga tal que esto:

# Default: on

# Descripcion: El servidor vnc se activa bajo demanda
service vnc
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = :8 -inetd -once -query localhost -depth 24 -geometry 1280x1024 -securitytypes=none
}

El parámetro "server" dice qué programa atenderá la petición de acceso (en este caso, el servidor VNC), y el parámetro "server_args" dice con qué parámetros se activa (en este caso dice que se usará la pantalla 8, que se pondrá en marcha con el acceso y se detendrá cuando se cierre, que el servidor hará una conexión local XDMCP, que tendrá una profundidad de color de 24 bits, con un escritorio de 1280x1024 y que se desactiva la autenticación de VNC).

¿Ya?. Vale, ahora reinicia el servicio xinetd con un "sudo /etc/init.d/xinetd restart".

Vale, ahora tienes que activar XDMCP en sí mismo. Esto dependerá de qué gestor de pantallas uses. Si estás usando gdm (Gnome), que es lo más habitual, entonces edita el fichero /etc/gdm/custom.conf y en el apartado [xdmcp] cambia la línea "Enable=false" por "Enable=true". Esto es lo que ocurre en Ubuntu, para ser más exactos. En otros sistemas puede que te venga mejor ejecutar gdmsetup, o si usas KDE  editar los ficheros de configuración de kdm, o en otros sistemas los de xdm (si no usas ni Gnome ni KDE). En cualquiera de los casos, ya sea en gdm, kdm o xdm, tienes que acceder a la configuración y activar la opción XDMCP. Para localizar los ficheros en cuestión te puede ayudar el comando "find /etc -name gdm" por ejemplo, o averiguar cómo hacerlo en tu sistema buscando en Google (por ejemplo "ubuntu habilitar xdmcp")

Vale, ahora reinicia el servidor gráfico o mejor resetea la máquina entera. Con esto ya has terminado en la máquina remota.

Ahora vete a la máquina cliente, abre un terminal y teclea: "vncviewer selene:5908". Bien, obviamente, no tienes que teclear esto exactamente, sino el nombre (o la IP) de tu propia máquina remota.

Y ahora deberías abrirse en tu pantalla algo así:

La máquina remota ofreciendo login a través de VNC

Tecleas tu contraseña de usuario y et voila:

La máquina remota dándote acceso a tu escritorio

La máquina remota dándote acceso a tu escritorio

Google Chrome ya no recuerda mis contraseñas

Un día abres tu navegador todo confiado y te encuentras conque en todas tu páginas favoritas estás deslogado en la página de entrada. Curiosamente tu contraseña está ahí, con todos sus asteriscos, pero no has entrado automáticamente, tienes que darle al botón.

Pulsas la casilla de "Recuérdame", le das al botón. Entras a la página. Luego cierras el navegador y vuelves a abrirlo. Otra vez deslogado. La contraseña está ahí otra vez, pero no te ha recordado. Que desconsiderado...

Vas a preferencias, borras los datos de navegación, borras las cookies, te aseguras de que la casilla "Permitir que se establezcan datos locales" está marcada en "Configuración de contenido". Vuelves a intentarlo y nada, no te recuerda.

Bien, no me anduve con contemplaciones.  Yo lo solucioné así:

  1. Entré en "Preferencias", "Cosas personales" y me aseguré de que tenía configurada una cuenta de Gmail para mantener sincronizados los marcadores y esas cosas.
  2. Cerré el navegador.
  3. Abrí una consola y borré la carpeta ".config/google-chrome" de mi Home (yo tengo copias de seguridad actualizadas a diario, ¿las tienes tu?).
  4. Abrí de nuevo el navegador. Está desconfigurado, así que lo primero que hace es preguntarte qué portal de búsqueda quieres (obviamente, Google, ¿no?).
  5. Se abre el navegador pero virgen, sin marcadores ni nada.
  6. Vas a "Preferencias", "Cosas personales" y configuras la cuenta de Gmail para sincronización. Automáticamente vuelven a aparecer todos tus marcadores y esas cosas.
  7. Entro en todas mis páginas favoritas. Cierro el navegador.
  8. Lo abro y ahora sí me recuerda y entro directamente ya logado. :-)

No, no me ando con chiquitas...

Hotot se queda colgado diciendo “Loading Resources…”

No puedes iniciar el cliente de Twitter Hotot, porque se queda colgado diciendo "Loading Resources..." sin hacer nada más. Lo que es peor, si esperas que una actualización lo solucione vas de cráneo, porque seguirá haciendo lo mismo.

Solución: Algo ha pasado con los ficheros de configuración de Hotot y están corruptos. Bórralos y deja que sean creados de nuevo.

[lacofi@cecile ~]$ rm -Rf .config/hotot
[lacofi@cecile ~]$ rm -Rf .cache/hotot

Ahora arranca Hotot y te pedirá que introduzcas tu cuenta de Twitter.

Notas sobre la actualización de Ubuntu 11.10 (Oneiric Ocelot) a 12.04 (Precise Pengolin)

En la actualización, se desactivan automáticamente todos los repositorios de terceros, por lo que habrá que reactivarlos o actualizarlos posteriormente.

Hay determinado software que te dará algún problema extra.

Dropbox

Dropbox no consigue reiniciarse una vez actualizado el sistema a 12.04.

Este problema me surgió en la actualización de Cecile, pero no es una instalación fresca en Sophie. Para imitar una instalación fresca:

  1. Ejecuta el comando "echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches". Sio no lo haces, te lo pedirá él de todas formas en cuanto lo inicies.
  2. Borra tu carpeta Dropbox (haz antes una copia de seguridad, claro).
  3. Borra la configuración (es decir, el directorio ".dropbox" de tu Home)
  4. Ahora inicia de nuevo dropbox.

Con esto, en mi sistema funcionó y empezó a sincronizar de nuevo. Eso si, preparate para esperar un buen rato, porque tendrá que bajarse de nuevo todos los ficheros desde la nube. Curiosamente no funcionó a la primera sino al segundo o tercer intento.

Curioso, muy curioso.

VMware

O VMplayer, da igual. No funcionan en Ubuntu 12.04. El problema es que fallará la compilación de los módulos vmnet debido a cambios en el kernel 3.2 que usa esta versión de Ubuntu.

Afortunadamente, hasta que los chicos de VMware se den por aludidos y saquen una versión corregida compatible con Ubuntu 12.04, hay disponible un parche creado por la comunidad. Bájatelo a tu ordenador. Descomprimelo. Vete a la carpeta donde se ha descomprimido, y ejecuta el script "patch-modules_3.2.0.sh" como root. Deja que el script trabaje y parchee las fuentes. Cuando termine (no tardará mucho), arranca de nuevo VMware.

Esto funciona para la versión de VMware 8.0.2. Si quieres instalar la nueva versión VMware 8.0.3 volverá a fallar la compilación, así que tendrás que ejecutar de nuevo el script. Pero antes tienes que editarlo y cambiar la línea donde pone "vmreqver=8.0.2" por "vmreqver=8.0.3" para después ejecutar el script.

Si aplicas el parche a VMware 8.0.2 y después actualizas a 8.0.3 el parche no dejará que lo vuelvas a ejecutar. Para que funcione, tendrás que borrar el fichero /usr/lib/vmware/modules/source/.patched como root.

El fichero .xsession-errors crece sin control en Ubuntu 11.10

En Ubuntu 11.10 (Oneiric  Ocelot), me he encontrado conque con cierta frecuencia el /home se queda sin espacio. El motivo es que hay un fichero que crece exponencialmente ocupándolo todo. Me refiero, claro, al fichero .xsession-errors de tu Home. Si borras el fichero con "rm" te encuentras conque no liberas espacio en absoluto y, aunque el fichero no existe, el espacio sigue constando como ocupado. Solo después de resetear el sistema volverás a tener ese espacio libre.

Se trata de un bug conocido. La nueva distribución Ubuntu 12.04 (Precise Pangolin) lo soluciona (más bien lo parchea) volcando los errores del subsistema gráfico a un fichero de /tmp con lo que los logs son borrados en cada reseteo del sistema. Pero si eres como yo y tu ordenador está siempre encendido, los logs nunca serán borrados y el fichero seguirá creciendo exponencialmente aunque esté en /tmp.

La solución definitiva es decirle al sistema de log que ese registro de errores se vaya directamente al agujero negro. Para ello edita el fichero /etc/X11/Xsession, edítalo como root, y en él verás una linea que dice:

ERRFILE=$HOME/.xsession-errors


Cambia esa entrada para que diga:

ERRFILE=/dev/null


Resetea el sistema. Ya está. Ahora el fichero de errores no ocupará espacio porque se irá a carajo según se vaya creando.

Muchas gracias a los miembros de Ubuntu Forums, como siempre ahí, al rescate.

No puedo instalar Chromium en Gentoo, me da error

Si estás intentando instalar Chromium en Gentoo, puede que te salga un error que diga al final algo así:

make: *** [out/Release/chrome] Error 1
emake failed
* ERROR: www-client/chromium-13.0.782.107-r1 failed (compile phase):
*   (no error message)
*
* Call stack:
*     ebuild.sh, line  56:  Called src_compile
*   environment, line 6339:  Called die
* The specific snippet of code:
*       emake chrome chrome_sandbox BUILDTYPE=Release V=1 || die;
*
* If you need support, post the output of 'emerge --info =www-client/chromium-13.0.782.107-r1',
* the complete build log and the output of 'emerge -pqv =www-client/chromium-13.0.782.107-r1'.
* The complete build log is located at '/mnt/guin2xp/portage/www-client/chromium-13.0.782.107-r1/temp/build.log'.
* The ebuild environment file is located at '/mnt/guin2xp/portage/www-client/chromium-13.0.782.107-r1/temp/environment'.
* S: '/mnt/guin2xp/portage/www-client/chromium-13.0.782.107-r1/work/chromium-13.0.782.107'

Vale. Lo primero de todo, has de saber que la compilación de Chromium es muy sensible a la falta de memoria porque la devora. A poco que no le guste la que tienes, zas, se rompe y da error. La solución es bien fácil: crea un fichero de swap de, pongamos, 3 Gb, actívalo, y ya tienes más memoria. Ahora vuelve a hacer emerge y muy probablemente pueda compilarlo.

Para crear la swap, ya sabes cómo se hace, ¿no?...

[lacofi@cecile ~]$ sudo dd if=dev/zero of=/media/swapfile bs=1M count=3072
[lacofi@cecile ~]$ sudo mkswap /media/swapfile
[lacofi@cecile ~]$ sudo swapon /media/swapfile