Distronaam, glibc of compiler: wat het installatieprogramma controleert

Het installatieprogramma drukt “unsupported distribution” af, u wijzigt één tekenreeks en het gaat verder tot het een minuut later faalt met een loader-fout. Die volgorde is het symptoom dat het herkennen waard is: de eerste fout was een herkenningscontrole en de tweede is een compatibiliteitsgrens. Het zijn twee verschillende problemen die toevallig in dezelfde terminal verschijnen. De controle aanpassen kan u alleen van de eerste naar de tweede verplaatsen.

Het symptoom: het installatieprogramma stopt bij uw afgeleide distributie

Een script dat een distributienaam leest en weigert door te gaan, vertelt u dat de auteur uw afgeleide distributie niet heeft getest. Dat is een ondersteuningsverklaring en geen technisch feit, en ze is vaak onjuist in de zin dat het pakket prima zou werken.

De problemen beginnen wanneer de omweg het plan wordt. Een identiteitsbestand wijzigen laat de controle slagen, en het pakket laadt daarna wel of niet tegen de runtime die werkelijk is geïnstalleerd. Faalt het daar, dan helpt geen enkele verdere identiteitswijziging.

De nuttige stap is dus uitzoeken welke vraag het installatieprogramma stelde, en daarna uitzoeken of het antwoord ertoe had gedaan. Dat zijn twee afzonderlijke onderzoeken en alleen het tweede voorspelt of het pakket zal werken.

Drie versies die mensen de systeemversie noemen

Een distributierelease benoemt een verpakte omgeving. Een C-bibliotheekversie benoemt een runtime-implementatie en de release ervan. Een compiler-versie benoemt een toolchain. In gesprekken noemen mensen alle drie “de systeemversie”, en in een installatieprogramma zijn ze niet uitwisselbaar.

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

Een vooraf gebouwde toepassing verwacht de runtime die aanwezig was toen ze werd gelinkt. Compilers op de host vervangen linkt haar niet opnieuw, en een nieuwere toolchain verandert niets aan de loadersymbolen die het binaire bestand opvraagt. Architectuur telt weer apart, want een 32-bits pakket op een 64-bits systeem faalt om redenen die geen versietekenreeks verklaart.

Bewaar de vier uitvoeritems bij het rapport. Ze verzamelen kost tien seconden en ze beantwoorden de meeste vragen die een onderhouder u anders per e-mail zou stellen.

Lees de fout, niet de controle

De eerste startfout is het bewijs. Een melding over een ontbrekend gedeeld object, of over een symboolversie waaraan de loader niet kan voldoen, is een runtime-afhankelijkheidsprobleem. Een melding die de distributienaam herhaalt, is opnieuw de herkenningscontrole, elders.

De documentatie van de dynamische linker beschrijft hoe het zoeken naar bibliotheken werkt en waar de loader zoekt. Een distributielabel wijzigen voegt geen map toe aan dat zoekpad, en daarom lijkt de tweede fout los te staan van de eerste.

Grijp niet naar ldd op een gedownload uitvoerbaar bestand als gewone eerste stap. De eigen handleiding waarschuwt dat het het programma onder sommige omstandigheden kan uitvoeren, en een niet-vertrouwd installatieprogramma uitvoeren is precies het geval waarover die waarschuwing gaat.

Waarom het wijzigen van de tekenreeks niet helpt

De identiteit van het besturingssysteem vervalsen verandert hoe elk programma op de machine zichzelf ziet. Pakketbeheerders, ondersteuningstools en andere toepassingen lezen hetzelfde bestand, en een waarde die één installatieprogramma tevreden stelt, kan maanden later iets anders in de war brengen.

Hostbibliotheken vervangen door bestanden uit een andere distributie is erger. Het kan ongerelateerde software breken, het is onzichtbaar voor de pakketbeheerder, en het vereist een onderhoudsplan dat niemand opschrijft. Die wijzigingen worden niet gerechtvaardigd door één restrictief installatieprogramma.

Is de controle echt een herkenningsfout, dan kan de onderhouder die bevestigen en de ondersteunde correctie beschrijven. Is ze geen fout, dan is het ondersteunde pad een build voor uw platform, en dat antwoord verandert niet omdat de tekenreeks is bewerkt.

Schrijf een rapport waarop de onderhouder kan handelen

Noteer de distributie en release, de architectuur, de VPN-release, de exacte voorwaarde die werd geweigerd, en de eerste runtime-fout als u zo ver kwam. Vermeld of u iets hebt gewijzigd, want een rapport van een gewijzigd systeem is een ander rapport.

Laat het oorspronkelijke installatieprogramma ongewijzigd en beschrijf de controle in plaats van ze te omzeilen. Dat onderscheid stelt de onderhouder in staat een te enge herkenningsregel te scheiden van een echte binaire compatibiliteitsgrens, en dat zijn twee heel verschillende fouten met twee heel verschillende oplossingen.

Komt het antwoord dat uw platform niet wordt ondersteund, dan is dat een bruikbaar resultaat. Het zegt u te zoeken naar een ondersteunde build in plaats van nog een avond te besteden aan identiteitsbestanden die nooit het probleem waren.