Remontar sistema de ficheros root como de lectura-escritura tras arrancar en modo rescate

El título lo dice todo: arranco un Ubuntu en modo rescate y accedo a la shell como root. Quiero modificar un fichero pero me dice que el sistema de ficheros / está montado en modo de solo lectura. No puedo desmontarlo ya que estoy dentro de él, ¿qué hacer?, pues remontarlo "al vuelo" con el siguiente comando:

# mount -o remount,rw /

Me imagino al sistema operativo dando un saltito y mientras que está en el aire el sistema de archivos pasa de "ro" a "rw" antes de que vuelva a pisar el suelo.

Por cierto, no estoy muerto ni estoy de parranda. Si no escribo últimamente es porque estoy mas atareado que un gato en una matanza. A ver si esta semana puedo escribir alguna cosilla interesante, porque últimamente me dedico más a apretar tornillos que a otra cosa.

Publicar vídeos en un blog implementado con Nibbleblog.

Ya hablé en su día de nibbleblog para su uso privado en la intranet del centro. Esta semana he necesitado escribir un post con varios vídeos y paso a contar como los he insertado. Seguramente el sistema vale para cualquier otro blog/gestor de contenidos/página web.

Algunos vídeos eran de Youtube, para ellos cargamos el vídeo en cuestión en Youtube, y damos sobre el con el botón derecho, seleccionando "Copiar código de inserción". Ese mismo código podremos pegar como html en nuestra página.

<iframe src="https://www.youtube.com/embed/PGNG7VZ-qBI?start=840" 
         width="640" height="480" frameborder="0" allowfullscreen="allowfullscreen">
</iframe>

Si queremos que la reproducción empiece en un momento concreto añadimos "?start=" a la URL:

<iframe src="https://www.youtube.com/embed/PGNG7VZ-qBI?start=840" 
         width="640" height="480" frameborder="0" allowfullscreen="allowfullscreen">
</iframe>

Otros vídeos estaban dentro de Google Drive. Para ello seleccionamos el fichero y lo configuramos para compartir con cualquiera que tenga el enlace. Luego, con el botón derecho, damos a "Obtener enlace", eso nos genera algo así como "https://drive.google.com/open?id=0BwESTH0ykuAAUFJJdERodjgwYTZ", pues lo que nos interesa ese el "id=XXXX" ya que eso nos va a servir para obtener el enlace donde va el vídeo embebido para visualizar directamente, que sería lo marcado en rojo:

<iframe src="https://drive.google.com/file/d/0BwESTH0ykuAAUFJJdERodjgwYTZ/preview"
   width="640" height="480">
</iframe>

Y ya está, tarea hecha. Es una pena no tener cosas mas interesantes de momento, pero estamos sobrepasados por el trabajo y tengo todo a medias.

Usar samba para enviar ficheros desde un script.

Un buen administrador de sistemas tiene siempre un montón de soldaditos trabajando para él por toda la red: scripts, tareas puppet, procesos de vigilancia,... A veces nos interesa que nos manden información de vuelta para que otro proceso o nosotros mismos la recopilemos y que esa información nos llegue de una manera sencilla.

En este caso concreto tenía unos scripts que recaban información y necesitaba que me suministrasen un fichero por cada máquina donde se ejecutaban. Para ello se me ocurrieron varias alternativas:

• Que me lo enviasen por correo: instalando y configurando en cada PC un cliente de correo tipo mutt. Demasiado complicado.
• Que se guarde en algún servidor conectando por FTP, SCP, ... Me obliga a habilitar ese servicio en el servidor y buscar la manera de que se pueda guardar el fichero de manera no interactiva sin tener que poner contraseña .
• Hacer facters de puppet y dejar que el propio puppet recopile los datos y los guarde en el servidor en ficheros yaml con sus reports. Si es para algo que va a usarse mucho es una buena solución. Si es para algo rápido e infrecuente no merece la pena trabajarse el facter en Ruby.
• La elegida: escribir el fichero en un recurso Samba de acceso público, sin autenticación. Rápido y sucio, que solo requiere tener instalado smbclient en los PC donde se realiza.

