El problemo
Me hallaba instalando MCUXpresso que es una IDE basada en eclipse para desarrollo de sistemas embebidos de NXP para poder programar la mimxrt1020-evk que NXP me regaló. El instalador es un archivo armado con Makeself.
El inicio del instalador |
Este archivo es una concatenación entre un enorme comprimido y un encabezado que hace unas verificaciones, descomprime y ejecuta lo que hay en el comprimido.
El inicio del payload binario |
En este caso en particular, supongo que usa apt/dpkg para instalar dependencias y dejar todo prolijito. Al final llama a las configuraciones pendientes y tiene una falla que hace meses que está ahí y nunca me había molestado, hasta ahora.
Tomá nota del exit status 6 |
Momento de decisión: buscar situaciones parecidas con google (no) o escarbar por mis propios medios (si).
Podemos ver que el paquete es kismet y que tiene que ver con un usuario inexistente. Tambien podemos ver que más que una instalación de MCUXpresso es una reinstalación (unpacking xxxx over xxxx) y no vemos que fué lo que instaló, claro, las dependencias ya quedaron en el primer intento y recién se me ocurrió documentar luego.
Me imagino que cuando instalé kismet me mandé alguna macana con los usuarios y kismet ofrece ajustar los permisos para que algunos usuarios puedan hacer cosas que normalmente requieren privilegios sin tener que usar root o sudo.
En los scripts debe haber una linea como:
dpkg -i JLink_Linux_x86_64.deb mcuxpressoide-11.1.1_3241.x86_64.deb
que al final dispara una acción que lleva a ese error.
Para comprobarlo debería descomprimir el payload o instalar y observarlo mientras esté descomprimido, pero prefiero suponer que no tengo acceso o que el instalador está tomando medidas defensivas, también me obliga a entender como funciona Makeself que aunque no debe ser muy misterioso me resulta completamente carente de interés, Makeself es circunstancial, es más productivo aprender del sistema común.
Momento de decisión: analizar y modificar al instalador (no) o replicar comportamiento (si).
Necesito reproducir el comando mínimo con el mismo resultado. No me preguntes de dónde lo sé, evidentemente es el humus estratificado de mi mente, pero sé que:
sudo dpkg --configure kismet
debería servir y así es:
El siguiente paso es ver que archivos está abriendo con strace
sudo strace -f -eopen dpkg --configure kismet
Trae dos cosas interesantes:
Fijate que coincide el 6 con el 6 de la captura. |
Un archivo interesante para mirar |
Agregando que nos muestre las lecturas:
sudo strace -f -eopen -eread dpkg --configure kismet
Tomá nota del GET kismet/install-users |
En los read() de arriba, se ve pasar el nombre del usuario inexistente. Esa forma de letrita por letrita primero apuesto a que es indicio de un pipeline entre procesos. Pero no lo pude reproducir, así que quizás sea algo tipo expect, un proceso pasándole letritas a otro interactivo.
Volviendo al archivo interesante, /var/lib/dpkg/info/kismet.postinst, este hace una llamada que coincide con el GET de más arriba:
Ahí le agregamos a continuación de usermod:
echo "########### group $GROUP x $x "
y ahora tenemos:
El siguiente paso es comprender como funciona db_* para modificar el usuario.
Al inicio se incluye /usr/share/debconf/confmodule, dentro de ese archivo vemos los comandos disponibles:
Hay tantos debconf que no podemos menos que preguntar a man debconf de qué se trata:
Para ver debconf-devel hay que instalar debconf-doc.
Momento de decisión: esto tendría que habérseme ocurrido en el primer momento: puedo desinstalar kismet (no), agregar el usuario faltante para que termine la instalación (no) o seguir por este camino (si).
Leemos superficialmente man debconf-devel y deducimos que con db_set nos arreglamos:
. /usr/share/debconf/confmodule
db_get kismet/install-users
echo $RET
db_set kismet/install-users XXXXXX
db_get kismet/install-users
echo $RET
Me vas a tener que creer que primero dice un usuario y luego otro |
Apuesto a que el instalador ahora anda:
Gané, me anoto quitar ese echo.
Queda entonces para que google le responda al próximo que no quiera pensar mucho:
dpkg: error processing package
subprocess installed post-installation script returned error exit status 6
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code
No hay comentarios:
Publicar un comentario