Tras migrar a Xubuntu 22, quería instalar mediante puppet en los infolab el driver "nvidia-driver-390" y "nvidia-dkms-390". Estos paquetes necesitan que se haya instalado previamente el paquete linux-headers-xxx correspondiente al kernel que corre actualmente el sistema operativo.
El problema es que ninguno ambos paquetes instala linux-headers y, para mas inri, si no lo encuentran lo que sucede es que falla lo instalación. Tenemos que instalar nosotros a mano previamente el linux-headers-xxx y luego los nvidia-tal-390. Como odio hacer a mano cosas que son automatizables he encontrado la manera de instalarlo todo de un tirón usando puppet. Las reglas serían:
Explicación: el problema es saber desde puppet que versión de los linux-headers tenemos que instalar. El truco está en usar el facter $kernelrelease, que nos devuelve el kernel instalado en la forma "xxx-generic". Si quitamos la parte "-generic" (con la función de puppet "regsubst") nos quedará la versión del kernel, que unida a "linux-headers-" nos permitirá instalar el paquete correcto. Voilà!
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:
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:
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:
