Incidencias de la última actualización en Ubuntu 16.04. Análisis y propuesta de solución.

Saludos.

Tras implantar la versión 16.04 en nuestro centro llevamos dos meses de trabajo intensivo intentado remediar una curiosérrima incidencia. Por partes:

a) Dos tipos de pizarras; bastantes modelos antiguos (no recuerdo el número, pero los de borde ancho, con bafles incorporados, lápiz con punta de plástico y no táctiles para simplificar) y dos nuevas (borde estrecho, sin bafles incorporados y táctiles, con lápiz de punta de tela en vez de plástico).

b) Sistema operativo Linkat 16.04 (Ubuntu 16.04). Actualizado.

Cada pizarra es servida por una torre específica que puede funcionar tanto con un usuario local como con un usario remoto por LDAP; en ambos casos la pizarra ha de funcionar.

Actualmente ser requiere un simple expediente mecánico para que funcionen, pero la idea es que eso no sea necesario, como hasta ahora... Lo expongo:

1.- Se arranca la torre; se puede observar el proceso de conexión de la pizarra con la torre mientras el sistema se levanta simplemente en el botón de calibración y sus cambios de color. Acaba en blanco lo cual se supone que es el reconocimiento completo y la conexión válida. Es decir, el activdriver funciona perfectamente.

2.- Arranca automáticamente un usuario aula el cual es local para poder trabajar directamente en el aula. Al arrancar este usuario entre el software de arranque automático se incluye el activmgr. Dícese, el icono en el panel desde donde se accede a la configuración y al calibrado.

3.- Tras eso, se activaría el activinspire y tendríamos la pizarra en servicio.

Esa es la teoría... La práctica es que el lanzador del activmgr se queda colgado y no avanza. Si llamas al activinspire se queda bloqueado en el arranque y no sigue adelante. De entrada, diríamos que es un fallo general y se acabó; una montaña de dinero a la basura.

Pero... Si arrancas sin el USB de la pizarra conectado -o lo quitas cuando ya ha entrado el usuario-, el programa activmgr se carga sin el menor problema, aparece el icono correspondiente en el panel y, al conectar el cable, reconoce la pizarra. Ya puedes trabajar sin problemas.

Hemos descartado un fallo de conexiones puesto que el comportamiento es IDÉNTICO en todas las pizarras... del modelo viejo. Con el nuevo no pasa. Curioso cuanto menos.

Hemos descartado que sea una entrada demasiado rápida del programa activmgr puesto que hemos forzado un retraso de hasta dos minutos en el lanzamiento (sleep 120 añadido al script de lanzamiento); nada.

El único procedimiento funcional es el descrito, y es adecuado y no da fallos. Dícese: ¿Qué señal está enviando -o no enviando- la pizarra (VIEJA, recordémoslo; la nueva no da ese problema. No da ningún problema, de hecho) para que no deje arrancar el gestor de configuración? ¿Nos pueden dar alguna respuesta?

Por otro lado, hemos abandonado las otras líneas y nos estamos centrando, simplemente, en la creación de un script que entre en acción antes que activmgr.sh y apague electrónicamente el dispositivo de la pizarra /dev/ACTIVBoard1 llame a activmgr.sh y vuelva a levantar el dispositivo. Básicamente, hacer de manera electrónica lo que estamos haciendo mecánicamente.

Es importante solventarlo porque la mayoría del profesorado considera molesta esa maniobra -necesaria e imprescindible para poder trabajar-. También nos gustaría saber porqué la incidencia sólo afecta al modelo viejo ¿quizá el módulo táctil ha sido tan integrado en el nuevo software que no se puede funcionar sin el? Sería absurdo. Si fuera así TAMPOCO funcionaría con esta maniobra.

A la espera de su respuesta, quizá incluso del script que les estamos proponiendo. Muy amables.

