Ձեր VPN բինարն այս պրոցեսորի համար է կառուցված? Կարդացեք ELF վերնագիրը

Երկու ֆայլերն էլ 32-բիթանոց են, և դրանցից միայն մեկն է աշխատում ձեր տախտակի վրա: Intel-ի համար ELF32 կառուցվածքը և ARM-ի համար ELF32 կառուցվածքը համընկնում են դասի դաշտում և տարբերվում են այն ամենում, ինչ կարևոր է: 32-բիթանոց տարբերակ առաջարկող ներբեռնման էջը ձեզ գրեթե ոչինչ չի ասել, մինչև չկարդաք այն ֆայլի վերնագիրը, որը դուք իրականում ներբեռնել եք: Անվանափոխումը ոչ մի հրահանգ չի փոխում:

Դասը և մեքենան պատասխանում են տարբեր հարցերի

Դասի դաշտը ասում է՝ ֆայլն օգտագործում է 32-բիթանոց, թե 64-բիթանոց կառուցվածքներ: Մեքենայի դաշտը նշում է հրահանգների բազմությունը, որի համար ֆայլը կոմպիլացվել է: Միայն առաջինը կարդալը այն ուղին է, որով x86 կառուցվածքը հայտնվում է ARM տախտակի վրա բացարձակ հավաստի թվացող ֆայլի անունով: Երկու արժեքներն էլ գալիս են նույն հրամանից, դրա համար էլ մեկը բաց թողնելը այդքան հեշտ է:

Նույն շփոթությունը վերաբերում է 64-բիթանոց պիտակներին, որտեղ aarch64-ը և x86-64-ը կիսում են բառի չափը և ոչ մի հրահանգ: Մեկ 64-բիթանոց ներբեռնում թվարկող մատակարարի էջը նկարագրում է իր սեփական կառուցվածքը, ոչ թե ձեր մեքենան: Ստուգեք ֆայլի վերնագիրը, ոչ թե էջի սյունակի վերնագիրը:

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

Առաջին հրամանը տպում է վերնագիրը՝ ներառյալ դասը և մեքենան: Երկրորդը ցույց է տալիս ծրագրի վերնագրերը, որտեղ գտնվում է ինտերպրետատորի հարցումը: Երրորդը ձեզ մեկ տող է տալիս, երբ աղյուսակն ավելին է, քան պետք է:

Կատարման թույլտվություն ավելացնելը կամ տարածման ստուգումը կարկատելը ոչինչ չի թարգմանում: Էմուլյացիան, որտեղ հարթակը դա աջակցում է, տեղակայման որոշում է՝ իր աշխատանքի և կախվածությունների ծախսով:

Կարդացեք վերնագիրը նախքան տեղադրիչը գործարկելը

Ստուգեք վստահելի արտեֆակտը նախքան դրանից ինչ-որ բան կատարեք: Կես ճանապարհին ձախողվող տեղադրիչը կարող է թողնել փոխարինված գրադարաններ և ոչինչ չաշխատող, ինչը ավելի վատ մեկնարկային կետ է, քան այն արխիվը, որով սկսել եք: Վերնագրի ստուգումը միայն ընթերցման է և շրջելի այն առումով, որ համակարգում ոչինչ չի փոխվում:

Համեմատեք մեքենայի դաշտը աշխատող համակարգի փաթեթների ճարտարապետության հետ, ոչ թե տախտակի շուկայական անվան հետ: 32-բիթանոց օգտատիրական տարածք աշխատեցնող 64-բիթանոց պրոցեսորին անհրաժեշտ է 32-բիթանոց կառուցվածքը, և այդ մանրամասնն է որոշում, թե որ ներբեռնումն է բնիկ: Տախտակի կարողությունը սահմանափակումը չէ. տեղադրված օգտատիրական տարածքն է:

dpkg --print-architecture
uname -m
getconf LONG_BIT

Առաջին հրամանը հաղորդում է ճարտարապետությունը, որի համար համակարգը տեղադրում է փաթեթներ, և դա այն արժեքն է, որը պետք է համընկնի: Մյուս երկուսը նկարագրում են միջուկը և բառի չափը, և դրանք կարող են տարբերվել օգտատիրական տարածքից բազմաճարտարապետ տեղադրման դեպքում:

Երբ այդ պատասխանները տարբերվում են, որոշեք, թե որն է աջակցում մատակարարը, նախքան մեկ այլ արխիվ ներբեռնելը: Գուշակելը ստեղծում է տեղադրումների հանգույց, որոնցից յուրաքանչյուրը ձախողվում է տարբեր կետում, և ամեն ձախողում նոր խնդիր է թվում:

Ստուգեք ինտերպրետատորը, ոչ միայն ճարտարապետությունը

Դինամիկ գործարկվող ֆայլը ծրագրի վերնագրում գրանցում է այն բեռնիչը, որն ակնկալում է: Այլ բեռնիչի ուղի ունեցող համակարգում միջուկը հրաժարվում է գործարկել ֆայլը, նույնիսկ երբ մեքենայի դաշտը ճշգրտորեն համընկնում է: Դա այն ձախողումն է, որը մարդկանց ուղարկում է բացակայող գրադարաններ փնտրելու:

Սխալի հաղորդագրությունը ասում է, թե որ դեպքում եք գտնվում, և երկու դեպքերը հեշտ է շփոթել: Ձևաչափի կամ ճարտարապետության մերժումը տարբերվում է բացակայող ֆայլից կամ ինտերպրետատորից, և դրանցից միայն մեկն է շտկվում մեկ այլ փաթեթ տեղադրելով:

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

Առաջին հրամանը ցույց է տալիս ինտերպրետատորի ուղին, որը պահանջում է բինարը: Երկրորդը ստուգում է՝ այդ ուղին գոյություն ունի, ինչը տարանջատում է սխալ կառուցվածքը բացակայող բեռնիչից:

Մի՛ գործարկեք կախվածությունների ցանկը վստահելի չհանդիսացող բինարի վրա, որովհետև որոշ իրականացումներ կարող են գործարկել այն ֆայլը, որը ստուգում են: Պահեք ստուգումը միայն ընթերցման և դիմացեք բեռնիչի սիմվոլիկ հղումներ ավելացնելու գայթակղությանը՝ չաջակցվող կառուցվածքը գործարկելու համար:

Խնդրեք կառուցվածք՝ փաստերը ձեռքում

Ուղարկեք մատակարարին ՕՀ թողարկումը, փաթեթների ճարտարապետությունը, դասի և մեքենայի արժեքները և առաջին սխալի հաղորդագրությունը: Այդ համադրությունը վաստակում է օգտակար պատասխան, մինչդեռ ընդհանուր ձախողման էկրանի պատկերը վաստակում է աջակցության ձևանմուշ:

Բինարի հարցը առանձին պահեք կոնֆիգուրացիայի հարցից: Երբ ճիշտ կառուցվածքը գործարկվի, պրոֆիլները, հավատարմագրերը և երթուղիները դեռևս իրենց խնդիրներն են, և պրոֆիլի խմբագրման ոչ մի քանակություն չի ստիպի սխալ ճարտարապետության բինարը աշխատել: