Distro-naam, glibc of kompileerder: wat die installeerder nagaan

Die installeerder druk “unsupported distribution”, jy verander een string, en dit gaan voort totdat dit ’n minuut later met ’n laaierfout misluk. Daardie volgorde is die simptoom wat ’n mens moet herken: die eerste mislukking was ’n herkenningstoets, en die tweede is ’n versoenbaarheidsgrens. Dit is twee verskillende probleme wat toevallig in dieselfde terminaal verskyn. Om die toets te verander kan jou net van die eerste na die tweede skuif.

Die simptoom: die installeerder stop op jou afgeleide

’n Skrip wat ’n verspreidingsnaam lees en weier om voort te gaan, sê vir jou dat die skrywer daarvan jou afgeleide nie getoets het nie. Dit is ’n ondersteuningsverklaring eerder as ’n tegniese feit, en dit is dikwels verkeerd in die sin dat die pakket heeltemal sou werk.

Die moeilikheid begin wanneer die noodoplossing die plan word. Om ’n identiteitslêer te verander laat die toets slaag, en die pakket laai dan, of laai nie, teen die looptyd wat werklik geïnstalleer is nie. As dit daar misluk, sal geen verdere identiteitsredigering help nie.

Die nuttige stap is dus om uit te vind watter vraag die installeerder gevra het, en dan om uit te vind of die antwoord saak sou maak. Dit is twee afsonderlike ondersoeke en net die tweede voorspel of die pakket sal werk.

Drie weergawes wat mense die stelselweergawe noem

’n Verspreidingsvrystelling benoem ’n verpakte omgewing. ’n C-biblioteekweergawe benoem ’n looptydimplementering en sy vrystelling. ’n Kompileerderweergawe benoem ’n gereedskapketting. Mense noem al drie “die stelselweergawe” in gesprek, en hulle is nie in ’n installeerder uitruilbaar nie.

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

’n Voorafgeboude toepassing verwag die looptyd wat teenwoordig was toe dit gekoppel is. Om kompileerders op die gasheer te ruil, koppel dit nie weer nie, en ’n nuwer gereedskapketting verander niks aan die laaier-simbole wat die binêre lêer versoek nie. Argitektuur maak weer afsonderlik saak, want ’n 32-bis-pakket op ’n 64-bis-stelsel misluk om redes wat geen weergawestring verduidelik nie.

Hou die vier uitsette by die verslag. Dit neem tien sekondes om in te samel en dit beantwoord die meeste vrae wat ’n instandhouer andersins per e-pos aan jou sou vra.

Lees die fout, nie die toets nie

Die eerste bekendstellingsfout is die bewys. ’n Boodskap oor ’n ontbrekende gedeelde objek, of oor ’n simboolweergawe wat die laaier nie kan bevredig nie, is ’n looptydafhanklikheidsprobleem. ’n Boodskap wat die verspreidingsnaam herhaal, is weer die herkenningstoets, op ’n ander plek.

Die die dokumentasie van die dinamiese skakelaar beskryf hoe biblioteekopsoeking werk en waar die laaier soek. Om ’n verspreidingsetiket te verander voeg nie ’n gids by daardie soekpad nie, en daarom lyk die tweede mislukking onverwant aan die eerste.

Moenie ldd op ’n afgelaaide uitvoerbare lêer as ’n gewone eerste stap gebruik nie. Die handleiding daarvan waarsku dat dit die program onder sommige omstandighede kan uitvoer, en om ’n onbetroubare installeerder te laat loop is juis die geval waaroor daardie waarskuwing gaan.

Waarom die verandering van die string nie help nie

Om die bedryfstelsel se identiteit te vervals, verander hoe elke program op die masjien homself sien. Pakketbestuurders, ondersteuningsnutsgoed en ander toepassings lees dieselfde lêer, en ’n waarde wat een installeerder tevrede stel, kan maande later iets anders verwar.

Om gasheerbiblioteke met lêers uit ’n ander verspreiding te vervang, is erger. Dit kan onverwante sagteware breek, dit is onsigbaar vir die pakketbestuurder, en dit vereis ’n instandhoudingsplan wat niemand neerskryf nie. Daardie veranderinge word nie deur een beperkende installeerder geregverdig nie.

As die toets werklik ’n herkenningsgebrek is, kan die instandhouer dit bevestig en die ondersteunde regstelling beskryf. As dit nie ’n gebrek is nie, is die ondersteunde pad ’n bou vir jou platform, en daardie antwoord verander nie omdat die string geredigeer is nie.

Skryf ’n verslag waarop die instandhouer kan reageer

Teken die verspreiding en vrystelling aan, die argitektuur, die VPN-vrystelling, die presiese toestand wat verwerp is, en die eerste looptydfout as jy so ver gekom het. Let op of jy enigiets verander het, want ’n verslag van ’n veranderde stelsel is ’n ander verslag.

Hou die oorspronklike installeerder onveranderd en beskryf die toets eerder as om dit te omseil. Daardie onderskeid laat die instandhouer ’n te eng herkenningsreël van ’n werklike binêre versoenbaarheidsgrens skei, wat twee baie verskillende foute met twee baie verskillende regstellings is.

As die antwoord terugkom dat jou platform nie ondersteun word nie, is dit ’n bruikbare resultaat. Dit sê vir jou om na ’n ondersteunde bou te soek eerder as om nog ’n aand aan identiteitslêers te spandeer wat nooit die probleem was nie.