Comentarios

  • Adam H PrometheanAdam H Promethean Publicaciones: 385 admin
    Hola,

    Gracias por su aporte. Primero de todo, es importante mencionar que LinKat no es un sistema operativo soportado oficialmente por Promethean. Por favor consulte la página siguiente - https://support.prometheanworld.com/es/content/activdriver-requisitos-sistema

    Por eso, no podemos garantizar que nuestros productos funcionan correctamente dado que no han sido probado con este sistema.

    Es verdad que soportamos Ubuntu 16.04 pero recientemente ha salido un nuevo kernel que ha provocado problemas con el ActivDriver.

    En cuanto a las pizarras antiguas, necesitan un kernel para funcionar. Este kernel viene con el ActivDriver.
    Con las pizarras nuevas, no necesitan un kernel para funcionar, dado que usan los drivers HID del sistema operativo.

    Para entender un poco más lo que pasa, por favor responde a las preguntas siguientes:
    1/ Si la instalación de LinKat es una instalación "fresca" solamente con ActivDriver instalada, ¿la pizarra funciona?
    2/ ¿Los ordenadores tienen puertos USB 3.0? Si es así, se puede desactivar el modo USB 3.0 en el BIOS, a veces llamado xHCI

    Dado que esta versión del sistema nos parece basado en Ubuntu 16.04, puede ser que este problema pasa solamente con la versión más reciente. Puede ser que este sistema operativo también tiene un kernel que no funciona con ActivDriver, como en el caso de Ubuntu 16.04.
    O, puede ser la configuración del chipset que controla la comunicación entre la pizarra y el ordenador.

    Si quieren, podemos pasar en interno un pedido para que LinKat sea un sistema operativo soportado oficialmente, pero no podemos garantizar que será abordado.

    Cordialmente,
    Adam

    El Soporte Técnico de Promethean
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    Saludos. Muy agradecido por su respuesta y paso a responder por partes:


    LinKat no es un sistema operativo soportado oficialmente por Promethean
    Linkat actualmente es, excepto por una serie de modificaciones que no afectan al nucleo del sistema, un Ubuntu. El montaje de unidades remotas, los perfiles de usuario LDAP o los microajustes que se puedan hacer para optimizar el rendimiento de maquinaria que no sea de última generación no afectan al nivel de controladores de la pizarra.

    En cuanto a las pizarras antiguas, necesitan un kernel para funcionar. Este kernel viene con el ActivDriver.
    Con las pizarras nuevas, no necesitan un kernel para funcionar, dado que usan los drivers HID del sistema operativo.
    Gracias por la aclaración, eso explica algunas diferencias.


    En cuanto a las preguntas:
    1/ Si la instalación de LinKat es una instalación "fresca" solamente con ActivDriver instalada, ¿la pizarra funciona?
    No tiene nada que ver, el comportamiento es idéntico en instalación limpia, en subida de versión y en imagen clonada. Incluso el proceso de purgar todo el software de pizarra y reinstalarlo repite la incidencia: Funciona en el momento de la instalación y el problema se da en la interacción con el arranque de la máquina.

    El fallo está desde el primer prototipo de 16.04, ya el año pasado -momento en el cual desarrollamos el primer prototipo-. Se repitió en la maqueta de este verano, momento en el cual ser eligió la 16.04 puesto que el prototipo de 18.04 -que hubiera sido el ideal- no era funcional (el problema con el kernel 4.15, ya lo sé).

    2/ ¿Los ordenadores tienen puertos USB 3.0? Si es así, se puede desactivar el modo USB 3.0 en el BIOS, a veces llamado xHCI
    Inicialmente atribuímos el fallo a un defecto el cable, controladora o puertos del ordenador, ya que estamos hablando de un core2duo de segunda mano con 4GB de RAM, sin puertos USB 3. Suficiente para gestionar eso y más pero con muchos años de trabajo tras el. Esta tesis buenista perdió validez  simplemente porque con la extensión de la imagen al resto de máquinas -cada una con un origen diferente- se repite exactamente igual en todos ellos, independientemente de la generación del procesador, el puerto USB afectado o la memoria del equipo.

    Dado que esta versión del sistema nos parece basado en Ubuntu 
    16.04, puede ser que este problema pasa solamente con la versión más 
    reciente. Puede ser que este sistema operativo también tiene un kernel 
    que no funciona con ActivDriver, como en el caso de Ubuntu 16.04.
    Ya respondí antes. Es Ubuntu, con kernels de Ubuntu y sí que funciona... siempre que se haga lo que describí al principio puesto que hablo de máquinas actualizadas completamente el lunes, 19 de Noviembre de 2018, con el último kernel disponible.

    O, puede ser la configuración del chipset que controla la comunicación entre la pizarra y el ordenador.
    ¿La configuración del chipset funcionaría con un montaje posterior a la activación del usuario y no con el proceso automático? Me suena... raro, pero si fuera así ¿porqué afecta a máquinas con un chipset diferente unas de otras? Parece poco probable. En caso de que fuera así ¿qué solución habría?

    Si quieren, podemos pasar en interno un pedido para que LinKat sea un sistema operativo soportado oficialmente, pero no podemos garantizar que será abordado.
    En cuanto a que se dé un soporte oficial a Linkat, si tenemos en cuenta que es un sistema oficial de la Generalitat de Catalunya y que se supone que esta administración junto con la mayoría de las otras. debiera potenciarlo para promocionar los estándares libres y no los cerrados y contando que a nivel técnico dudo que suponga un problema -puesto que verán que sería poco más que cambiarle el nombre a la versión Ubuntu y asegurarse la compatibilidad con el entorno gráfico- sería una gran idea. Aunque la verdad es que iría aún mejor avanzar cuanto antes la disponibilidad de la 18.04. Todos viviríamos un poco más tranquilos. Por nuestra parte y como centro donde usamos su maquinaria ofrecemos la colaboración que nos sea posible.



    Cordialmente,

    La Coordinación Informática del INS Terra Roja.





  • Riccardo PrometheanRiccardo Promethean Publicaciones: 198 mod
    editado 27 de noviembre
    Hola,

    Gracias por su paciencia, y su detallada respuesta.

    De nuestro lado, confirmamos que no tenemos problemas con Ubuntu 16.04 si no con la ultima distribución, la 16.04.5.
    Por cuanto los ajustes en Linkat sean menores, no resulta inmediato averiguar como pueda afectar nuestro software.

    Hemos abierto un pedido para extender la compatibilidad de nuestro software a Linkat.

    Ya estamos desatollando el software para Ubuntu 18.04, todavía no podemos asegurar que siga funcionando con los modelos mas antiguos de ActivBoard.

    Sugiero que visite regularmente nuestra comunidad (https://community.prometheanworld.com/es/) para estar al paso con las novedades del soporte.

    Saludos cordiales,
    Riccardo

    Soporte técnico de Promethean
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    A título informativo... Comportamiento de las pizarras USB contra el kernel (extraido con udevadm)





    Por el momento, estamos intentando forzar el apagado del controlador desde el fichero activmgr.sh y relanzarlo desde allí. A ver por dónde nos salimos. ¿Alguna idea?.
  • Riccardo PrometheanRiccardo Promethean Publicaciones: 198 mod
    Hola,

    No estamos seguros que pueda hacer diferencia.
    Cualquier Kernel sucesivo al 4.13 no resulta oficialmente soportado.

    Es probable que este vaya a cambiar con el soporte a la versión de Ubuntu 18.04 que, probablemente, el soporte sera extendido al ultimo kernel.

    Saludos cordiales,
    Riccardo

    Soporte técnico de Promethean
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    No estamos pidiendo seguridades, sino colaborando en lo posible y públicamente en una posible solución.

    Estos dos días nos hemos dedicado intensivamente al análisis del proceso de arranque y estamos en el siguiente punto:

    1. udev detecta la máquina conectada por USB con el fichero 10_Board_Rules.
    2. En este momento se crea el fichero input/promethean(número de orden).
    3. Se crea el enlace /dev/ACTIVBoard(núm. de dispositivo promethean).
    4. Crea el fichero (dentro del directorio) /tmp/activboard/.activdevices con el contenido add.
    5. Lanza el script /usr/bin/promethean.sh con el parámetro add.
    6. EN TEORÍA, la primera actividad del script nada más detectar el parámetro add es cargar los módulos evdev y promethean con modprobe si no están montados... parece ser que en el arranque esta parte falla, pero sólo en arranque; en conexión posterior no hay problema.
    7. Está comentada una asignación 644 para el enlace /dev/ACTIVBoard(núm. de dispositivo promethean). Si se descomenta se levanta el activmgr, aunque sigue fallando la activación del dispositivo. Es decir, que hay DOS fallos concurrentes y parecen tener algo que ver con los permisos.
    8. Comprueba si existe la carpeta de calibración y la crea en caso necesario, con permisos 777.
    9. Sigue una serie de comunicaciones internas con la pizarra, movidas con logger; con una previsión anotada muy interesante: #since HAL, udev seems to be called before ACTIVBoard<n> is avaiable (sometimes). ¿Se parece sospechosamente al comportamiento que hemos descrito hasta ahora como error? Pero ahora es constante.
    10. Crea, si no existe, el fichero /tmp/activboard/.activdevices, y le da permisos 666.
    11. Salimos de promethean.sh. Se supone que todo está activado y podemos llamar a activmgr. Y si es a posteriori, no hay problema. En el primer arranque sí que es un problema.
    12. En un grupo de coordinadores se nos ha sugerido una solución: forzar la caida de la pizarra y el rearme con un modprobe; por ejemplo al final del promethean.sh.
    ¿Alguna opinión? Gracias por su paciencia.
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    Cualquier Kernel sucesivo al 4.13 no resulta oficialmente soportado.

    Perfecto, pero estamos hablando de un 4.4.

  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    Y, por curiosidad, ¿Qué cambió a partir del 4.13 que invalida el funcionamiento?
  • Riccardo PrometheanRiccardo Promethean Publicaciones: 198 mod
    editado 3 de diciembre
    Hola,

    Gracias por hacer las comprobaciones.

    ¿Han intentado con un kernel de la linea 4.10.0, que sea anterior al 4.13?

    No sabemos exactamente que cambió a partir del 4.13.
    Tenemos una lista de los cambios, todavía no sabemos cual de ellos causa incompatibilidad con nuestro software.

    Es una de las cosas que nuestros compañeros del desarrollo están intentando descubrir.

    Si desea mas información sobre de este tema, una opción seria la de ponerse en contacto con el equipo de Ubuntu. 

    No dude en contactarnos si tiene cualquier pregunta.

    Saludos cordiales,
    Riccardo

    Soporte Técnico de Promethean
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    La única diferencia entre una pizarra que funciona (14.04) y una que no (16.04) es que el fichero /tmp/activboard/.activdevices no existe en la primera (funciona) y sí en la segunda (no funciona). Y eso si es en el proceso de arranque.  Tras el arranque inicial no hay problema.

    Por lo cual, ¿sería interesante apuntar a que systemd -el gran cambio entre las dos versiones- hace arrancar demasiado pronto el daemon de la pizarra -promethean.sh-? ¿Se puede retrasar ese arranque con algun campo en las reglas de montaje 10_board_rules?

    Gracias.
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    En teoría, si no nos hemos equivocado en el análisis, con los procesos descritos aquí https://unix.stackexchange.com/questions/206093/configure-ordering-of-systemd-services debiera ser posible arreglar el problema.

  • Riccardo PrometheanRiccardo Promethean Publicaciones: 198 mod
    Hola,

    Nuestros desarrolladores están comprobando el problema. Hasta que recibamos una respuesta de parte de ellos, no podemos responder a su consulta sobre cómo cambiar o alterar la instalación con este script.

    Gracias de antemano por su paciencia y cooperación.



    Saludos cordiales,
    Riccardo

    Soporte Técnico de Promethean
  • CInfTerraRojaCInfTerraRoja Publicaciones: 24
    Saludos. dado que estamos en proceso de primera evaluación todo el desarrollo está detenido. ¿Se sabe algo de cualquiera de las líneas que les hemos comentado por si hay alguna solución?
  • Adam H PrometheanAdam H Promethean Publicaciones: 385 admin
    Hola,

    Gracias por su publicación. Dado que está usando una distribución de Linux que por el momento no está oficialmente soportado por nuestro Driver, la incidencia está con el equipo de desarrollo.

    Hasta que recibimos una respuesta en interno, no podemos ofrecerle otra solución.

    Le mantendremos informado lo más antes que recibimos alguna novedad.

    Cordialmente,
    Adam
Accede o Regístrate para comentar.