En primer lugar la carpeta compartida de forma promiscua:

# cat /etc/samba/smb.conf
....
map to guest = Bad User
....
[almacen]
comment = Almacen IES
path = /home/almacen
writable = yes
browseable = yes
guest ok = yes
force directory mode = 0777
....

En esta carpeta cualquiera puede leer y escribir sin ningún tipo de autenticación, ideal para scripts que se ejecutan de forma autónoma por toda la red. Ahora vamos a ver un ejemplo de script, que guardará los datos (por ejemplo, nombre del PC y MAC de sus tarjetas de red) en la ruta /home/almacen/deposito y en un fichero con el mismo nombre que el PC:

#!/bin/bash

HOST=$(hostname)

echo  "$HOST" > /tmp/$HOST

ifconfig -a | grep HW | awk '{print $5}' >>/tmp/$HOST

cd /tmp
smbclient -N //172.19.196.14/almacen -c "cd deposito; put $HOST"

exit 0

La clave está en:

smbclient -N //172.19.196.14/almacen -c "cd deposito; put $HOST"

Que conecta a al servidor situado en esa IP y al recurso "almacen" y ejecuta los comandos cd y put para subir el fichero al directorio indicado. Simple, efectivo, rápido y sucio. Lo tiene todo.

La conjura de los necios (IV): Oceanía siempre ha estado en guerra con Eurasia.

Martes 14 de febrero de 2016, informativo de Canal Extremadura:

Versión escrita de la noticia aquí.

Vaya, esto es terrible. Parece ser que una empresa ha decidido que ya no se soporta Linux y hay que moverse a Microsoft. Jara está implementado sobre SAP (que a su vez corre sobre AIX y/o SUSE por lo que se puede leer en Internet) y parece ser que para SAP también es una sorpresa el no soportar Linux, porque en está página actualizada hace 4 meses nos dicen:

Supported Linux Distributions:

The following Linux distributions are tested and certified for use in SAP environments. See also SAP note 171356:

Oracle:

Oracle Linux 7 for x86_64
Oracle Linux 6 for x86_64
Oracle Linux 5 for x86_64

Red Hat:

Red Hat Enterprise Linux 7 for x86_64, IBM System p and IBM System z
Red Hat Enterprise Linux 6 for x86, x86_64, IPF, IBM System p and IBM System z
Red Hat Enterprise Linux 5 for x86, x86_64, IPF, IBM System p and IBM System z
Red Hat Enterprise Linux 4 for x86, x86_64, IPF and IBM System p
Red Hat Enterprise Linux 3 for x86 and IPF (out of maintenance)
Red Hat Enterprise Linux 2.1 for x86 (out of maintenance)
Red Hat Linux 7.1 Professional (out of maintenance)
Red Hat Linux 6.2 (out of maintenance)
Red Hat Linux 6.1 Enterprise Version 1.0 (out of maintenance)

SUSE:

SUSE Linux Enterprise Server 12 for x86_64 and IBM System z
SUSE Linux Enterprise Server 11 for x86_64, IPF, IBM System p and IBM System z
SUSE Linux Enterprise Server 10 for x86, x86_64, IPF, IBM System p and IBM System z
SUSE Linux Enterprise Server 9 for x86, x86_64, IPF, IBM System p and IBM System z (out of maintenance)
SUSE Linux Enterprise Server 8 for x86, IPF and IBM System z (out of maintenance)
SUSE Linux Enterprise Server 7 for IA32 and IBM System z (out of maintenance)
SUSE Linux Enterprise Server for IA32 (out of maintenance)

Supongo que quizá la noticia leída por torso parlante de turno quiere decir que la empresa que da soporte a Jara ha decidido usar SAP sobre Windows y el SES, que parece no tener ningún poder sobre dicha empresa, ha agachado la cabeza y ha dicho "Amén, amo".

