"Después del juego es antes del juego"
Sepp Herberger

sábado, 24 de septiembre de 2016

VirtualBoxing Windows (Parte II)

En la anterior entrada vimos como virtualizar Windows dentro de nuestros Xubuntu para satisfacer en nuestros Infolab las necesidades de todos, les haga falta Windows o no.

Con el sistema ya en despliegue tuve que hacer varias correciones menores que cuento aquí:

1. Cambios en la BIOS para que funcione VirtualBox.

Los PC usados son HP ProDesk 600 G2 SFF, que tienen Secure Boot activado en la BIOS por defecto. Los últimos kernel de Ubuntu están viniendo configurados para que si se detecta Secure Boot activado los drivers de terceros deban estar firmados para cargarlos en memoria. El driver de virtualbox es un problema aquí y firmarlo es un proceso complicado que habría que repetir con frecuencia con cada actualización.

La solución mas rápida es entrar con la tecla F10 en la BIOS durante el arranque, desactivar Secure Boot, borrando las claves del mismo y poniendo que el arranque sea solo en modo Legacy. Al guardar y reiniciar nos pedirá un código numérico a modo de CAPTCHA cutre para confirmar que lo hemos hecho a propósito y ya está. El driver de virtualbox podrá cargarse sin problema. Todo esto ya lo contamos en el apartado 2 de esta entrada.

También será necesario en la parte Avanzada de la BIOS activar el VTx para permitir la virtualización, ya que si no el virtualbox se queja al arrancar y aborta.

2. Cambios en el script de arranque.

Para poder arrancar la máquina virtual cpm un click del usuario, verificando que ya no había otra corriendo y mapear la carpeta $HOME del usuario dentro de la máquina virtual usábamos un script.

Tras varias pruebas apareció el problema de que la carpeta compartida se quedaba mapeada en la máquina virtual, lo cual daba problemas al cambiar de usuario. Con la línea en negrita que añado en el script se soluciona el problema: desmapeamos la carpeta compartida antes de mapearla de nuevo.
# cat /opt/VirtualBox\ VMs/run_vbox 
#!/bin/bash

#Poniendo esto  /etc/environment
#export VBOX_USER_HOME="/mnt/VirtualBox VMs/VirtualBox"
#en el arranque lo tendremos para todos los usuarios. Maquinas virtuales en local.

#Si cierran la ventana a lo bruto se hace un shutdown de la máquina. Esto al .vbox de 
#la máquina
#    

machine="Win10"

running=$(VBoxManage list runningvms | grep $machine)
if  [ -n "$running" ]
then
   zenity --error --text "La máquina $machine ya está funcionando"  
else
  #Si cierran la ventana a lo bruto se hace un shutdown de la máquina. Esto al .vbox de la máquina
  #    
  #o bien VBoxManage...
  VBoxManage setextradata $machine "GUI/LastCloseAction" "Shutdown"
  VBoxManage sharedfolder remove "$machine" --name "compartido"
  VBoxManage sharedfolder add "$machine" --name "compartido" --hostpath "$HOME" --automount
  VirtualBox --startvm $machine
fi

3. Problemas de permisos.

Como la máquina virtual completa es compartida por todos los usuarios y está en una carpeta común (/opt/VirtualBox VMs) hay varios ficheros que deben tener como propietario al usuario actual, para que pueda ejecutarla sin problema.

