Nome della distro, glibc o compilatore: cosa controlla l’installer

L’installer stampa “unsupported distribution”, modificate una stringa e prosegue finché non fallisce un minuto dopo con un errore del loader. Questa sequenza è il sintomo da riconoscere: il primo errore era un controllo di riconoscimento e il secondo è un limite di compatibilità. Sono due problemi diversi che capita compaiano nello stesso terminale. Modificare il controllo può solo spostarvi dal primo al secondo.

Il sintomo: l’installer si ferma sulla vostra derivata

Uno script che legge un nome di distribuzione e rifiuta di continuare vi sta dicendo che il suo autore non ha testato la vostra derivata. È una dichiarazione di supporto e non un fatto tecnico, ed è spesso sbagliata nel senso che il pacchetto funzionerebbe benissimo.

Il guaio comincia quando il workaround diventa il piano. Modificare un file di identità fa passare il controllo, e il pacchetto quindi si carica, o non si carica, rispetto all’ambiente di esecuzione realmente installato. Se fallisce lì, nessun’altra modifica dell’identità servirà.

La mossa utile è quindi scoprire quale domanda ha posto l’installer, e poi scoprire se la risposta sarebbe stata importante. Sono due indagini separate e solo la seconda predice se il pacchetto funzionerà.

Tre versioni che la gente chiama la versione del sistema

Una versione di distribuzione nomina un ambiente pacchettizzato. Una versione di libreria C nomina un’implementazione dell’ambiente di esecuzione e la sua versione. Una versione di compilatore nomina una toolchain. In una conversazione la gente chiama tutte e tre “la versione del sistema”, e in un installer non sono intercambiabili.

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

Un’applicazione precompilata si aspetta l’ambiente di esecuzione presente quando è stata collegata. Cambiare i compilatori sull’host non la ricollega, e una toolchain più recente non cambia nulla nei simboli del loader che il binario richiede. L’architettura conta di nuovo a parte, perché un pacchetto a 32 bit su un sistema a 64 bit fallisce per motivi che nessuna stringa di versione spiega.

Conservate i quattro output con il rapporto. Raccolglierli richiede dieci secondi e rispondono alla maggior parte delle domande che un manutentore vi farebbe per email.

Leggete l’errore, non il controllo

Il primo errore di avvio è la prova. Un messaggio su un oggetto condiviso mancante, o su una versione di simbolo che il loader non può soddisfare, è un problema di dipendenza dall’ambiente di esecuzione. Un messaggio che ripete il nome della distribuzione è di nuovo il controllo di riconoscimento, altrove.

La documentazione del linker dinamico descrive come funziona la ricerca delle librerie e dove cerca il loader. Cambiare un’etichetta di distribuzione non aggiunge una directory a quel percorso di ricerca, ed è per questo che il secondo errore sembra senza rapporto con il primo.

Non ricorrete a ldd su un eseguibile scaricato come primo passo casuale. Il suo stesso manuale avverte che può eseguire il programma in alcune circostanze, ed eseguire un installer non fidato è esattamente il caso a cui si riferisce quell’avvertimento.

Perché modificare la stringa non aiuta

Falsificare l’identità del sistema operativo cambia il modo in cui ogni programma della macchina vede se stesso. I gestori di pacchetti, gli strumenti di supporto e altre applicazioni leggono lo stesso file, e un valore che soddisfa un installer può confonderne un altro mesi dopo.

Sostituire le librerie dell’host con file di un’altra distribuzione è peggio. Può rompere software non correlato, è invisibile al gestore di pacchetti e richiede un piano di manutenzione che nessuno scrive. Quei cambiamenti non sono giustificati da un solo installer restrittivo.

Se il controllo è davvero un difetto di riconoscimento, il manutentore può confermarlo e descrivere la correzione supportata. Se non è un difetto, il percorso supportato è una build per la vostra piattaforma, e quella risposta non cambia perché la stringa è stata modificata.

Scrivete un rapporto su cui il manutentore possa agire

Annotate la distribuzione e la versione, l’architettura, la versione del VPN, la condizione esatta che è stata rifiutata e il primo errore dell’ambiente di esecuzione se siete arrivati fin lì. Indicate se avete modificato qualcosa, perché un rapporto da un sistema modificato è un altro rapporto.

Lasciate invariato l’installer originale e descrivete il controllo invece di aggirarlo. Questa distinzione permette al manutentore di separare una regola di riconoscimento troppo stretta da un vero limite di compatibilità binaria, che sono due bug molto diversi con due correzioni molto diverse.

Se la risposta è che la vostra piattaforma non è supportata, è un risultato utilizzabile. Vi dice di cercare una build supportata invece di passare un’altra sera su file di identità che non sono mai stati il problema.