Demoras en el arranque de los PC "infolab"

Ya contamos como configurar como puestos multiseat los infolabs HP ProDesk 600 G1 SFF que tenemos, permitiendo que un mismo PC fuese usado por 2 usuarios a la vez de forma concurrente.

Había venido observando que el arranque de un PC infolab con multiseat era bastante mas lento (un minuto o más) que el de un infolab normal. En un primer momento lo achaqué a su condición de multiseat: al tener dos escritorios concurrentes quizá el arranque tarda más mientras preparaba el entorno. Pero como no estaba muy convencido he estado investigando.

Lo primero es medir los tiempos de arranque con systemd-analyze. Con:

# systemd-analyze blame

Nos sale una lista decreciente de tiempos y procesos, llamándome la atención esto:

54.4s dev-sda5.device

Comparando con otro infolab sin multiseat:

7.471s dev-sda5.device

Buscando en Internet veo que dev-sdaX.device no es nada en concreto, no se corresponde con ningún servicio y no hay manera de sacar información de ahí. Analizando con "systemd-analyze plot" y "systemd-analyze critical-chain" no saco nada más en claro.

Bueno, pues otra manera mas detallada de analizar el arranque es utilizar systemd-bootchart, que guarda una imagen SVG en /var/run con los tiempos y procesos de arranque más detallada que la de "systemd-analyze plot".

Analilzando veo que el proceso mas destacado es nvidia-smi lanzado desde systemd-udevd, el cual tarda 14s en ejecutarse. Si lo hago en un equipo sin multiseat veo que tarda menos de medio segundo.

Pensando entre las diferencias que hay entre infolabs con y sin multiseat recuerdo el tema de las tarjetas VGA. Un infolab trae 2 tarjetas VGA de serie:

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1)

En el caso de un equipo multiseat ambas VGA están activas (ya que hacen falta para los 2 monitores). En un equipo normal tengo la tarjeta VGA Intel (la de la placa base) desactivada en la BIOS, ya que no me hace falta y la desactivo para evitar problemas.

Como ultima comprobación, mirando el syslog de arranque con dmesg encuentro que, cuando hay retraso, este mensaje aparece en el log:

watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [nvidia-smi:618]

Deduzco que es casi seguro que la combinación del programa nvidia-smi (que viene con el driver propietario nvidia) y la tarjeta VGA intel de la placa base son la causa del problema.

Consideremos estas pruebas y limitaciones:

• No puedo prescindir de los drivers nvidia, ya que con nouveau no funciona el multiseat.
• No puedo desactivar la tarjeta intel en la BIOS, ya que la necesito para seat-1 del multiseat.
• He probado con distintos kernel 4.x y 5.x por si fuera un fallo del driver. No se arregla con ninguno.
• He actualizado el driver propietario a la ultimísima versión (usando el PPA). No se arregla.

Cuando no se te ocurre nada nuevo es el momento de buscar en Internet. Buscando por el texto del error mostrado en el syslog encuentro:

• Solución 1: Añadir nomodeset como parámetro de arranque del kernel en el grub. Se arregla el problema, pero no funciona el multiseat. El seat-1 no se levanta.
• Solución 2: en el fichero /lib/udev/rules.d/71-nvidia.rules comentar la línea:
  

  ACTION=="add" DEVPATH=="/module/nvidia" SUBSYSTEM=="module" RUN+="/usr/bin/nvidia-smi"
  

Pues está última propuesta funciona. Comentando esa línea impedimos que nvidia-smi (el causante del problema) se ejecute en el arranque del sistema, al iniciar la tarjeta nvidia. Parece temerario pero resulta que al final que el arranque se acelera (dev-sda5.device dura unos segundos en lugar de casi un minuto) y el multiseat funciona. Hablando en plata: la ejecución inicial de nvidia-smi es prescindible.

Como colofón podemos decir que esto no es es solamente aplicable cuando hay multiseat (que es como me ha salpicado a mí): siempre que haya una demora en el arranque producido por un conflicto entre nvidia-smi y una tarjeta no nvidia en la placa madre la solución será comentar esta línea que ejecuta en el inicio nvidia-smi. Tomemos nota para el futuro.

---

Qué bonitos los robots de Boston Dynamics, no entiendo como a mi compañera Marisa le dan repelús:

Jkiwi en Ubuntu Bionic 18.04

Ya hicimos funcionar la aplicación de maquillaje y estilismo capilar jkiwi para una arquitectura de 64 bits aquí.

Cuando me han pedido instalarla en Ubuntu 18 me he encontrado con que da error de dependencias porque no encuentra la máquina virtual java. Necesita uno de los siguientes paquetes: sun-java6-jre | sun-java5-jre | icedtea-java7-jre | openjdk-6-jre para funcionar y al no encontrarlos se aborta la instalación.

