Distronavn, glibc eller compiler: hvad installationsprogrammet kontrollerer

Installationsprogrammet skriver “unsupported distribution”, du retter én streng, og det fortsætter, indtil det et minut senere fejler med en loader-fejl. Den sekvens er symptomet, der er værd at genkende: den første fejl var et genkendelsestjek, og den anden er en kompatibilitetsgrænse. Det er to forskellige problemer, som tilfældigt optræder i samme terminal. At rette tjekket kan kun flytte dig fra det første til det andet.

Symptomet: installationsprogrammet stopper på din afledte distribution

Et script, der læser et distributionsnavn og nægter at fortsætte, fortæller dig, at dets forfatter ikke har testet din afledte distribution. Det er en supportudtalelse frem for en teknisk kendsgerning, og den er ofte forkert i den forstand, at pakken ville køre fint.

Problemet begynder, når omvejen bliver planen. Ændring af en identitetsfil får tjekket til at bestå, og pakken indlæses derefter, eller undlader at indlæses, mod det runtime, der faktisk er installeret. Hvis den fejler der, hjælper ingen yderligere identitetsredigering.

Det nyttige træk er derfor at finde ud af, hvilket spørgsmål installationsprogrammet stillede, og derefter finde ud af, om svaret ville have betydet noget. Det er to separate undersøgelser, og kun den anden forudsiger, om pakken vil fungere.

Tre versioner, som folk kalder systemversionen

En distributionsudgivelse navngiver et pakket miljø. En C-biblioteksversion navngiver en runtime-implementering og dens udgivelse. En compilerversion navngiver en værktøjskæde. Folk kalder alle tre “systemversionen” i samtale, og de kan ikke udskiftes i et installationsprogram.

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

Et forudbygget program forventer det runtime, der var til stede, da det blev linket. At skifte compilere på værten linker det ikke igen, og en nyere værktøjskæde ændrer intet ved de loader-symboler, som den binære fil beder om. Arkitektur betyder igen noget for sig, fordi en 32-bit pakke på et 64-bit system fejler af grunde, som ingen versionsstreng forklarer.

Gem de fire output sammen med rapporten. De tager ti sekunder at indsamle, og de besvarer de fleste af de spørgsmål, en vedligeholder ellers ville stille dig pr. e-mail.

Læs fejlen, ikke tjekket

Den første opstartsfejl er beviset. En meddelelse om et manglende delt objekt eller om en symbolversion, som loaderen ikke kan opfylde, er et runtime-afhængighedsproblem. En meddelelse, der gentager distributionsnavnet, er genkendelsestjekket igen, på et andet sted.

dokumentationen for den dynamiske linker beskriver, hvordan bibliotekssøgning fungerer, og hvor loaderen søger. Ændring af en distributionsetikette føjer ikke en mappe til den søgesti, og derfor ser den anden fejl ud til at være uden forbindelse med den første.

Grib ikke efter ldd på en downloadet eksekverbar fil som et tilfældigt første skridt. Dens egen manual advarer om, at den under visse omstændigheder kan køre programmet, og at køre et ikke-betroet installationsprogram er netop det tilfælde, den advarsel handler om.

Hvorfor redigering af strengen ikke hjælper

Falsk identitet af operativsystemet ændrer, hvordan hvert program på maskinen ser sig selv. Pakkehåndteringer, supportværktøjer og andre programmer læser den samme fil, og en værdi, der tilfredsstiller ét installationsprogram, kan forvirre noget andet måneder senere.

At erstatte værtens biblioteker med filer fra en anden distribution er værre. Det kan ødelægge urelateret software, det er usynligt for pakkehåndteringen, og det kræver en vedligeholdelsesplan, som ingen skriver ned. De ændringer retfærdiggøres ikke af ét restriktivt installationsprogram.

Hvis tjekket virkelig er en genkendelsesfejl, kan vedligeholderen bekræfte det og beskrive den understøttede rettelse. Hvis det ikke er en fejl, er den understøttede vej et byg til din platform, og det svar ændrer sig ikke, fordi strengen blev redigeret.

Skriv en rapport, som vedligeholderen kan handle på

Notér distributionen og udgivelsen, arkitekturen, VPN-udgivelsen, den præcise betingelse, der blev afvist, og den første runtime-fejl, hvis du kom så langt. Angiv, om du ændrede noget, fordi en rapport fra et ændret system er en anden rapport.

Hold det originale installationsprogram uændret og beskriv tjekket i stedet for at omgå det. Den skelnen lader vedligeholderen adskille en alt for snæver genkendelsesregel fra en reel binær kompatibilitetsgrænse, som er to meget forskellige fejl med to meget forskellige rettelser.

Hvis svaret kommer tilbage, at din platform ikke understøttes, er det et brugbart resultat. Det fortæller dig at lede efter et understøttet byg i stedet for at bruge endnu en aften på identitetsfiler, der aldrig var problemet.