Distronamn, glibc eller kompilator: vad installationsprogrammet kontrollerar

Installationsprogrammet skriver ut “unsupported distribution”, du ändrar en sträng och det fortsätter tills det misslyckas en minut senare med ett loader-fel. Den sekvensen är symtomet som är värt att känna igen: det första felet var en igenkänningskontroll och det andra är en kompatibilitetsgräns. Det är två olika problem som råkar dyka upp i samma terminal. Att ändra kontrollen kan bara flytta dig från det första till det andra.

Symtomet: installationsprogrammet stannar på din härledda distribution

Ett skript som läser ett distributionsnamn och vägrar fortsätta säger att dess författare inte testade din härledda distribution. Det är ett supportuttalande och inte ett tekniskt faktum, och det är ofta fel i den meningen att paketet skulle fungera bra.

Problemet börjar när kringgåendet blir planen. Att ändra en identitetsfil får kontrollen att passera, och paketet laddas sedan, eller laddas inte, mot den runtime som faktiskt är installerad. Om det misslyckas där hjälper ingen ytterligare identitetsändring.

Det användbara draget är därför att ta reda på vilken fråga installationsprogrammet ställde, och sedan ta reda på om svaret hade spelat roll. Det är två separata undersökningar och bara den andra förutsäger om paketet kommer att fungera.

Tre versioner som folk kallar systemversionen

En distributionsutgåva namnger en paketerad miljö. En C-biblioteksversion namnger en runtime-implementering och dess utgåva. En kompilatorversion namnger en verktygskedja. I samtal kallar folk alla tre “systemversionen”, och i ett installationsprogram är de inte utbytbara.

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

Ett förbyggt program förväntar sig den runtime som fanns när det länkades. Att byta kompilatorer på värden länkar det inte igen, och en nyare verktygskedja ändrar ingenting i de loadersymboler som binärfilen begär. Arkitekturen spelar återigen roll separat, eftersom ett 32-bitars paket på ett 64-bitars system misslyckas av skäl som ingen versionssträng förklarar.

Spara de fyra utdata tillsammans med rapporten. De tar tio sekunder att samla in och de svarar på de flesta frågor som en underhållare annars skulle ställa dig via e-post.

Läs felet, inte kontrollen

Det första startfelet är beviset. Ett meddelande om ett saknat delat objekt, eller om en symbolversion som loadern inte kan uppfylla, är ett runtime-beroendeproblem. Ett meddelande som upprepar distributionsnamnet är återigen igenkänningskontrollen, någon annanstans.

dokumentationen för den dynamiska länkaren beskriver hur biblioteksökning fungerar och var loadern söker. Att ändra en distributionetikett lägger inte till en katalog i den sökvägen, och därför verkar det andra felet orelaterat till det första.

Ta inte till ldd på en nedladdad körbar fil som ett vanligt första steg. Dess egen manual varnar för att den under vissa omständigheter kan köra programmet, och att köra ett ej betrott installationsprogram är just det fall som den varningen handlar om.

Varför redigering av strängen inte hjälper

Att förfalska operativsystemets identitet ändrar hur varje program på maskinen ser sig självt. Pakethanterare, supportverktyg och andra program läser samma fil, och ett värde som tillfredsställer ett installationsprogram kan förvirra något annat månader senare.

Att ersätta värdens bibliotek med filer från en annan distribution är värre. Det kan förstöra orelaterad programvara, det är osynligt för pakethanteraren, och det kräver en underhållsplan som ingen skriver ner. De ändringarna rättfärdigas inte av ett enda restriktivt installationsprogram.

Om kontrollen verkligen är en igenkänningsdefekt kan underhållaren bekräfta den och beskriva den stödda rättelsen. Om den inte är en defekt är den stödda vägen ett bygge för din plattform, och det svaret ändras inte för att strängen redigerades.

Skriv en rapport som underhållaren kan agera på

Notera distributionen och utgåvan, arkitekturen, VPN-utgåvan, det exakta villkor som avvisades, och det första runtime-felet om du kom så långt. Notera om du ändrade något, eftersom en rapport från ett ändrat system är en annan rapport.

Låt det ursprungliga installationsprogrammet vara oförändrat och beskriv kontrollen istället för att gå runt den. Den skillnaden gör det möjligt för underhållaren att skilja en alltför snäv igenkänningsregel från en verklig binär kompatibilitetsgräns, och det är två mycket olika buggar med två mycket olika rättelser.

Om svaret är att din plattform inte stöds är det ett användbart resultat. Det säger åt dig att leta efter ett stött bygge istället för att lägga ännu en kväll på identitetsfiler som aldrig var problemet.