Nombre de la distro, glibc o compilador: qué comprueba el instalador

El instalador imprime “unsupported distribution”, usted edita una cadena y continúa hasta que falla un minuto después con un error del cargador. Esa secuencia es el síntoma que conviene reconocer: el primer fallo fue una comprobación de reconocimiento y el segundo es un límite de compatibilidad. Son dos problemas distintos que casualmente aparecen en la misma terminal. Editar la comprobación solo puede llevarle del primero al segundo.

El síntoma: el instalador se detiene en su derivada

Un script que lee un nombre de distribución y se niega a continuar le está diciendo que su autor no probó su derivada. Eso es una declaración de soporte y no un hecho técnico, y a menudo es incorrecta en el sentido de que el paquete funcionaría sin problema.

El problema empieza cuando el apaño se convierte en el plan. Cambiar un archivo de identidad hace que la comprobación pase, y el paquete entonces se carga, o no se carga, contra el entorno de ejecución que realmente está instalado. Si falla ahí, ninguna edición adicional de identidad servirá.

Así que el movimiento útil es averiguar qué pregunta hizo el instalador y luego averiguar si la respuesta habría importado. Son dos investigaciones separadas y solo la segunda predice si el paquete funcionará.

Tres versiones que la gente llama la versión del sistema

Una versión de distribución nombra un entorno empaquetado. Una versión de biblioteca C nombra una implementación del entorno de ejecución y su versión. Una versión de compilador nombra una cadena de herramientas. En una conversación la gente llama a las tres “la versión del sistema”, y en un instalador no son intercambiables.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

Una aplicación precompilada espera el entorno de ejecución presente cuando se enlazó. Cambiar compiladores en el host no la vuelve a enlazar, y una cadena de herramientas más nueva no cambia nada en los símbolos del cargador que pide el binario. La arquitectura importa otra vez por separado, porque un paquete de 32 bits en un sistema de 64 bits falla por razones que ninguna cadena de versión explica.

Guarde las cuatro salidas con el informe. Recogerlas lleva diez segundos y responden a la mayoría de las preguntas que un mantenedor le haría por correo.

Lea el error, no la comprobación

El primer error de arranque es la evidencia. Un mensaje sobre un objeto compartido que falta, o sobre una versión de símbolo que el cargador no puede satisfacer, es un problema de dependencia del entorno de ejecución. Un mensaje que repite el nombre de la distribución es de nuevo la comprobación de reconocimiento, en otro sitio.

La documentación del enlazador dinámico describe cómo funciona la búsqueda de bibliotecas y dónde busca el cargador. Cambiar una etiqueta de distribución no añade un directorio a esa ruta de búsqueda, y por eso el segundo fallo parece no tener relación con el primero.

No recurra a ldd sobre un ejecutable descargado como primer paso casual. Su propio manual advierte que puede ejecutar el programa en algunas circunstancias, y ejecutar un instalador no confiable es exactamente el caso al que se refiere esa advertencia.

Por qué editar la cadena no ayuda

Falsificar la identidad del sistema operativo cambia cómo cada programa de la máquina se ve a sí mismo. Los gestores de paquetes, las herramientas de soporte y otras aplicaciones leen el mismo archivo, y un valor que satisface a un instalador puede confundir otra cosa meses después.

Sustituir bibliotecas del host por archivos de otra distribución es peor. Puede romper software no relacionado, es invisible para el gestor de paquetes y necesita un plan de mantenimiento que nadie escribe. Esos cambios no los justifica un solo instalador restrictivo.

Si la comprobación es realmente un defecto de reconocimiento, el mantenedor puede confirmarlo y describir la corrección admitida. Si no es un defecto, la vía admitida es una compilación para su plataforma, y esa respuesta no cambia porque se haya editado la cadena.

Escriba un informe sobre el que el mantenedor pueda actuar

Anote la distribución y la versión, la arquitectura, la versión del VPN, la condición exacta que se rechazó y el primer error del entorno de ejecución si llegó tan lejos. Indique si modificó algo, porque un informe de un sistema modificado es otro informe.

Deje el instalador original sin cambios y describa la comprobación en lugar de sortearla. Esa distinción permite al mantenedor separar una regla de reconocimiento demasiado estrecha de un límite real de compatibilidad binaria, que son dos errores muy distintos con dos correcciones muy distintas.

Si la respuesta es que su plataforma no es compatible, es un resultado utilizable. Le dice que busque una compilación compatible en lugar de pasar otra tarde sobre archivos de identidad que nunca fueron el problema.