Distronamn, glibc eller kompilator: kva installasjonsprogrammet sjekkar

Installasjonsprogrammet skriv ut “unsupported distribution”, du endrar éin streng, og det held fram til det feilar eitt minutt seinare med ein lastarfeil. Den sekvensen er symptomet det er verdt å kjenne att: den første feilen var ein attkjenningssjekk, og den andre er ei kompatibilitetsgrense. Det er to ulike problem som tilfeldigvis dukkar opp i same terminal. Å endre sjekken kan berre flytte deg frå den første til den andre.

Symptomet: installasjonsprogrammet stoppar på den avleia distribusjonen din

Eit skript som les eit distribusjonsnamn og nektar å halde fram, fortel deg at forfattaren ikkje testa den avleia distribusjonen din. Det er ei støttefråsegn og ikkje eit teknisk faktum, og ho er ofte feil i den tydinga at pakken ville køyrt fint.

Problemet byrjar når omvegen blir planen. Endring av ei identitetsfil får sjekken til å passere, og pakken blir deretter lasta, eller ikkje lasta, mot køyretida som faktisk er installert. Feilar han der, hjelper inga vidare identitetsredigering.

Det nyttige trekket er difor å finne ut kva spørsmål installasjonsprogrammet stilte, og deretter finne ut om svaret ville hatt noko å seie. Det er to separate undersøkingar, og berre den andre føresegn om pakken vil fungere.

Tre versjonar folk kallar systemversjonen

Ei distribusjonsutgåve namngjev eit pakka miljø. Ein C-bibliotekversjon namngjev ein køyretidsimplementasjon og utgåva av han. Ein kompilatorversjon namngjev ei verktøykjede. I samtale kallar folk alle tre “systemversjonen”, og i eit installasjonsprogram er dei ikkje utskiftbare.

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

Eit førehandsbygd program ventar køyretida som fanst då det vart lenka. Å byte kompilatorar på verten lenkar det ikkje på nytt, og ei nyare verktøykjede endrar ingenting i lastarsymbola som binærfilen ber om. Arkitektur tel igjen separat, fordi ein 32-bits pakke på eit 64-bits system feilar av grunnar ingen versjonsstreng forklarer.

Ta vare på dei fire utskriftene saman med rapporten. Dei tek ti sekund å samle inn, og dei svarar på dei fleste spørsmåla ein vedlikehaldar elles ville stilt deg på e-post.

Les feilen, ikkje sjekken

Den første oppstartsfeilen er beviset. Ei melding om eit manglande delt objekt, eller om ein symbolversjon lastaren ikkje kan oppfylle, er eit køyretidsavhengigheitsproblem. Ei melding som gentek distribusjonsnamnet, er igjen attkjenningssjekken, på ein annan stad.

dokumentasjonen for den dynamiske lenkaren skildrar korleis bibliotekssøk fungerer og kvar lastaren leitar. Å endre ei distribusjonsetikett legg ikkje til ei mappe i den søkjestien, og difor verkar den andre feilen urelatert til den første.

Ikkje grip til ldd på ei nedlasta køyrbar fil som eit tilfeldig første steg. Den eiga handboka åtvarar om at ho kan køyre programmet under visse omstende, og å køyre eit ikkje-klarert installasjonsprogram er nettopp tilfellet den åtvaringa handlar om.

Kvifor redigering av strengen ikkje hjelper

Å forfalske identiteten til operativsystemet endrar korleis kvart program på maskinen ser seg sjølv. Pakkehandsamarar, støtteverktøy og andre program les den same fila, og ein verdi som tilfredsstiller eitt installasjonsprogram kan forvirre noko anna månader seinare.

Å erstatte biblioteka til verten med filer frå ein annan distribusjon er verre. Det kan øydeleggje urelatert programvare, det er usynleg for pakkehandsamaren, og det krev ein vedlikehaldsplan som ingen skriv ned. Dei endringane blir ikkje rettferdiggjorde av eitt restriktivt installasjonsprogram.

Viss sjekken verkeleg er ein attkjenningsfeil, kan vedlikehaldaren stadfeste han og skildre den støtta rettinga. Viss han ikkje er ein feil, er den støtta vegen eit bygg for plattformen din, og det svaret endrar seg ikkje fordi strengen vart redigert.

Skriv ein rapport vedlikehaldaren kan handle på

Noter distribusjonen og utgåva, arkitekturen, VPN-utgåva, den nøyaktige vilkåret som vart avvist, og den første køyretidsfeilen viss du kom så langt. Noter om du endra noko, fordi ein rapport frå eit endra system er ein annan rapport.

Hald det opphavlege installasjonsprogrammet uendra og skildre sjekken i staden for å gå rundt han. Den skilnaden lèt vedlikehaldaren skilje ein altfor snever attkjenningsregel frå ei reell binær kompatibilitetsgrense, og det er to svært ulike feil med to svært ulike rettingar.

Viss svaret er at plattformen din ikkje blir støtta, er det eit brukbart resultat. Det fortel deg å leite etter eit støtta bygg i staden for å bruke endå ein kveld på identitetsfiler som aldri var problemet.