El motivo es que en Ubuntu 18.04 el paquete con la máquina virtual java es openjdk-8-jre, que no existía cuando se creó el .deb de jkiwi. La solución pasa por editar el paquete .deb y añadir la dependencia de openjdk-8-jre.

El paquete .deb lo modificamos tal como contamos aquí:

# dpkg-deb  -R jkiwi_0.9.5_all.deb jkiwi

En jkiwi/DEBIAN/control hay que modificar la siguiente línea, añadiendo la parte en negrita:

Depends: sun-java6-jre | sun-java5-jre | icedtea-java7-jre | openjdk-6-jre | openjdk-8-jre

Y luego reconstruimos el paquete:

# dpkg-deb -b jkiwi/ jkiwi_0.9.5_all.deb

El recién creado jkiwi_0.9.5_all.deb (puedes descargarlo de aquí) es el que ya podremos instalar (en mi caso lo he metido en mí repositorio local para instalarlo mas cómodamente) al tener su dependencia openjdk-8-jre cumplida. La aplicación funciona perfectamente con este openjdk, aunque sea muy posterior a la propia aplicación.

Sustitución del cable de teclado de Infolabs/Siatic HP-KUS1206.

Tenemos un montón de teclados HP KUS1206 con lector SmartCard de muy buena calidad y robustos, pero en mi caso adolecen de un punto débil: el cable USB tiene tendencia a "pelarse" y partirse en el punto donde entra en el teclado, seguramente por el trajineteo al que están sometidos por los múltiples usuarios. Otro problema es que el cable se ha ido deformando y endureciendo, perdiendo flexibilidad, a lo largo de los años.

Como estos teclados por todo lo demás están en perfecto estado y funcionan a las mil maravillas, me daba rabia tener que mandar a reciclar un teclado de 50 euros por un puñetero cable USB roto. Así que me dispuse a desmontar uno a ver como iba conexión del cable.

En algunos teclados/ratones este cable está soldado a una pequeña placa de circuito impreso, pero afortunadamente en estos teclados vienen unidos con un conector:

En un principio me puse muy contento pensando que era un conector de 5 pines Dupont de los usados para montajes electrónicos, ya que esos conectores son fáciles de encontrar y manejar.

Pero no, los pin housing de los conectores Dupont tienen un ancho de 0.1"/2.54mm cada uno, de tal manera que 10 pines ocupan una pulgada (2.54cm). En cambio el pin housing de este teclado tiene un ancho de 2mm, de tal manera que los 5 pines ocupan 1cm (y 10 pines ocupan 2.00cm). Esto es un pin housing:

Los pin housing de 2mm con esta forma no son nada fáciles de encontrar y al final salen caros por su rareza. Parecía que no había solución a no ser que cortásemos y soldásemos a ese pin housing otro cable USB en perfecto estado. Soldar cables USB requiere un grado de destreza y paciencia que no tengo.

Pero vaya, rebuscando entre chatarra encontré varios cables de antiguos ratones averiados o rotos:

Midiendo resulta que su pin housing tiene 1cm de ancho, coincidiendo con los pines macho de nuestro teclado. Hay un pequeño problema: la posición de los hilos es diferente en ambos cables, ya que en el cable del teclado es Negro-Negro-Verde-Blanco-Rojo, mientras que en el cable del ratón es Negro-Negro-Rojo-Blanco-Verde. El coloreado en los cables USB es uno de los pocos cableados que normalmente se respeta.

Con ayuda de un destornillador pequeño es sencillo levantar la pestañita de plástico y extraer el hilo con el "crimp connector" que lo hace encajar en el pinheader.

Intercambiamos los hilos Rojo y Verde del cable del ratón, lo encajamos en el housing y este lo acoplamos con cuidado, forzando suavecito, en los 5 pines macho del circuito impreso del teclado.

Enchufando el cable USB al PC compruebo que el teclado funciona. Cerramos todo y dejamos el teclado listo con el nuevo cable, que aunque no es tan grueso como el original me ha permitido recuperar la funcionalidad.

El cableado antes:

El cabledo ahora:

Como después de tantos años tenía un buen número de cables de ratón con ese conector, he podido reparar varios teclados que tenía desahuciados para piezas y darles una nueva vida.

Para cuando se me acaben los cables de ratón he visto que se pueden localizar cables sueltos "usb to housing 5pin cable for mouse keyboard" o, llegado el caso, comprar pin housings y crimp connectors de 2mm sueltos para hacer el montaje a partir de otros cables USB que hayamos guardado para reciclar.

---

La sonda solar Parker ha llegado a su destino y empezará a estudiar la corona solar, cayendo en algunos puntos por debajo de la órbita de Mercurio. Una auténtica proeza de precisión y resistencia a 1377º de temperatura.

