Distronavn, glibc eller kompilator: hva installasjonsprogrammet sjekker

Installasjonsprogrammet skriver ut “unsupported distribution”, du endrer én streng, og det fortsetter til det feiler et minutt senere med en loader-feil. Den sekvensen er symptomet det er verdt å kjenne igjen: den første feilen var en gjenkjennelsessjekk, og den andre er en kompatibilitetsgrense. Det er to forskjellige problemer som tilfeldigvis dukker opp i samme terminal. Å endre sjekken kan bare flytte deg fra den første til den andre.

Symptomet: installasjonsprogrammet stopper på din avledede distribusjon

Et skript som leser et distribusjonsnavn og nekter å fortsette, forteller deg at forfatteren ikke testet din avledede distribusjon. Det er en støtteerklæring og ikke et teknisk faktum, og den er ofte feil i den forstand at pakken ville kjørt fint.

Problemet begynner når omveien blir planen. Endring av en identitetsfil får sjekken til å passere, og pakken lastes deretter, eller lastes ikke, mot kjøretiden som faktisk er installert. Hvis den feiler der, hjelper ingen ytterligere identitetsredigering.

Det nyttige trekket er derfor å finne ut hvilket spørsmål installasjonsprogrammet stilte, og deretter finne ut om svaret ville hatt betydning. Det er to separate undersøkelser, og bare den andre forutsier om pakken vil fungere.

Tre versjoner folk kaller systemversjonen

En distribusjonsutgivelse navngir et pakket miljø. En C-bibliotekversjon navngir en kjøretidsimplementasjon og utgivelsen av den. En kompilatorversjon navngir en verktøykjede. I samtale kaller folk alle tre “systemversjonen”, og i et installasjonsprogram er de ikke utskiftbare.

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

Et forhåndsbygd program forventer kjøretiden som fantes da det ble lenket. Å bytte kompilatorer på verten lenker det ikke på nytt, og en nyere verktøykjede endrer ingenting i loader-symbolene som binærfilen ber om. Arkitektur teller igjen separat, fordi en 32-biters pakke på et 64-biters system feiler av grunner ingen versjonsstreng forklarer.

Ta vare på de fire utskriftene sammen med rapporten. De tar ti sekunder å samle inn, og de svarer på de fleste spørsmålene en vedlikeholder ellers ville stilt deg på e-post.

Les feilen, ikke sjekken

Den første oppstartsfeilen er beviset. En melding om et manglende delt objekt, eller om en symbolversjon loaderen ikke kan oppfylle, er et kjøretidsavhengighetsproblem. En melding som gjentar distribusjonsnavnet, er igjen gjenkjennelsessjekken, på et annet sted.

dokumentasjonen for den dynamiske linkeren beskriver hvordan biblioteksøk fungerer og hvor loaderen leter. Å endre en distribusjonsetikett legger ikke til en mappe i den søkestien, og derfor virker den andre feilen urelatert til den første.

Ikke grip til ldd på en nedlastet kjørbar fil som et tilfeldig første steg. Dens egen manual advarer om at den kan kjøre programmet under visse omstendigheter, og å kjøre et ikke-klarert installasjonsprogram er nettopp tilfellet den advarselen handler om.

Hvorfor redigering av strengen ikke hjelper

Å forfalske identiteten til operativsystemet endrer hvordan hvert program på maskinen ser seg selv. Pakkebehandlere, støtteverktøy og andre programmer leser den samme filen, og en verdi som tilfredsstiller ett installasjonsprogram kan forvirre noe annet måneder senere.

Å erstatte vertens biblioteker med filer fra en annen distribusjon er verre. Det kan ødelegge urelatert programvare, det er usynlig for pakkebehandleren, og det krever en vedlikeholdsplan som ingen skriver ned. De endringene rettferdiggjøres ikke av ett restriktivt installasjonsprogram.

Hvis sjekken virkelig er en gjenkjennelsesfeil, kan vedlikeholderen bekrefte den og beskrive den støttede rettelsen. Hvis den ikke er en feil, er den støttede veien et bygg for plattformen din, og det svaret endres ikke fordi strengen ble redigert.

Skriv en rapport vedlikeholderen kan handle på

Noter distribusjonen og utgivelsen, arkitekturen, VPN-utgivelsen, den nøyaktige betingelsen som ble avvist, og den første kjøretidsfeilen hvis du kom så langt. Noter om du endret noe, fordi en rapport fra et endret system er en annen rapport.

Hold det originale installasjonsprogrammet uendret og beskriv sjekken i stedet for å gå rundt den. Den forskjellen lar vedlikeholderen skille en altfor snever gjenkjennelsesregel fra en reell binær kompatibilitetsgrense, og det er to svært forskjellige feil med to svært forskjellige rettelser.

Hvis svaret er at plattformen din ikke støttes, er det et brukbart resultat. Det forteller deg å lete etter et støttet bygg i stedet for å bruke enda en kveld på identitetsfiler som aldri var problemet.