Jara tiene su pequeña historia tragicómica. Según cuentan los anales el contrato estipulaba que debía correr sobre software libre, lo ganó IBM y una vez con el poder decidió hacerlo en SAP, que debe ser lo mas próximo al concepto germánico de la libertad. La Junta de Extremadura fue una vez mas un organismo pusilánime que aceptó este cambalache sin penalizar para nada a IBM (ya se sabe,... débil con el poderoso, poderoso con el débil). Recuerdo haber leído hace tiempo en algún blog acusaciones de lo oscurantista del proceso, insinuando sobornos, pero igual lo he soñado porque no lo encuentro ya en Internet. Derecho al olvido, lo llaman.

Bueno, yo venía aquí a hablar de mi libro. En el minuto 1:45 del vídeo la voz en off dice:

El año pasado ya se licitó un contrato millonario para adquirir licencias de Microsoft para las aulas extremeñas. De momento, este proceso se ha paralizado.

Algo que ya comenté aquí. Ya sabemos, si lo dice la telepantalla será verdad: Oceanía siempre ha estado en guerra con Eurasia.

Ejecutar tareas puppet sin servidor puppet.

Tengo unas cuantas máquinas aisladas en una red que no pertenece a mis dominios en las que quiero ejecutar tareas puppet creadas por mi, pero no puedo usar el servidor puppet de dicha red.

¿Existe alguna manera de ejecutar tareas puppet sin tener servidor puppet?. Si, usando "puppet apply". Para ello creamos (o copiamos desde nuestro servidor puppet oficial) en una ruta local, por ejemplo "/root/puppet", un árbol de directorios con los distintos módulos:

# tree /root/puppet
puppet/
├── siatic_ajustes
│   ├── files
│   │   ├── 14-init.conf
.   .   . 
.   .   .
.   .   .
│   │   └── Siatic.desktop
│   ├── LEEME
│   └── manifests
│       └── init.pp
└── siatic_pkgsync
    ├── files
    │   ├── mayhave
    │   ├── maynothave
    │   └── musthave
    ├── leeme.txt
    └── manifests
        └── init.pp

Ahora, si localmente queremos ejecutar siatic_pkgsync haremos:

# puppet apply --modulepath=/root/puppet/ -e "include siatic_pkgsync"

Y ya está. Sencillo...¿no?. Este truco también puede usarse para probar in situ sobre una de las máquinas una tarea puppet que estemos desarrollando para luego propagar a otras máquinas.

Tenía que decir algo más, pero no tengo ahora ganas de que los mercaderes ocupen mi templo, así que pongo esto:

Salud.

Clonado de monitor y cañón con distintas resoluciones.

Sobre resoluciones y xrandr para jugar con ellas ya hemos hablado aquí y aquí.

Vamos a ver como solucionar cuando tenemos una pantalla y un cañón de vídeo que soportan distintas resoluciones y queremos tenerlos clonados con unas resoluciones fijas, independientemente de la que tenga configurada el usuario en su configuración de "Pantalla" de las Preferencias del sistema de XFCE.

En nuestro caso, las pizarras+PC que hemos recibido tienen una resolución máxima de 1280x720 para el cañón de vídeo y de 1920x1080 para el monitor. El monitor se conecta por el puerto VGA-? y el cañón por HDMI-?. Pongo la interrogación porque a priori es imposible saber que número va ahí: no sé si depende del PC, de la temperatura en la superficie de Marte o de las probabilidades de formar gobierno de Pedro Sánchez, la cuestión es al ser variable no se puede poner de forma fija.

El script sería:

#!/bin/sh

#Primero borramos displays.xml del perfil XFCE del usuario para anular cualquier configuración que tuviere.
test -e  $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml  &&  rm  $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

#Averiguamos los id correctos de las salidas HDMI y VGA
HDMI=$(xrandr | grep " connected" | grep HDMI | cut -d" " -f1)
VGA=$(xrandr | grep " connected" | grep VGA | cut -d" " -f1)