Para ello hace falta meter un script que se ejecute en el inicio de sesión y que lo haga como root (hay que cambiar permisos a unos ficheros de los que no somos propietarios). Está ultima condición descarta el uso de /etc/xdg/autostart/* y /etc/X11/Xsession.d/*. Para ejecutar un script en el inicio de sesión como root tenemos que usar la configuración de ligthdm, nuestro gestor de sesiones, metiendo un fichero en /etc/lightdm/lightdm.conf.d/ como.
# cat /etc/lightdm/lightdm.conf.d/15-vbox.conf 
[SeatDefaults]
# Seat defaults
# display-setup-script = Script to run when starting a greeter session (runs as root)
# greeter-setup-script = Script to run when starting a greeter (runs as root)
# session-setup-script = Script to run when starting a user session (runs as root)
# session-cleanup-script = Script to run when quitting a user session (runs as root)
session-setup-script=/opt/VirtualBox\ VMs/vbox_permisos
El script llamado es vbox_permisos, que hace:
# cat vbox_permisos 
#!/bin/bash
#Cambia el propietario de las ficheros de VirtualBox, para permitir el acceso al usuario que hace login
chown $USER:$USER "/opt/VirtualBox VMs/VirtualBox/VirtualBox.xml"
chown $USER:$USER "/opt/VirtualBox VMs/Win10/Win10.vbox"
Como se puede ve, hace se propietario al usuario que inicia sesión de "/opt/VirtualBox VMs/VirtualBox/VirtualBox.xml" y "/opt/VirtualBox VMs/Win10/Win10.vbox", que son los dos ficheros necesarios para arrancar la máquina virtual.

Con esto ya está todo solucionado y funciona sin problemas.... de momento.

Por último, recordemos la conveniencia de tener una copia de estos 2 últimos ficheros, los scripts y el fichero .vdi con la máquina virtual en lugar seguro de la máquina física, para hacer una restauración rápida si algún usuario avanzado de Windows nos desconfigura o borra algo.

miércoles, 21 de septiembre de 2016

Depurar errores de importación en controlies

Estamos a principios de curso y nuestro controlies echa humo con la importación de alumnos y profesores desde Rayuela. Antes de seguir, unos consejos para refrescar lo importante:
  • Controlies sólo importa ficheros de profesores y de alumnos. No de grupos, ya que esos datos van implícitamente dentro de los alumnos. El fichero XML de Grupos bajado de Rayuela no tiene ningún valor para controlies.
  • El formulario para importar los datos es el mismo tanto profesores como para alumnos...¿cómo distingue entre unos y otros?: pues por la extensión: si el fichero es un XML interpreta que es de profesores, si es un ZIP (que contiene un XML y las fotos) se interpreta que es de alumnos.
  • La casilla de "Borrar datos" solo debe marcarse en la primera importación del curso (normalmente hay varias importaciones a lo largo del año ya que las matriculaciones se realizan en varias oleadas) ya que borra todos los profesores/alumnos (según el caso) previos del árbol ldap antes de iniciar el proceso a modo de limpieza de datos obsoletos.
  • Si no se marca la casilla "Borrar datos" se integrarán los datos importados con los ya existentes previamente, siendo ignorados los profesores/alumnos que ya estuvieran en ldap. Por eso es aconsejable marcar la casilla al menos una vez con los alumnos y así deshacernos de aquellos que hayan abandonado el centro.
  • No hay que olvidar lanzar después el script crearCarpetas en el servidor principal para crear los homes Linux de los usuarios añadidos a ldap.

Cuando se realiza la importación no es infrecuente que se aborte con un "Internal server error" o similar. Veamos como solucionar esto o al menos saber que ha pasado:
  • Debemos asegurarnos de que no hay ninguna partición al 100% en el servidor principal. La importación se hace descomprimiendo datos en /tmp/rayuela-ldap y si la partición que contiene esta ruta se llena todo se va al traste.
  • Borrar /tmp/rayuela-ldap antes de importar tampoco viene mal, para liberar espacio y quitar "basura" de importaciones antiguas que pudieron quedar a medias.
  • Si sigue fallando hay que depurar, para ello borramos /var/web2py/applications/controlies/errors/* y lanzamos la importación para que se produzca de nuevo el error. En /var/web2py/applications/controlies/errors/... debería haberse creado un fichero con el volcado del error y en /tmp/rayuela-ldap deben estar además los ficheros temporales usados durante la importación.

El fichero en /var/web2py/applications/controlies/errors/... es un típico fichero de volcado de pila de web2py horrible y farragoso:
(dp1
S'output'
p2
S" 'ascii' codec can't encode character u'\\xe2' in position 2: ordinal not in range(128)"
p3
sS'layer'
p4
S'/var/web2py/applications/init/controllers/gestion.py'
p5
sS'code'
p6
S'# coding: utf8\nfrom applications.controlies.modules.Hosts import Hosts\nfrom applications.controlies.modules.Rayuela2Ldap import Rayuela  \nfrom applications.controlies.modules.SQLiteConnection import SQLiteConnection\nfrom applications.controlies.modules.Laptops import Laptops\nfrom applications.controlies.modules.LaptopsHistory import LaptopsHistory\nfrom applications.controlies.modules.Config import Config\nfrom applications.controlies.modules.Thinclients import Thinclients\nfrom applications.controlies.modules.Utils import Utils\nfrom applications.controlies.modules.Utils import LdapUtils\nimpo
......
......
......
S"u'Jo\\xe2o'"
p7197
sS'resultado'
p7198
S"u'Jo\\xe2o'"
p7199
sS'self'
p7200
S''
p7201
sssS'traceback'
p7202
S'Traceback (most recent call last):\n  File "/usr/lib/pymodules/python2.7/gluon/restricted.py", line 205, in restricted\n    exec ccode in environment\n  File "/var/web2py/applications/init/controllers/gestion.py", line 748, in \n  File "/usr/lib/pymodules/python2.7/gluon/globals.py", line 173, in \n    self._caller = lambda f: f()\n  File "/usr/lib/pymodules/python2.7/gluon/tools.py", line 2575, in f\n    return action(*a, **b)\n  File "/var/web2py/applications/init/controllers/gestion.py", line 218, in rayuela\n    todos=rayuela.gestiona_archivo()\n  File "applications/controlies/modules/Rayuela2Ldap.py", line 437, in gestiona_archivo\n
self.parsea_archivo("/tmp/rayuela-ldap/Alumnos.xml","alumno")\n  File "applications/controlies/modules/Rayuela2Ldap.py", line 249, in parsea_archivo\n    self.parse_nodo(nodo)\n  File "applications/controlies/modules/Rayuela2Ldap.py", line 236, in parse_nodo\n    usuario[info.nodeName]=self.asegura_codigos(dato)\n  File "applications/controlies/modules/Rayuela2Ldap.py", line 121, in asegura_codigos\n    return str(resultado).strip()\
nUnicodeEncodeError: \'ascii\' codec can\'t encode character u\'\\xe2\' in position 2: ordinal not in range(128)\n'
p7203
s.
La parte final es la interesante, he puesto en negrita lo relevante: se produce un error en /tmp/rayuela-ldap/Alumnos.xml, relacionado con la codificación Unicode de la cadena que aparece mas arriba S"u'Jo\\xe2o'. Habría que buscar esa cadena en Alumnos.xml por ver si viene en alguna codificación extraña y arreglarlo mano. Esto pasa a veces ya que los datos vienen desde Rayuela con codificaciones o caracteres extraños que controlies no sabe manejar.

Si no encontramos nada queda una última opción: seguir una estrategia "divide y vencerás" y realizar la importación grupo a grupo, en lugar de todo el alumnado completo, hasta dar con el que produce el error. Luego, dentro de ese grupo, hacerlo alumna a alumno hasta pillar al "culpable" y depurar.

Una vez localizado el dato erróneo será cuestión de editar el XML a mano para quitar lo que causa el fallo y lanzar de nuevo la importación. Si es el fichero de Alumnos no olvidar volver a meter Alumnos.xml dentro del ZIP para importar, respetando la estructura del ZIP original: el fichero Alumnos.xml en la raíz del mismo y las fotos en un directorio.

Bueno, pues esperemos que este año no haya muchos errores en estas lides.

lunes, 19 de septiembre de 2016

Configurando la VGA en los HP ProDesk 600 G2 SFF (Parte II)

Bueno, bueno, volvemos del verano con las uñas afiladas y muchas cosas en el tintero. Vamos a ampliar un post antiguo sobre los Infolab.

1. Usar driver propietario nvidia desde un repositorio PPA.

En la Parte I miramos como configurar la VGA de nuestro HP ProDesk en distintos escenarios. Recordemos que teníamos 2 tarjetas VGA
00:02.0 8086:1912 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 06) 
01:00.0 10de:1287 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1)  
Y que la nvidia la configurabamos con el driver propietario oficial de nVidia. Como este driver se instalaba mediante un fichero NVIDIA-Linux-x86_64-361.28.run y con varias preguntas de forma interactiva, era un proceso bastante poco operativo para hacer un despliegue masivo por muchas máquinas. Mis compañeros sugirieron otra forma que yo no había advertido para instalar el driver: mediante un repositorio PPA de Ubuntu que se actualice con los drivers propietarios nVidia. Para ello añadimos el repositorio:
# add-apt-repository ppa:graphics-drivers/ppa
# apt-get update
Y ahora el paquete con el driver:
# apt-get install nvidia-364
Hay varios paquetes que se informa que han funcionado: nvidia-361, nvidia-364 y nvidia-367. Pongo nvidia-364 porque al parecer es el que más compañeros han usado. Y ya está, de esta forma conseguimos tener el driver propietario de las nVidia sin tener que descargar el .run y ejecutarlo a mano. El resto del artículo anterior se mantendría igual.

2. Evitar problemas entre el Secure Boot de la BIOS UEFI y los drivers de terceros.

Otro problema que se nos puede presentar es que no se cargue el driver en el arranque. Es decir que:
# lsmod | grep -i nvidia
No muestre nada. Si intentamos cagarlo a mano:
# modprobe nvidia
Nos contestará con algo asi como "Required key not available" La causa de se explica en este enlace: básicamente consiste en que el kernel tiene activada una opción por la cual si encuentra en la BIOS UEFI el Secure Boot activado solo permitirá cargar drivers de terceros firmados previamente. Firmar drivers es un proceso bastante farragoso que habrá que repetir cada vez que se actualice el driver o el kernel.

Es mas sencillo para nuestro caso desactivar el Secure Boot, aunque implique ir por los PC uno a uno ya que no se puede automatizar. En caso el de los HP Prodesk 600 G2 pulsaremos F10 al arrancar en el equipo para entrar en la BIOS UEFI, iremos a Opciones Avanzadas/Seguridad y una vez allí desactivamos en el combo que sale el arranque Seguro UEFI, dejando solo el Legacy activado, y borramos las claves Secure Boot marcando la casilla. Una vez hecho esto guardamos y salimos de la BIOS.

En el siguiente arranque pide teclear a mano un úmero aleatorio de 4 digitos para confirmar que se quiere desactivar el arranque seguro, una vez hecho ya vuelve a cargar el driver nvidia y el problema desaparece. De igual manera que con el driver de la nvidia, esto soluciona problemas con otros drivers de terceros tales como:

-El driver de audio de este post.
-El driver nw_fermi de las pizarras Smart.
-El driver de VirtualBox.
-Etc, etc, etc.

Nos vemos pronto y ten por seguro que seguiremos sin Gobierno.

martes, 9 de agosto de 2016

A vueltas con el software de las PDI

Desde que empezaron a llegar pizarras digitales interactivas a los centros educativos hemos visto pasar ante nuestros ojos dispositivos de Interwrite, SmartBoard, Promethean, eBeam, Hitachi, Galneo y seguro que alguna artesanal hecha con el mando de la Wii. En algunos casos como Smart y Galneo la distribución ha sido masiva por todos los centros. En otros se han ido adquiriendo de forma esporádica o han llegado como premios por proyectos presentados por la comunidad educativa.

Cada una de estas pizarras tiene su propio software de manejo: Workspace para las Interwrite, SmartNotebook para las SmartBoard, Pandectas para las Galneo....Eso en principio no supone problema si vamos a usar la pizarra de la misma forma que una pizarra tradicional: un panel para escribir y borrar.

El problema viene cuando queremos sacar partido a lo que tenemos: guardar el trabajo para retomarlo más adelante, diseñar actividades interactivas, reutilizar las actividades realizadas por otros,.... En una jungla de distintos programas según la pizarra no hay manera de garantizar la reutilización de los contenidos. Como además se suelen guardar en formatos propietarios es casi imposible contar con herramientas de importación. Para mas INRI, el cambio de software de un aula y de un centro a otro acaba desalentando enormemente a los docentes que quieren introducirse en el uso de las PDI.

Creo que la única solución puede ser adoptar de forma oficial un software determinado que sea multiplataforma y que pueda usarse independientemente del hardware subyacente de la pizarra. A fin de cuentas es lo mas lógico, ¿no?: los programas que usamos para escribir manuales para imprimir, escanear documentos o grabar CD son independientes del dispositivo físico usado luego. ¿Por qué no habría de ser así en las PDI?.

En principio el Smart Notebook parece un buen candidato
, ya que se puede licenciar su para uso sobre otras pizarras y es un software ampliamente difundido en la comunidad educativa. Pero en mi opinión tiene varios problemas:

  • Es un software propietario: dependes de la empresa que lo desarrolla a la hora de sacar nuevas versiones, incluir mejoras y/o arreglar bugs.
  • Aunque en apariencia lo es, en realidad no es multiplataforma: para GNU/Linux quedó estancado en la versión 11, mientras que para Windows y OSX va por la versión 16. Lo mismo sucede con Interwrite Workspace y Pandectas: las versiones siguen líneas separadas de desarrollo a distintas velocidades y con distintas funcionalidades según el sistema operativo.
  • Puedes contratar servicios adicionales para que hagan versiones a medida para ti, pero la experiencia de otros proyectos es siempre lo misma: hay un periodo inicial de "luna de miel" en la que se atiende todo rápidamente, pero pasado el primer año la calidad del servicio va decayendo hasta que se abandona cualquier retroalimentación y posibilidad de continuar el trabajo.

Estos problemas son extensibles a cualquier solución propietaria por la propia idiosincrasia del software no libre.

La única manera que se me ocurre de evitar estos contratiempos es usando software libre y el único proyecto lo suficientemente avanzado que conozco es Open Sankoré.

  • Tiene la misma versión, 2.1.5 estable y 3.1 en desarrollo, para las 3 plataformas.
  • Está bajo licencia GPL y su código fuente es público y modificable por cualquiera, de tal forma que nuestras mejoras quedarían a disposición de la Comunidad Educativa a nivel internacional.
  • Tiene un repositorio púbico de recursos que se pueden reutilizar y al cual cualquiera puede contribuir.

Como desventajas se me ocurren:

  • Presumiblemente no tiene tantas funcionalidades como tienen los SW propietarios equivalentes. Eso es algo que deberían juzgar los expertos en el uso de PDI.
  • El repositorio github hace 2 años que no recibe actualizaciones, por lo que algún indocumentado que no sepa como funciona esto puede afirmar que es un "proyecto muerto". Bueno, está tan muerto como puede estarlo el Notebook de SmartBoard para Linux, que no recibe actualizaciones desde hace mas tiempo y que nos ha costado bastante trabajito hacerlo funcionar sobre Ubuntu Trusty (sin apoyo de Smart, of course). Si dedicas dinero el proyecto "resuciará" e irá progresando y estoy seguro de que es mas fácil hacer avanzar Open Sankoré que Smart Notebook.
  • No te darán soporte para hacerla funcionar con nuevas pizarras que se adquieran. No es problema: mi compañero Jaime ha hecho funcionar Open Sankoré con pizarras Galneo, aunque en principio no parecían compatibles. Normalmente es sencillo realizar estas tareas para un grupo tan preparado como son los administradores de los IES/CPR.

En conclusión:

  • Usar SW propietario es un parche cortoplacista que no vas a controlar nunca. Usar SW libre es un proyecto a medio y largo plazo en el que tú eres el dueño del producto.
  • Económicamente da lo mismo emplear el dinero en pagar licencias de SW propietario que invertirlo (usando recursos propios o recursos externos contratando con alguna empresa neutral) en mejorar un SW libre existente.
  • A nivel político-publicitario siempre se sacará mas rédito a hacer tu propio SW, siguiendo las peticiones y demandas de tu profesorado y poniendo de forma gratuita el resultado a disposición de otras Comunidades Autónomas y países.

Y esta es mi opinión. Me encanta discutir, así que se aceptan peros.

viernes, 5 de agosto de 2016

Xiaomi no mola

No todo es salir del paso y a veces lo que intentamos fracasa estrepitosamente, aunque esté considerado de mal gusto hablar de ello. Pues no será así hoy: de todas las cosas que me toca hacer hay veces que tiro horas por /dev/null sin lograr nada más que una merecida lección que me pone en mi sitio. Por ejemplo, si necesito bajarme los humos nada mejor que echar un rato con el ladrillo que antes era un Xiaomi Redmi 1S.

Me compré el móvil de segunda mano aproximadamente en julio de 2015. La gente contaba (y cuenta) maravillas sobre Xiaomi y sus estupendos productos, así que adquirí un móvil casi nuevo. Traía interfaz Miui vistosa y pulida, la cámara era bastante buena y en general el funcionamiento era ligero. Pero, vaya... la batería de 2000mAh se quedaba corta. No es tolerable que después de quitarlo del cargador a las 7:30 cuando llega la hora de comer, sin haber apenas tocado el móvil para una o dos llamadas breves y 4 whatsapps, estuviese la batería al 75%. Mis móviles Android anteriores, con menos batería y potencia no sufrían tal drenaje injustificado.

Buscando en Internet resulta que este comportamiento es normal ahora. Ya me ha pasado recientemente con otro móvil, un Doogee X5 Pro, que había que cargar a media tarde para poder usarlo hasta final de día (que es cuando usamos intensivamente el móvil los multipadres de estos tiempos). Por ese motivo ya no compro ningún móvil que tenga menos de 4000mAh de batería y directamente no me creo la historia de los que afirman que si, que les duran sus 2X00mAh hasta la noche con 4 horas de pantalla.

El Xiaomi Redmi 1S por lo visto podía mejorarse cambiando la ROM y poniendo luego un kernel ad-hoc que multiplicaba las horas de autonomía milagrosamente, ya que el software por defecto era bastante manirroto con el consumo de energía. Dediqué varios días a probar versiones sin ninguna mejora significativa que mereciese la pena ("...espera a que se calibre bien la batería, decían en los foros....¡ya!") ....hasta que sucedió la primera catástrofe.

Una noche cargué una ROM y al reiniciar no tenía señal de red telefónica. Ni 2G, ni 3G ni nada. Reinicié una vez mas y al volver tampoco tenía Wifi. Al día siguiente me puse a investigar y entonces me doy cuenta de que mi móvil ha perdido el IMEI y las MAC de la Wifi y el Bluetooth. Esos datos se guardan en diversas particiones del "disco duro" del móvil y por algún motivo se habían machacado. A partir de aquí aquí constato varias cosas:

  • Que la perdida de IMEIs, Baseband y MAC no es infrecuente en los Xiaomi.
  • Que si tienes CPU Mediatek es bastante sencillo fijar de nuevo el IMEI y otros datos perdidos, con el modo ingeniero o usando applicaciones de terceros como las Uncle Tool.
  • Que si tienes CPU SnapDragon, como es mi caso, estás jodido. No hay un método sencillo y los que probé no funcionaron.
  • No funcionó usando una esotérica aplicación llamada QPST y sus satélites QFil, eMMC downloader, etc.
  • No funcionó leyendo e intentando sacar algo en claro los delirantes, autoreferenciados y nada lógicos posts de la página turca de Androidbrick. Parecen una broma de Erdogan y los otomanos a Occidente en venganza por la batalla de Lepanto,
  • No funcionó pidiendo ayuda en los foros oficiales de Miui http://en.miui.com ni en los semioficiales http://miui.es, que además de tener una estética y contenido que parecerían naïf al mismo Doraemon tienen mucha paja entre la información relevante. Su único gran consejo era que "esperase a la siguiente ROM oficial y reflashease". Como si una ROM nueva fuera a traerme de vuelta las particiones perdidas.
  • Si que saqué claro que si tienes un móvil con SnapDragon no está de más hacer un backup de esas particiones usando adb y guardarlas en lugar seguro para restaurarlas si hay una catástrofe. Como dice mi amigo Pedro, mas vale un por si acaso que cien mecagoend10s. Aquí viene como hacerlo para un Redmi 1S como el mío. Para otros modelos las particiones no serían "mmcblk0p16_modemst1" y siguientes, pero no es díficil averiguar cuales son ya que la buena gente suele publicar eso para otros móviles.
    Hay incluso aplicaciones como ésta (manual) o ésta que te hacen el backup sin tener que teclear comandos mediante la shell del adb.
  • Por supuesto, intentar hablar directamente con Xiaomi o Qualcomm (fabricantes de los SnapDragon) usando sus soportes oficiales es como hablar con el Ser Inmutable de Parménides.
  • En la desesperación, encontré un post en indonesio en el que alguien compartía en Dropbox el backup de esas particiones. Lo descargué y lo probé sin éxito. En teoría eso equivale a clonar el IMEI y piensas que va a aparecer Jack Bauer por la ventana a detenerte, pero tampoco es para tanto.
  • La solución "oficial" es cambiar la placa base, pero si el móvil está fuera de garantía eso cuesta casi tanto como uno nuevo. Descartado.
Estaba resignado a usar el móvil de reproductor MP3, cámara de fotos y GPS, sin ninguna conectividad exterior, pero cualquier situación siempre es susceptible de empeorar: una mañana estaba cargando y se apagó para siempre. Nunca mas volvió a encender ni siquiera en modo Fastboot, aunque al conectarlo al puerto USB de un PC se detectaba algo durante un tiempo, al final no aparecía nada. Llevé el móvil a un par de técnicos y ambos me certificaron que tenía un ladrillo con la placa base frita. Llegados a este punto me rendí y dejé el móvil en un cajón. Pasado un año y aprovechando el tiempo libre del verano me decidí a darle una vuelta al tema. A lo largo del año habia ido acumulando alguna documentación nueva. Una de ellas era usar el método del cortocircuito para revivir al móvil: desmontándolo hay 2 puntos llamados "test point" que podemos puentear con un cable o unas pinzas y eso puede poner el móvil en un modo llamado "Qualcomm Download Mode o QDL" (que no es el modo Recovery ni Fastboot, sino otro modo un par de escalones mas cerca del Infierno) desde el que usando la herramienta MiFlash se podía cargar el firmware completo (usando una ROM Fastboot) y revivirlo. Los puntos a cortocircuitar uniéndolos son los dos círculos plateados bajo la ranura SIM izquierda:
Es importante deshabilitar de forma temporal el requisito de drivers firmados en Windows (o de forma permanente aquí) y preparar bien el cable para hacer el cortocircuto entre ambos test point. Para cortocircuitar yo he usado 3 pines para soldadura ya que casualmente la distancia entre el primero y tercero coinciden con la distancia entre los dos test point.
Para poder hacer el cortocircuito he unido ambos pines con un cable dupont hembra-hembra, quedando:
Una vez preparada la parte de hardware, instalamos MiFlash, deshabilitamos la firma de drivers en Windows, abrimos MiFlash y conectamos el cable USB de carga/datos al PC. Por otro lado, descargamos una ROM Fastboot para nuestro Redmi 1S y la descomprimimos, guardando los ficheros en una ruta corta y sin espacios en blanco, por ejemplo c:\armani (armani es el nombre en clave que pone Xiaomi al modelo Redmi 1S). Los ficheros descomprimidos estarán en c:\armani y c:\armani\images (por ejemplo debe haber un C:\armani\images\MPRG8626.mbn). En MiFlash le damos a Browse y seleccionamos el directorio c:\armani. A continuación realizamos el cortocircuito tocando primero el pin de la izquierda y con cuidado y lentamente el de la derecha, vigilando que no se desconecten, tal como se ve:
Sin soltar pinchamos el cable USB en el móvil y en este punto debe sonar el "tachán" de detección de un disposivo USB en Windows. Si no se detecta nada hay que desconectar repetir la realización del cortocircuito hasta que se detecte.
Una vez detectado, con la tercera mano damos al botón de actualizar en MiFlash y vemos que ya aparece un COMx conectando con el móvil en QDL mode (si lo listamos con lsusb aparece como 05c6:9008). Esto es todo un avance, ya que traemos el móvil desde un estado de muerte clínica y ahora al menos parece dispuesto a interactuar. ¿Que pasa si soltamos los cables y quitamos el cortocircuito aquí?. Mi experiencia es que el móvil ya está en modo QDL y no hace falta seguir cortocircuitando ambos test point. De todas maneras, también he probado a hacer todo manteniendo el cortocircuito. Continuemos: ahora le damos al botón "Flash" de MiFlash y comienza el proceso de flasheo de la ROM y vemos como van apareciendo mensajes en pantalla. Si todo va bien en unos minutos acaba todo y el móvil reinicia mostrando flamante el sistema operativo. En mi caso no va bien: tras 10 o 15 segundos se queda en un "wait device connect..." y al final acaba dando un error diciendo que los drivers no están firmados. No es eso, el error sucede tras el "Reboot to mini kernel" :
[00001794]CreateManagedObject(1392): Error no especificado(0x80131604)
[00001794]GetFactoryObject(1436): Error no especificado(0x80131604)
[00001794]CreateManagedObject(1392): Se ha intentado cargar un programa con un formato incorrecto.(0x8007000b)
[00001794]GetFactoryObject(1436): Se ha intentado cargar un programa con un formato incorrecto.(0x8007000b)
[00001794]GetFactoryObject(1457): El servicio especificado no existe.(0x800704db)
[00001794]GetSearchPath(1512): El servicio especificado no existe.(0x800704db)
[00001794]StartFlash(13): El parámetro no es correcto.(0x80070057)
[00001E64]CEmergencyFlasher::IsQPSTServer(655): No implementado(0x80004001)
[00001E64]COM10 0.05 Load programmer "C:\armani\images\MPRG8626.mbn"
[00001E64]DownloadFlashProgrammerDMSS(625): Se ha intentado cargar un programa con un formato incorrecto.(0x8007000b)
[00001E64]DownloadFlashProgrammer(946): Se ha intentado cargar un programa con un formato incorrecto.(0x8007000b)
[00001E64]COM10 0.05 Open programmer "C:\armani\images\MPRG8626.mbn"
[00001E64]COM10 0.05 Open serial port "\\.\COM10"
[00001E64]COM10 0.05 Receiving hello packet
[00001E64]COM10 0.05 Send hello response
[00001E64]COM10 0.05 ReadDataPacket id 13, offset 00000000, length 80
[00001E64]COM10 0.05 ReadDataPacket id 13, offset 0x000050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x001050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x002050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x003050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x004050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x005050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x006050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x007050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x008050, length 4096
[00001E64]COM10 0.06 ReadDataPacket id 13, offset 0x009050, length 972
[00001E64]COM10 0.06 EndTransferPacket id 13, status 0
[00001E64]COM10 0.06 Send done packet
[00001E64]COM10 0.06 Open boot file "C:\armani\images\8626_msimage.mbn"
[00001E64]COM10 0.06 Open serial port "\\.\COM10"
[00001E64]COM10 0.06 Send hello command 0
[00001E64]COM10 0.08 Enable trusted security mode
[00001E64]COM10 0.08 Open EMMC card USER partition
[00001E64]COM10 0.13 StreamWrite address 00000000, size 40960
[00001E64]COM10 0.20 StreamWrite address 0x00a000, size 40960
[00001E64]COM10 0.28 StreamWrite address 0x014000, size 40960
[00001E64]COM10 0.36 StreamWrite address 0x01e000, size 40960
[00001E64]COM10 0.44 StreamWrite address 0x028000, size 40960
[00001E64]COM10 0.52 StreamWrite address 0x032000, size 40960
[00001E64]COM10 0.59 StreamWrite address 0x03c000, size 40960
[00001E64]COM10 0.66 StreamWrite address 0x046000, size 40960
[00001E64]COM10 0.73 StreamWrite address 0x050000, size 40960
[00001E64]COM10 0.83 StreamWrite address 0x05a000, size 40960
[00001E64]COM10 0.89 StreamWrite address 0x064000, size 40960
[00001E64]COM10 0.95 StreamWrite address 0x06e000, size 40960
[00001E64]COM10 1.02 StreamWrite address 0x078000, size 40960
[00001E64]COM10 1.09 StreamWrite address 0x082000, size 40960
[00001E64]COM10 1.16 StreamWrite address 0x08c000, size 40960
[00001E64]COM10 1.22 StreamWrite address 0x096000, size 40960
[00001E64]COM10 1.31 StreamWrite address 0x0a0000, size 40960
[00001E64]COM10 1.38 StreamWrite address 0x0aa000, size 40960
[00001E64]COM10 1.44 StreamWrite address 0x0b4000, size 40960
[00001E64]COM10 1.52 StreamWrite address 0x0be000, size 40960
[00001E64]COM10 1.58 StreamWrite address 0x0c8000, size 40960
[00001E64]COM10 1.66 StreamWrite address 0x0d2000, size 40960
[00001E64]COM10 1.75 StreamWrite address 0x0dc000, size 40960
[00001E64]COM10 1.84 StreamWrite address 0x0e6000, size 40960
[00001E64]COM10 1.91 StreamWrite address 0x0f0000, size 40960
[00001E64]COM10 1.98 StreamWrite address 0x0fa000, size 40960
[00001E64]COM10 2.06 StreamWrite address 0x104000, size 40960
[00001E64]COM10 2.14 StreamWrite address 0x10e000, size 40960
[00001E64]COM10 2.22 StreamWrite address 0x118000, size 40960
[00001E64]COM10 2.30 StreamWrite address 0x122000, size 40960
[00001E64]COM10 2.38 StreamWrite address 0x12c000, size 40960
[00001E64]COM10 2.45 StreamWrite address 0x136000, size 40960
[00001E64]COM10 2.53 StreamWrite address 0x140000, size 40960
[00001E64]COM10 2.61 StreamWrite address 0x14a000, size 40960
[00001E64]COM10 2.69 StreamWrite address 0x154000, size 40960
[00001E64]COM10 2.78 StreamWrite address 0x15e000, size 40960
[00001E64]COM10 2.88 StreamWrite address 0x168000, size 40960
[00001E64]COM10 2.94 StreamWrite address 0x172000, size 40960
[00001E64]COM10 3.02 StreamWrite address 0x17c000, size 40960
[00001E64]COM10 3.09 StreamWrite address 0x186000, size 17920
[00001E64]COM10 3.13 Close EMMC card USER partition
[00001E64]COM10 3.14 Reboot to mini kernel
[00001E64]COM10 3.19 Wait device connect 0
[00001E64]COM10 4.22 Wait device connect 1
[00001E64]COM10 5.25 Wait device connect 2 
[00001E64]COM10 6.28 Wait device connect 3
[00001E64]COM10 7.31 Wait device connect 4
[00001E64]COM10 8.33 Wait device connect 5
[00001E64]COM10 9.38 Wait device connect 6
[00001E64]COM10 10.41 Wait device connect 7
[00001E64]COM10 11.44 Wait device connect 8
[00001E64]COM10 12.47 Wait device connect 9
[00001E64]COM10 13.50 Wait device connect 10
[00001E64]COM10 14.53 Wait device connect 11
[00001E64]COM10 15.56 Wait device connect 12
Y de aquí no salimos, parece que la carga del MiFlash no pasa de los primeros estadios. He probado diversas ROM y versiones de MiFlash por si fuera eso, sin éxito. A intentar hacerlo con la batería puesta de forma precaria, sin éxito. Y poco mas: mi móvil está tan dobleplusbrickeado que ni el QDL mode acaba de traerlo a la vida. Abandono de nuevo con el rabo entre las piernas y 6 u 8 horas de trabajo improductivo. Quizá el próximo año tenga mas soluciones o bien tenga que usar algo parecido JTAG para flashear directamente el dispositivo por hardware... No, en serio, creo que si no consigo una placa base barata lo que haré será venderlo por piezas. Esto ha sido un fracaso absoluto, con una serie de catástrofes inexplicables (¿borrarse el IMEI al actualizar una ROM? ¿no poder corregir ese IMEI? ¿borrarse el bootloader o algo similar de forma espontánea?) y ni Xiaomi ni Qualcomm han ayudado mucho. Como uno ya tiene una edad y eso le da el derecho humano a tener mas manías.... a partir de ahora Xiaomi y Qualcomm:


Vamos a disfrutar de la vida, que sin gobierno se vive muy bien y hasta nos perdonan la desviación del déficit nuestros amigos de la UE para no humillarnos. Estos imbéciles se piensan que yo soy tonto...

viernes, 29 de julio de 2016

Pico Proyector Acer C112 DLP en Ubuntu 14.04 y 16.04

Estos días estoy jugando con un mini proyector Acer C112 DLP para hacerlo funcionar. Es un aparato curioso, que no tiene entrada VGA sino que se conecta por USB y con un programa cliente (EZ Display) se envía en tiempo real la pantalla desde el PC al proyector. No tiene mucha resolución ni luminosidad, pero está dentro de los márgenes que se esperan en este tipo de proyectores.


En principio el aparato solo trae el driver/programa cliente para Windows XP (aunque si insistes y pruebas al final puedes hacerlo funcionar en Windows 7) y punto pelota. Que maravilla, un aparato comprado hace pocos años que no funciona ni con Linux ni con Windows 8 y 10, vamos, que estos de Acer se han lucido con el soporte.

En esta páginaofrecen unos drivers/software para hacerlo funcionar en Windows 8 y 10. Parece un desarrollo propio de un programador al margen de Acer y al parecer hay que pagar algo, aunque el precio es bastante reducido (15$ es poco por poder seguir utilizando el aparato).

Para Linux, en cambio, tenemos a un héroe llamado Antonio Ospite (muy majo y atento que responde a cualquier consulta rápidamente) que estuvo sniffeando junto a Reto Schneider el tráfico USB windows-proyector y desensamblando el driver hasta poder hacer una librería y una aplicación en Linux que funciona perfectamente tal como funciona su equivalente Windows: el proyecto libam-7xxx, que soporta varios picoproyectores tales como:

  • Acer Series C pico projectors (C20 C110 C112 C120)
  • Philips/SagemCom PicoPix projectors (PPX 1020, PPX 1230, PPX 1430, PPX 1630)
  • CEL-TEC MP-01
  • Otros chinos

Para Ubuntu 16.04 es sencillo, instalamos estos paquetes desde repositorios:
ii  libam7xxx0.1                                 0.1.6-2                                    amd64        library for accessing am7xxx based devices
ii  libam7xxx0.1-bin                             0.1.6-2                                    amd64        library for accessing am7xxx devices - utilities
ii  usb-modeswitch                               2.2.5+repack0-1ubuntu1                     amd64        mode switching tool for controlling "flip flop" USB devices
ii  usb-modeswitch-data                          20151101-1                                 all          mode switching data for usb-modeswitch
Aquí tuve un pequeño problema un par de días: pinchaba el dispositivo y tras cierta una actividad de disco se quedaba todo quieto. Mirando con lsusb los dispositivos conectados no aparecía nada. Mirando el syslog se ve como se detecta algo, se prueban unos driver y al final todo acaba diciendo:
Jul 25 11:37:48 pc kernel: [ 5603.550891] option 1-8:2.0: device disconnected
Tras consultar con Antonio y sugerirme varias pruebas (desinstalar usb-modeswitch, quitar el módulo option de memoria, desinstalar libmtp-runtime) al final ha empezado a funcionar solo. Pienso que coincide con que he actualizado el kernel a 4.4.0-21-generic #37-Ubuntu, pero no estoy seguro.

Bueno, ahora pinchamos el dispositivo y haciendo lsusb debe aparecer primero como 1de1:1101 (dispositivo de almacenamiento, conteniendo los drivers de Windows XP) y en unos instantes usb-modeswich lo cambia a 1de1:5501, que es el proyector en si. Como no hay driver para él, no aparece ningún dispositivo que lo maneje. No importa, la aplicacion am7xxx-play envía directamente lo que le digamos por el puerto USB sin intermediarios, usando:
# am7xxx-play -f x11grab -i :0
Enviamos en tiempo real el contenido de la pantalla tal como lo hace EzDisplay. Si se mira la ayuda de am7xxx-play se verán opciones para modificar resolución, calidad, conexiones en tiempo real a otras fuentes de vídeo (cámaras, páginas web, etc). Vamos, una pequeña maravilla....¡gracias!.

Después de esto me he visto en la necesidad de usarlo en Ubuntu 14.04 con el problema de que no hay paquetes para ellos en repositorios. En https://ao2.it/debian/ hay varios paquetes compilados para Debian, pero ninguno acababa de encajar en el Ubuntu 14.04, siempre daban problemas con libavcodec5X y satélites (esos paquetes están relacionados con ffmpeg y continuamente dan problemas de compatibilidad con otras aplicaciones, parece ser que tienen un desarrollo fuertemente acoplado y cada versión es incompatible con el resto) ya que necesitaban unas versiones que no son las que trae Ubuntu 14.04 (libavcodec54 concretamente).

¿Solución?. Pues cómo en los viejos tiempos: vamos a compilar (y cumplimos la sentencia windowchista de que siempre estamos compilando los hijos de Linux). Antonio lo pone bastante sencillo: tenemos un repositorio git de donde solo hay que descargar y compilar. La última versión es la 0.1.6-2, pero es incompatible con Ubuntu 14.04. Para ahorrarme rollo ya digo que la última versión compatible es la 0.1.4-3, liberada hace 2 años.

Sin usar comandos git podemos descargarla directamente desde https://git.ao2.it/libam7xxx.git/commit/a49ffce85139aaf1fc2e2e79dd6c65ad7e7f523c en el enlace "snapshot".

Una vez descargado, descomprimimos el .tar.gz y seguimos los pasos del documento HACKING.asciidoc contenido en él:
 #cd libam7xxx-a49ffce
# aptitude install cmake libusb-1.0-0-dev libavformat-dev libavcodec-dev libavdevice-dev libswscale-dev
# mkdir build
# cd build
# cmake ../
# make 
Una vez hecha la compilación, en libam7xxx-a49ffce/build están los ejecutables y librerías. Podría hacer un paquete Debian para ellos, pero no, voy a instalar como en los viejos tiempos de Slackware:
 # make install
Con esto se copia todo a su sitio y si pinchamos el cañon en el USB ya podremos hacer:
# am7xxx-play -f x11grab -i :0
Una última nota: el fichero HACKING.asciidoc cuenta que es posible hacer funcionar am7xxx-play en Windows para que nos funcione allí aunque Acer no haya sacado drivers... ¿saben cómo? ¡Compilando!.

domingo, 24 de julio de 2016

DRBL no live.

Ozú que caló y cuanto trabajo en los finales del curso. Es como una ginkana sin premio.

Mi compañero Esteban nos enseñó y nos ha ampliado varias veces como usar DRBL para realizar clonaciones multicast masivas de PC, de tal manera que nos hemos ahorrado mucho tiempo y hemos podido realizar de manera muy eficiente la preparación de portátiles de un curso para otro.

Aunque he usado muchas veces el sistema de arrancar DRBL desde un pendrive, realizar los pasos de la guía de Esteban y cargar las imágenes de los portátiles de 10 en 10, esta vez y por motivos que no vienen a cuento, pensé en modificar un sistema ya instalado en un portátil para meter los scripts DRBL dentro y clonar desde alli. Sin pendrives live ni nada. El resto del tiempo el portátil tendrá un uso normal y podré recurrir a él cada vez que tenga que hacer una clonación multicast.

La principal (y seguramente la única) ventaja es que toda la parte de la configuración del entorno DRBL solo tendría que hacerla una vez: en la instalación. Con DRBL live esto es una secuencia de pasos de configuración bastante pesada que tienes que hacer con cada nuevo arranque, en cambio en un sistema instalado solo lo tendrias que hacer la primera vez y quedaría el entorno semiconfigurado.

Para ello me he guiado por este enlace y este otro, así como la página dedicada a la instalación de DRBL, aparte (como no podría ser de otra forma) del blog de Esteban.

Enumeremos la secuencia de pasos:

1) Sistema: partimos de un portátil ya funcional, en mi caso un Netbook Inves con Xubuntu 14.04 instalado.

2) Instalación del software.

Empezamos añadiendo el repositorio de DRBL:
# cat /etc/apt/sources.list
.......
deb http://drbl.sourceforge.net/drbl-core drbl stable
Importamos la clave GPG y actualizamos los índices:
# wget http://drbl.sourceforge.net/GPG-KEY-DRBL
# apt-key add GPG-KEY-DRBL
# apt-get update
Instalamos el entorno DRBL y todas sus dependencias (si tenemos pkgsync no olvidemos incluir "drbl" en el mayhave).
# apt-get install drbl
# /usr/sbin/drblsrv -i
Todas las dependencias están ya dentro del mismo paquete, asi que con eso tenemos el entorno instalado y podemos pasar a configurarlo:

3) Configuración del entorno DRBL:
# drbl-push -i 
Esto nos hará una serie de cuestiones que podemos responder tal y como indican en los enlaces indicados anteriormente, en especial este del blog de Esteban.

En mi caso el directorio /tftpboot estaba en la partición raíz y alli apenas había espacio para meter todo lo que hace falta para el entorno, asi que lo he metido dentro de /home, que está en otra partición donde hay espacio de sobra. Luego he creado un enlace simbólico desde /tftpboot y tan pancho:
# mkdir /home/tftpboot
# ln -sf /home/tftpboot /tftpboot
# drbl-push -i 
La configuración generada por drblpush se guarda en /etc/drbl/drblpush.conf y podemos reutilizarla en otra ocasión o moverla de una máquina a otra usando el comando:
# drbl-push -c /etc/drbl/drblpush.conf
De esta manera nos ahorramos la tediosa ronda de preguntas. En mi caso (y en el tuyo deberia suceder lo mismo) este fichero queda:
# cat /etc/drbl/drblpush.conf

#Setup for general
[general]
domain=drbl.org
nisdomain=penguinzilla
localswapfile=yes
client_init=graphic
login_gdm_opt=login
timed_login_time=
maxswapsize=128
ocs_img_repo_dir=/home/partimag
total_client_no=20
create_account=
account_passwd_length=8
hostname=linex-
purge_client=no
client_autologin_passwd=
client_root_passwd=
client_pxelinux_passwd=
set_client_system_select=yes
use_graphic_pxelinux_menu=yes
set_DBN_client_audio_plugdev=yes
open_thin_client_option=no
client_system_boot_timeout=5
language=es_ES.UTF-8
set_client_public_ip_opt=no
config_file=drblpush.conf
collect_mac=no
run_drbl_ocs_live_prep=yes
drbl_ocs_live_server=
clonezilla_mode=full_clonezilla_mode
live_client_branch=alternative
live_client_cpu_mode=i386
drbl_mode=full_drbl_mode
drbl_server_as_NAT_server=no
add_start_drbl_services_after_cfg=yes
continue_with_one_port=

#Setup for eth0:0
[eth0:0]
interface=eth0:0
range=200-219
Nótese en range que he puesto un rango de 20 ip. Nunca voy a clonar mas de 20 PC a la vez, pero ese parámetro puedes variarlo en función de tus necesidades.

4) Lanzar la clonación.

Bueno, pues todos los pasos anteriores se hacen una sola vez y ya queda el entorno preparado para dar soporte de clonación cuando así lo requiramos, todo lo anterior correspondería a los pasos 1-21 descritos en este manual de Esteban. Ahora el portátil lo usaremos de forma normal (en mi caso es un portátil que usa habitualmente un alumno) y cuando queramos utilizarlo para realizar una clonación multicast haremos simplemente los siguientes pasos:

  • Meter las imágenes de clonación en directorios dentro /home/partimag si no estaban antes. Otra opción es pinchar un dispositivo externo de memoria y hacer que /home/partimage apunte al directorio de las imágenes usando "mount --bind"
  • Parar el servicio network-manager para que no interfiera en configuración drbl de la red.
  • Configurar la red con las direcciones correctas en eth0 y eth0:0.
  • Arrancar el servidor de clonación y responder a sus preguntas básicas sobre la imagen a cargar, el número de equipos a clonar, etc. (pasos 22 a 34 del manual de Esteban)
  • Levantar los servicios dhcp y tftp para que sirvan las ip y los clientes de clonación de imágenes.

Una vez hecho esto, podemos arrancar los clientes para que carguen el sistema por PXE y esperar a que empieze la clonación multicast.

Por comodidad estos pasos los he metido en un script que dejo en /root/lanza-clonacion.sh:
#!/bin/bash
service network-manager stop
ifconfig eth0 up
ifconfig eth0 192.168.1.1 netmask 255.255.255.0
ifconfig eth0:0 up
ifconfig eth0:0 192.168.100.254 netmask 255.255.255.0
/usr/sbin/dcs
service isc-dhcp-server restart
service tftpd-hpa restart
exit 0
De esta manera ejecuto el script, respondo a las 4 o 5 preguntas sobre que quiero clonar y donde y ya está. Incluso esa parte se puede automatizar: el comando /usr/sbin/dcs acepta parámetros para que no haga preguntas, quedando por ejemplo así:
 drbl-ocs -b -g auto -e1 auto -e2 -r -x -j2 -sc0 -p poweroff --clients-to-wait 10 --max-time-to-wait 300 -l es_ES.UTF-8 startdisk multicast_restore xubuntu-portatiles-workstation-amd64 sda
De esta manera configuramos DRBL para enviar la imagen llamada "xubuntu-portatiles-workstation-amd64" en el disco sda de 10 portátiles, esperando 300 segundos antes de comenzar la clonación.

Nota: aunque no lo he dicho la infraestructura de hardware sería la que propone Esteban: un switch aislado de la red del centro (mejor si no es gestionable, dan menos problemas con el multicast) y conectados a él los portátiles o equipos a clonar, así como el portátil que nos hace de servidor.

Hasta pronto, ahora en julio-agosto intentaré sacar varios posts plúmbeos que tengo pendientes como este. También hablaré del gobierno.