Si todo sale bien, le quedan 7 años para hacer 24 órbitas en las que recopilará datos sobre viento solar, magnetismo y partículas emitidas por nuestra estrella. ¡Buena suerte!

Ratón por puerto serie

Haciendo limpieza me he encontrado varios ratones serie y de bola. Me ha entrado curiosidad por ver si funcionaban, pero al ser de una época donde el plug'n'play era desconocido no ha bastado con enchufarlos al puerto serie, además he tenido que configurar un par de cosas:

Crear el fichero /etc/X11/xorg.conf.d/01-serial.conf (o /usr/share/X11/xorg.conf.d/01-serial.conf, dependiendo del Linux que usemos) :

# cat /etc/X11/xorg.conf.d/01-serial.conf

Section "InputDevice"
   Identifier "Mouse0"
   Driver "mouse"
   Option "Protocol" "Microsoft"
   Option "Device" "/dev/ttyS0"
   Option "ZAxisMapping" "4 5"
   Option "Emulate3Buttons" "false"
EndSection

Y añadir en rc.local la línea:

inputattach --microsoft /dev/ttyS0

Recordemos que con systemd el fichero rc.local no funciona, hay que activarlo como cuentan aquí.

Los ratones, pasados 25 años o más de su fabricación siguen funcionando. Ya no se hacen ratones como los de antes.

Bloqueo de funciones en impresora multifunción Epson WF-8590.

No soy muy partidario de las impresoras de inyección, ya que solo las veo útiles en un entorno donde se imprime de forma constante y abundante durante todo el año, pero como nos enviaron unas cuantas a cada centro no nos queda otra que lidiar con ellas. Las Epson WF-8590 no han salido problemáticas, de momento aguantan con las recargas de tinta genérica y se estropean lo normal.

Debido a que permiten ser usadas como fotocopiadora de manera sencilla me encuentro con el problema de tener tentadoras fotocopiadoras de uso público en sitios no controlados. En un centro educativo eso no puede ser, ya que es fácil imaginar que pronto empieza a haber fotocopias de extranjis. Para evitarlo bloqueo las funciones de fotocopia e impresión desde pendrive si sé que va a estar en un sitio sin supervisión.

Para ello nos conectamos a la IP de la impresora, metemos la contraseña de administración y configuramos el bloqueo de control de acceso. Esto hará que no se puedan usar las opciones de fotocopiado e impresión usando pendrives desde panel táctil de la impresora.

Al restringir el acceso me veo obligado a crear un par de usuarios:

Un usuario "administrador" con todos los permisos:

Y un usuario "usuario" con permiso para escanear e imprimir. Este será el que utilicen los usuarios rasos:

Con esto queda bloqueado el acceso por el panel, pero al haber activado el control de acceso necesitamos configurar un usuario y contraseña en Windows (en Linux esto no es necesario), a pesar de haber indicado en la configuración anterior que se "Permite imprimir y digitalizar sin información de autenticación". Parece ser un bug del firmware.

Para ello, en las preferencias de la impresora en Windows configuramos el usuario que definimos anteriormente:

Esto realmente lo que hace es meter en el registro de Windows estas claves:

El inconveniente es que hay que hacerlo para todos los usuarios de Windows uno a uno en cada PC y como no nos gusta repetir una y otra vez la misma configuración hemos definido un script que añade esas claves al registro:

@echo off
rem claves-epson.bat
reg import c:\windows\epson-usuario.reg

El fichero c:\windows\epson-usuario.reg sería:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\EPSON\PRINTER\EPSON WF-8590 Series]
"EPRFPW"="usuario"
"EPRFUM"="abcd1234"

Este último fichero lo mas adecuado es que lo creemos exportando desde regedit la clave "HKEY_CURRENT_USER\Software\EPSON\PRINTER\EPSON WF-8590 Series" desde un usuario con los datos configurados, ya que no es un fichero de texto ASCII al uso y tiene algunos bytes raros ocultos, por lo que no se puede crear con un editor de textos.

Para que se ejecute el script en el inicio de sesión de cada usuario de forma automática habría que ponerlo en la carpeta de scripts de inicio de todos los usuarios. En el caso de Windows 8 sería: "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp". En los otros Windows esta carpeta tiene ubicaciones distintas.

Y con esto tenemos la impresora controladita a nuestro gusto.

---

Es curioso que esto sea noticiable, pero es bueno saber que en SpaceX también explotan cosas:



La noticia es que un prototipo de la Starship ha explotado durante una prueba de presurización máxima. Cuando pruebas al máximo la presurización de un prototipo no es infrecuente que explote. De hecho, esa es la idea.

La Starship es bonita hasta cuando explota.