Disztrónév, glibc vagy fordító: mit ellenőriz a telepítő

A telepítő kiírja, hogy “unsupported distribution”, átírsz egy karakterláncot, és tovább megy, amíg egy perccel később meg nem bukik egy betöltőhibával. Ez a sorrend az a tünet, amit érdemes felismerni: az első hiba felismerési ellenőrzés volt, a második pedig kompatibilitási határ. Két különböző probléma, amelyek véletlenül ugyanabban a terminálban bukkannak fel. Az ellenőrzés átírása csak az elsőtől a másodikig vihet el.

A tünet: a telepítő megáll a származtatott disztródon

Egy szkript, amely beolvassa a disztribúció nevét és nem hajlandó folytatni, azt mondja, hogy a szerzője nem tesztelte a származtatott disztródat. Ez támogatási nyilatkozat, nem technikai tény, és gyakran téves abban az értelemben, hogy a csomag szépen futna.

A baj akkor kezdődik, amikor a kerülőút lesz a terv. Egy identitásfájl módosítása átviszi az ellenőrzést, és a csomag ezután betöltődik, vagy nem töltődik be, a ténylegesen telepített futtatókörnyezethez képest. Ha ott elbukik, további identitásmódosítás nem segít.

A hasznos lépés tehát kideríteni, melyik kérdést tette fel a telepítő, majd kideríteni, hogy a válasz számított volna-e. Ez két külön vizsgálat, és csak a második jósolja meg, hogy a csomag működni fog-e.

Három verzió, amit az emberek rendszerverziónak neveznek

Egy disztribúció-kiadás egy csomagolt környezetet nevez meg. Egy C könyvtár verziója egy futtatókörnyezet-implementációt és annak kiadását nevezi meg. Egy fordítóverzió egy eszközláncot nevez meg. Beszélgetésben az emberek mindhármat “a rendszerverziónak” nevezik, és egy telepítőben nem felcserélhetők.

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

Egy előre felépített alkalmazás a linkeléskor jelen lévő futtatókörnyezetre számít. A fordítók cseréje a gazdagépen nem linkeli újra, és egy újabb eszközlánc semmit nem változtat a betöltő szimbólumain, amelyeket a bináris kér. Az architektúra megint külön számít, mert egy 32 bites csomag egy 64 bites rendszeren olyan okokból bukik el, amelyeket egyetlen verziókarakterlánc sem magyaráz.

Tartsd meg a négy kimenetet a jelentés mellett. Összegyűjtésük tíz másodpercet vesz igénybe, és megválaszolják a legtöbb kérdést, amit egy karbantartó egyébként e-mailben tenne fel.

A hibát olvasd, ne az ellenőrzést

Az első indítási hiba a bizonyíték. Egy hiányzó megosztott objektumról vagy egy olyan szimbólumverzióról szóló üzenet, amelyet a betöltő nem tud kielégíteni, futtatókörnyezet-függőségi probléma. Az az üzenet, amely megismétli a disztribúció nevét, megint a felismerési ellenőrzés, más helyen.

A a dinamikus szerkesztő dokumentációja leírja, hogyan működik a könyvtárkeresés, és hol keres a betöltő. Egy disztribúciócímke módosítása nem ad hozzá könyvtárat ahhoz a keresési útvonalhoz, ezért tűnik a második hiba függetlennek az elsőtől.

Ne nyúlj a ldd-hoz egy letöltött futtatható fájlon rutinszerű első lépésként. A saját kézikönyve figyelmeztet, hogy bizonyos körülmények között végrehajthatja a programot, és egy nem megbízható telepítő futtatása pontosan az az eset, amiről ez a figyelmeztetés szól.

Miért nem segít a karakterlánc átírása

Az operációs rendszer identitásának hamisítása megváltoztatja, hogyan látja magát a gépen minden program. A csomagkezelők, támogató eszközök és más alkalmazások ugyanazt a fájlt olvassák, és egy érték, amely kielégít egy telepítőt, hónapokkal később összezavarhat valami mást.

A gazdagép könyvtárainak lecserélése egy másik disztribúció fájljaira rosszabb. Eltörhet kapcsolódó szoftvereket, láthatatlan a csomagkezelő számára, és olyan karbantartási tervet igényel, amelyet senki nem ír le. Ezeket a változtatásokat egyetlen korlátozó telepítő sem indokolja.

Ha az ellenőrzés valóban felismerési hiba, a karbantartó megerősítheti, és leírhatja a támogatott javítást. Ha nem hiba, a támogatott út egy build a platformodra, és ez a válasz nem változik attól, hogy a karakterláncot szerkesztették.

Írj olyan jelentést, amelyre a karbantartó tud cselekedni

Jegyezd fel a disztribúciót és kiadást, az architektúrát, a VPN kiadását, a pontosan elutasított feltételt és az első futtatókörnyezeti hibát, ha odáig eljutottál. Jegyezd meg, módosítottál-e bármit, mert egy módosított rendszerből származó jelentés más jelentés.

Hagyd az eredeti telepítőt változatlanul, és írd le az ellenőrzést ahelyett, hogy megkerülnéd. Ez a megkülönböztetés teszi lehetővé a karbantartónak, hogy elválassza a túl szűk felismerési szabályt egy valódi bináris kompatibilitási határtól, márpedig ez két nagyon különböző hiba, két nagyon különböző javítással.

Ha az a válasz, hogy a platformod nem támogatott, az használható eredmény. Azt mondja, keress támogatott buildet, ahelyett hogy még egy estét identitásfájlokra szánnál, amelyek soha nem voltak a probléma.