#Fijamos la resolución, clonamos y escalamos.
xrandr --output $VGA --mode 1920x1080 --pos 0x0 --rotate normal --output $HDMI --mode 1280x720 --pos 0x0 --rotate normal --same-as $VGA --scale-from 1920x1080
exit 0

Lo ideal para automatizar su ejecución en el PC sería crear un acceso directo al mismo con un fichero .desktop y finalmente meterlo en /etc/xdg/autostart para que se ejecutase con cada inicio de sesión, algo sencillo.

La conjura de los necios (III): no Deus, no machina.

Continuamos con lo dicho aquí y aquí.

En esta nota de prensa del pasado 3 de agosto nuestro presuntamente respetable Gobierno proclamaba:

La Consejería de Educación y Empleo sigue apostando por el software libre en la región.
....
De esta primera reunión se ha extraído, entre otras conclusiones, que la instalación de programas propietarios se hará únicamente en los centros educativos donde se detecte una necesidad real para la formación del alumnado. Igualmente, se ha definido un itinerario a seguir para fortalecer la colaboración y el diálogo con este colectivo y velar por los intereses del software libre en nuestra región, que sigue siendo la apuesta firme de la Junta de Extremadura.
En este sentido, la Consejería asegura que un máximo del 9% de dicho presupuesto, se va a destinar a adquirir el software propietario que se usará en las ramas de Formación Profesional que requieran programas específicos, como es el caso de programas de edición multimedia, contabilidad, etc.
....

Respuesta: trola del 15. Como bien dice nuestro Servicio TIC aquí en el apartado "Instrucciones para la recepción e instalación del equipamiento" el equipamiento viene con arranque dual Ubuntu-Windows y en la mayoría de los casos se deja al libre albedrío y capricho de los usuarios con que sistema arrancar. Si se aplicase la misma política en los comedores escolares mis hijos estarían encantados de poder comer salchichas con ketchup todos los días.

El que un político diga que eso de ahí es una vaca lechera y que su partido ama los productos lácteos no vale nada cuando el obrero especializado, que en este caso soy yo, tiene que arremangarse y ordeñarla y se confirma aquello de lo que venía avisando: es un toro y de leche rien de rien.

Bueno, pues dejemos a los políticos intentando salvarnos de sus miedos y ayudándonos a solucionar sus problemas, y vamos a pensar en lo que viene, que hay que generar riqueza rápidamente para pagar la deuda del Reino de España. Está claro que si no se impone el sentido común y el respeto a la palabra dada, nos van a infestar de forma gratuita (es un decir, porque las licencias las pagamos con nuestros impuestos) de Windows y otras hierbas los centros educativos y tenemos que prepararnos para ello.

1. Lo primero es tener en cuenta que el PC típico de un centro educativo no tiene un uso normal: cada día pasan por él diferentes usuarios con diferentes habilidades a la hora de usarlo. Cualquier persona con luces que haya usado un aparato de forma compartida, desde un coche a una cafetera, sabe que la degradación del mismo es mas rápida. Como dirían Sheldon Cooper: la entropía aumenta en proporción geométrica. Da igual que pongas sistemas de seguridad limitando permisos: los usuarios somos muy ingeniosos a la hora de crear caos de forma inexplicable e involuntaria.
   
2. Lo segundo es que al trabajar con grupos, muchas veces vamos a tener que realizar la misma configuración o acción sobre grupos de PC. Es frecuente pedir al administrador instalar una aplicación en un grupo de PC/usuarios, o copiar unas carpetas y crear una serie de accesos directos, por ejemplo.
   
3. Lo tercero es que los Windows tienen la mala costumbre de actualizarse en el peor momento, ralentizando la conexión y a si mismos. La repanocha llega cuando quieres apagarlo y te dice que esperes media hora: una propuesta chispeante si estás en un centro educativo y tienes que dejar el portátil en el armario de carga porque te vas de la clase.
   

Voy a intentar exponer los distintos enfoques que se me ocurren para gestionar una marabunta de Windows en territorio acostumbrado a Linux, donde ya teníamos nuestro OpenLdap, nuestro puppet, nuestros mirror y demás utilidades al coste de 0 euros:

• Hacerlo todo a mano. Administrar los PC uno a uno. Volver a los 80 pero sin Barón Rojo y sin la URSS. Estupendo para los que les guste sentirse como Chaplin apretando tuercas 12 horas al día en la línea de producción de Tiempos Modernos.
• Montarlo artesanalmente en plan hombre pobre: validar los Windows con OpenLdap a través de pGina, crear carpetas compartidas con samba, montar un PDC con samba-ldap, usar Wpkg para instalaciones automáticas..... muy económico si hay un número razonable de Windows pero sospecho que totalmente insuficiente para lo que se nos viene encima. Para mas INRI estas herramientas tapan solo algunos de los agujeros que se avecinan, no todos, sumado a que las utilidades para administrarlos son bastante rudimentarias.
• Montarlo bien y con clase, con un Windows Server y todas las herramientas adicionales. Claro, aquí hay un problema: nos hemos gastado todo el dinero en el coche y ya no hay para gasolina. Nadie entre las mentes pensantes de la Consejería se ha dado cuenta de que para mantener un tropel de Windows hace falta un entorno de servidor Windows y una máquina potente para ejecutarlo, y eso no sale gratis y habría que haberlo incluido en el presupuesto de los lotes. Pueden mirar al cielo esperando que llegue una solución Deus ex machina, pero lo cierto es que No deus, no machina. Es curioso que en los diálogos al respecto se produce un efecto eco:
  
  
  -Necesitamos un Windows Server
  -Vale, compraremos licencias de Windows Server.
  
  Todo esto sin saber que es un Windows Server, cuanto valen sus licencias, sobre que hierros se va a instalar, ni que otras herramientas hacen falta para poder poner en producción y administrar todos los clientes Windows sin morir en el intento. Dan ganas de decir:
  
  -Necesitamos un condensador de fluzo.
  
  A ver que responden. Por supuesto, de licencias de Windows Server no se ha vuelto a decir ni pío.
  
  
  
• Otra solución que planea sobre nuestros cielos es montar todos los Windows en máquinas virtuales dentro de Linux y redistribuir esas maquinas virtuales cuando haya cambios. De esta forma los usuarios pueden usar sus Windows, les haga falta o no (de igual manera que Isabel la Católica se bañaba una vez al mes, le hiciese falta o no) y si los rompen se reparía copiando la imagen del disco duro. No podrían guardar sus datos en local, pero hacer eso en un ordenador compartido en estos tiempos en que existe Dropbox, Google Drive y demás es un comportamiento un poco dejado que merece ser castigado con perdidas de datos periódicas.
  

Y este es el estado del frente a día de hoy. Seguiremos informando conforme vayamos construyendo, one more time, la solución a un problema que no hemos creado nosotros.

Salud.

Debian Jessie: debmirror da warnings del tipo NO_PUBKEY

Bueno, pues ya he migrado el servidor principal del centro a Debian Jessie y cuando lo estaba configurando para que crease y actualizase cada noche mirrors locales de los repositorios mas frecuentes mediante debmirror me he encontrado con que daba avisos del tipo NO_PUBKEY. En principio eso no impide que se cree el mirror, pero como son un poco maniático no me gusta quedarlo así. La solución, contada en el Paso 3 de esta entrada antigua pasa por añadir las claves dentro del directorio /root/.gnupg/... ya que debmirror se ejecuta desde el crontab con el usuario root.

El problema que me he encontrado es que si repetía los pasos dados en dicha entrada había varios repositorios que seguían dando warnings con debmirror. Buscando un poco he encontrado la forma de meter la clave directamente y en un único paso en /root/.gnupg sin que luego se produzcan los warnings.

Imagínemos que el aviso sea NO_PUBKEY CBF8D6FD518E17E1, pues bien, tendríamos que hacer:

# gpg --no-default-keyring --keyring ~/.gnupg/trustedkeys.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CBF8D6FD518E17E1

De esta manera se importa la clave gpg de CBF8D6FD518E17E1 directamente a /root/.gnupg/trustedkeys.gpg. Usamos el servidor hkp://keyserver.ubuntu.com:80 para sortear el firewall de la Red Educativa, tal como contamos en su día aquí.

En pocos días seguimos para bingo...a ver si puedo contar ya cosas de las pizarras Galneo, que de momento pintan muuuuuy bien.

debmirror deja de funcionar con wheezy-backports

En esta entrada contaba como crear unos mirrors de wheezy-backports y otros repositorios en nuestra red local para permitir una instalación y actualización más rápida de paquetes.

Hoy me he dado cuenta de que hacía al menos 15 días que no se sincronizaba el mirror de wheezy-backports y por tanto tampoco los equipos que se actualizaban desde él, provocando un fallo en pkgsync que acaba interrumpiendo todas las actualizaciones. Lanzando el comando debmirror a mano:

# debmirror -v --getcontent /var/www/mirrors/backports-wheezy/  --timeout=1200 \
--ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none \
--arch=i386,amd64 --ignore=disks-i386,amd64/ --section=main,contrib,non-free --method=http \
--host=ftp.es.debian.org --dist=wheezy-backports --root=debian

se empezaba a descargar algo pero a los pocos segundos quedaba congelado sine die, sin avanzar nada. Para otros repositorios si que funcionaba debmirror, pero probando para wheezy-backports desde otras redes (para descartar si era problema de mi red) también fallaba.

Después de estar un rato dando vueltas como pollo sin cabeza mi compañero Ricardo me ha dado la solución: añadir el parámetro "--diff none", de tal forma que queda:

# debmirror -v --getcontent /var/www/mirrors/backports-wheezy/  --timeout=1200 \
--ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none \
--arch=i386,amd64 --ignore=disks-i386,amd64/ --section=main,contrib,non-free --method=http \
--host=ftp.es.debian.org --dist=wheezy-backports --root=debian --diff=none

O modificando el script de creación del mirror, quedando:

#! /bin/sh

debug="$@"
arch=i386,amd64
base=/var/www/mirrors
.....
.....
destdir=$base/backports-wheezy
dist=wheezy-backports
section=main,contrib,non-free
allopt="$debug --timeout=1200 --ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none --arch=$arch --ignore=disks-$arch/ --section=$section --method=http"
defopt="$allopt  --host=ftp.debian.org --dist=$dist --root=debian --diff=none"
debmirror -v --getcontent $destdir/ $defopt

La causa, según cuenta Ricardo, es que para no se tenga que descargar el Packages entero por pequeñas modificaciones hay repositorios que usan archivos diff, conteniendo sólo los últimos cambios. Este método ha dejado de funcionar bien con debmirror, pero con diff=none le dices que ignore dichos archivos diff. ¡Gracias, Ricardo!.

Lo que voy a echar de menos los mirrors cuando los Windows que nos quiere poner la Junta de Extremadura empiecen a actualizarse de forma masiva en los centros educativos. Será la fiesta del bit. Aunque siempre podemos, como sugirió algún iluminado, desactivar las actualizaciones. Entonces será la superfiesta.

Bueno, pues ahí queda eso.

Cargar firmware desde cero a LG Optimus Hub E510 brickeado.

Después de jubilar mi LG Optimus Hub se me ocurrió recuperarlo y remozarlo para usarlo como reproductor de podcasts de Colectivo Burbuja, el Vórtice y otras radios online para cuando salgo a andar. Y si además puedo reutilizar hardware en teoría obsoleto para tener un iPod Touch lonchafinista mejor que mejor.

De esta estupenda colección de ROMs para mi móvil, la que mas me gustaba era la LiteHub: una Gingerbread ligera y pequeña (aunque, como cuento en la aventura interior, no va con la SIM de Vodafone pero ya me da lo mismo). En la carga volví a liarme de mala manera y acabé con el terminal brickeado. No entraba ni en el recovery y no había tampoco fastboot mode.

Carajo, había que instalar el sistema desde cero. Como muchos fabricantes (por ejemplo, Samsung con Kies/Odin o los moviles MTK con MTKDroidTools) en LG hay herramientas particulares para cargar la ROM en un móvil cascado (cosas del libre mercado perfecto: cada tornillo necesita un destornillador). Estas ROM son publicadas por LG en formato kdz y la herramienta se llama KDZ Firmware Updater. Los pasos son:

• Descargar e instalar los drivers universales LG "LGUnitedMobileDriver_S4981MAN37AP22_ML_WHQL_Ver_3.7.2".
• Descargar el KDZ_FW_UPD_EN.ZIP de cualquier sitio como éste, descomprimirlo, instalar MSXML y dejarlo listo para ejecutar el KDZ_FW_UPD.
• Descargar el fichero KDZ correspondiente a nuestro móvil y país desde este repositorio. Hay varias ROM KDZ para LG E510, pero la más adecuada es la V10B_00 de Movistar, ya que es la única que se deja rootear mas adelante. Las otras son mas modernas y están protegidas contra los métodos usuales de rooteo.
  

Para cargar la ROM entramos en KDZ_FW_UPD y configuramos:

• TYPE: 3GQCT
• PHONEMODE: DIAG
• KDZ FILE: seleccionamos archivo que KDZ que descargamos antes
• Ponemos el móvil en Emergency Mode: se apaga, se quita la batería un minuto, se pone de nuevo y se pulsa VOL+ y botón de encendido hasta que se enciende con una pantalla donde pone "Emergency Mode". Este es un modo parecido a Fastboot para cargar la ROM KDZ.

• Lo conectamos al USB del ordenador y dejamos que el Windows lo detecte correctamente.
• Pulsamos LAUNCH SOFTWARE UPDATE: empieza el baile en el que se muestran varios contadores en el log y durante el cual se puede reiniciar el móvil varias veces. Hay que esperar hasta que los contadores llegan a 0 y se muestra algo así como "Finished".

Una vez acaba, reiniciamos y nos encontramos una flamante ROM de Movistar, que no nos va a durar mucho. Recordemos que hemos elegido esta ROM entre todas las demás porque es la única que se deja rootear de una forma sencilla. Los pasos ahora son:

• Rootear con UnlockRoot23, según estas instrucciones.
• Una vez rooteada, ya podemos poner CWM Recovery, lo que permitirá cargar luego cualquier Custom ROM. Para ello descargaremos recovery-clockwork-5.0.2.7-e510.img y flash_image.zip y seguiremos el resto de instrucciones del enlace anterior.
• Una vez instalado el Recovery, descargamos la ROM LiteHub y la instalamos.

Un problema de todas las ROMs para este móvil es que tiene solo unos miserables 150-170Mb para aplicaciones de usuario, que se llenan enseguida (especialmente con los datos de las Google Apps, que bajan megas y megas no se con que finalidad). Lo que había hecho hasta ahora era instalar Link2SD para mover a mano algunas aplicaciones a la SD, pero no siempre soluciona las cosas y tarde o temprano sale el temido problema de "Memoria casi llena".

Esta vez quería probar otra cosa: instalar INT2EXT+, que usa de forma transparente la partición en formato "ext2/3/4" de la memoria SD para las aplicaciones que instalemos: con eso consigo tener una digna memoria de 900Mb para aplicaciones de una forma automática y sin más dolores de cabeza.

Al arrancar tenemos la ROM ligerita y minimalista, preparada para poder poner mis podcasts y aplicaciones de senderismo. Un par de apuntes más por si quiero explorar esos caminos en el futuro:

• Truco para meter, de forma bastante arriesgada, el Recovery CWM en un KDZ durante el flasheo.
• Truco para convertir una ROM KDZ en formato apto para flashear con el Recovery CWM.

Bueno, pues como aventuré las elecciones nos dejarían un panorama divertido. Entre eso y mis puñetas varias con Linux y sus variantes no hay manera de aburrirse.

Salud y aguas revueltas.