VPN-ის ინსტალერი ამბობს 32-bit-ს: სამაგიეროდ შეამოწმეთ ELF-ის სათაური

ჩამოტვირთვის გვერდი ამბობს 32-bit-ს, ფაილი ეშვება Raspberry Pi-ზე და ინსტალერი ისეთი შეტყობინებით ვარდება, რომელიც პრობლემის არც ერთ სასარგებლო ნაწილს არ ასახელებს. ორი სრულიად განსხვავებული შესრულებადი ფაილი ორივე 32-bit-ად ითვლება ELF-ის მნიშვნელობით და მათგან მხოლოდ ერთს შეუძლია ამ დაფაზე მუშაობა. კლასის ველი ერთი ფაქტია, მანქანის ველი მეორე, და ფაილის სახელი საიმედოდ არც ერთს არ გიყვებათ. წაიკითხეთ სათაური სანამ ბიბლიოთეკას შეცვლით ან სხვა სარკეს ცდით.

კლასი ამბობს სიტყვის ზომას, მანქანა ინსტრუქციათა სიმრავლეს

Linux-ის ELF ცნობარი ფაილის სათაურში განსაზღვრავს კლასის ველსა და მანქანის ველს და ორივე სხვადასხვა კითხვას პასუხობს. კლასი ამბობს იყენებს ფაილი 32-bit-იან თუ 64-bit-იან ფორმას; მანქანა ამბობს რომელი ინსტრუქციათა სიმრავლისთვის აშენდა. 32-bit-იანი x86 build და 32-bit-იანი ARM build პირველში თანხმდებიან და მეორეში განსხვავდებიან. ასე აწვდის სწორი სიტყვის ზომის დამპირებელი ეტიკეტი მაინც კოდს, რომლის გაშიფვრაც პროცესორს არ შეუძლია. წაკითხვადი მესამე მნიშვნელობა მოთხოვნილი ინტერპრეტატორია, რომელსაც პროგრამის სათაურები ასახელებენ, როცა ბინარი ერთს აცხადებს.

readelf -h -- ./vendor-vpn
readelf -l -- ./vendor-vpn
readelf -d -- ./vendor-vpn | grep NEEDED

პირველი ბრძანება ბეჭდავს სათაურს, მეორე ბეჭდავს პროგრამის სათაურებს, თუ ფაილს აქვს, ხოლო მესამე ჩამოთვლის საზიარო ობიექტებს, რომლებიც ჩამტვირთველს დასჭირდება. ჩაწერეთ კლასი, მანქანა და ინტერპრეტატორი ერთად, რადგან ეს სამი მნიშვნელობაა მთელი თავსებადობის საკითხი ამ დონეზე. სამიდან არც ერთი არ ჩანს ჩამოტვირთვის ღილაკზე, ამიტომ ფაილი უნდა შემოწმდეს და არა აღიწეროს.

რომელ ინტერპრეტატორს ითხოვს ის ბირთვისგან

ინტერპრეტატორს გამომცხადებელი შესრულებადი ფაილი ბირთვისგან ითხოვს ერთ კონკრეტულ ჩამტვირთველის გზას. როცა ეს ჩამტვირთველი არ არის, გაშვება ვარდება მაშინაც, როცა თქვენ მიერ დასახელებული ფაილი ზუსტად იქ წევს. ეს არის ის წერტილი, სადაც ადამიანები წყვეტენ, რომ ჩამოტვირთვა დაზიანებულია, მაშინ როცა ნამდვილი პასუხი ჩამტვირთველია, რომელსაც დისტრიბუცია არ აწვდის.

შეუსაბამეთ ჩამტვირთველი იმ სისტემას, რომელსაც ნამდვილად ამუშავებთ: OS-ის გამოშვება, მომხმარებლის სივრცის არქიტექტურა და პაკეტი, რომელიც ჩამტვირთველს აწვდის. 64-bit-იან ბირთვს 32-bit-იანი მომხმარებლის სივრცის გაშვება შეუძლია მხოლოდ მაშინ, როცა ეს სივრცე და მისი ჩამტვირთველი დაყენებულია, ამიტომ პროცესორის შესაძლებლობები გადამწყვეტი ფაქტორი არ არის. ერთი მოკლე შემოწმება ინტერპრეტატორს ერთ სტრიქონში ასახელებს და ნაკლებ დროს იკავებს, ვიდრე მხარდაჭერის ბილეთი. Shell სკრიპტი ისევ სხვანაირად ვარდება, რადგან მისი ინტერპრეტატორი პირველ სტრიქონშია დასახელებული და არა ELF-ის სათაურში, და ამ სტრიქონის წაკითხვა არაფრად ღირს.

file --brief ./vendor-vpn

შეუსაბამეთ ჩამოტვირთვა პაკეტის არქიტექტურას

დისტრიბუციათა პაკეტების არქიტექტურები იმავე განსხვავებას თავიანთ ლექსიკაში კოდირებენ და სწორედ ამ ლექსიკას მიუთითებს მომწოდებლის მხარდაჭერის განცხადება. შეადარეთ თქვენი პაკეტების მენეჯერის მოხსენებული მნიშვნელობა მომწოდებლის დოკუმენტირებულ მნიშვნელობას, ნაცვლად იმისა, რომ მარკეტინგული ეტიკეტი ფაილის სახელს შეადაროთ. პრობლემის შემქმნელი წყვილებია amd64 arm64-ის წინააღმდეგ და armhf armel-ის წინააღმდეგ, რადგან ყოველი წყვილი ჩამოტვირთვათა სიაში ურთიერთშემცვლელად გამოიყურება. x64-ით ან ia32-ით დამთავრებული ფაილის სახელი build-ის სამიზნეს აღწერს და არა მანქანას, რომელიც მას ინახავს.

ყოველი სტრიქონი შემთხვევაა, როცა სიტყვის ზომა სწორად გამოიყურება და კოდი მაინც არასწორად იქცევა, ან როცა ის იწყება და შემდეგ ერთი ფენით ქვემოთ ვარდება. წაიკითხეთ ინტერპრეტატორის სვეტი როგორც მკაცრი მოთხოვნა და არა როგორც მინიშნება, რადგან ბირთვი ამ გზას თქვენი კოდის რომელიმე ნაწილის გაშვებამდე წყვეტს. ემულაცია განლაგების გადაწყვეტილებაა საკუთარი წარმადობისა და მხარდაჭერის შედეგებით და ფართო სიტყვის ზომის რეკლამირებული პროცესორი მას არასოდეს გულისხმობს.

dpkg --print-architecture

ENOEXEC და ENOENT სხვადასხვა მარცხია

გაშვების ეტაპი ორი შეცდომიდან ერთს აცნობებს და ისინი სხვადასხვა პრობლემაზე მიუთითებენ. შეცდომის მნიშვნელობის წაკითხვა მარცხს სხვა რამის გაშვებამდე აკლასიფიცირებს.

ENOEXEC ნიშნავს, რომ ფორმატი არ იქნა ცნობილი: არასწორი არქიტექტურა, არასწორი კლასი ან რაღაც, რაც საერთოდ არ არის შესრულებადი ფაილი. ENOENT ELF ფაილზე ჩვეულებრივ ნიშნავს, რომ ინტერპრეტატორი აკლია, თუმცა მოთხოვნილი ფაილი არსებობს. იგივე ENOENT შეიძლება ნიშნავდეს სკრიპტის ინტერპრეტატორის არარსებობასაც, ამიტომ სკრიპტის პირველ სტრიქონს მნიშვნელობა აქვს. ნებისმიერ შემთხვევაში შეტყობინება ფენას ასახელებს და ყოველი „ვერ მოიძებნა“-ს დაკარგულ კონფიგურაციად მიჩნევა გამოძიებას არასწორი მიმართულებით აგზავნის. ციტირეთ შეცდომის მნიშვნელობა ბილეთში, რადგან ის გარშემო წინადადებაზე უკეთ უძლებს გადმოყოლას.

რა არ უნდა გააკეთოთ, როცა ბინარი არ ირთვება

აუხსნელი ბინარის shell-ის გარსში ძალით გატარება მას არ ამუშავებს. ნუ გაუშვებთ დამოკიდებულებათა შემმოწმებელს უყურადღებოდ ფაილზე, რომელსაც არ ენდობით, რადგან მისი გაშვება ზოგიერთ გარემოებაში ბინარიდან კოდს შეასრულებს. ნუ დაამატებთ ჩამტვირთველის სიმბოლურ ბმულებს, ნუ შეცვლით ჰოსტის ბიბლიოთეკებს და ნუ ჩამოიტვირთავთ ძველ არქივს მესამე მხარის სარკიდან შეტყობინების გასვლელად. თითოეული მათგანი ცვლილების არეალს აფართოებს და არ ეხება იმ შეუსაბამობას, რომელიც სათაურმა უკვე დაასახელა.

როცა მომწოდებელს მიმართავთ, გაგზავნეთ მნიშვნელობები და არა ამბავი: OS-ის გამოშვება, პაკეტის არქიტექტურა, კლასისა და მანქანის სტრიქონები, მოთხოვნილი ინტერპრეტატორი და შეცდომის პირველი სტრიქონი. ეს ნაკრები მხარდაჭერის კითხვებს უფრო სწრაფად წყვეტს, ვიდრე ჩავარდნილი ინსტალერის ეკრანის სურათი. ძველი არტეფაქტები და გახსენებული ფორუმის გამონაბოლქვი მიმდინარე მხარდაჭერის მატრიცა არ არის და მას შემდეგ, რაც ბუნებრივი ბინარი ჩაიტვირთება, პროფილი, ავთენტიფიკაცია და მარშრუტიზაცია ცალკე სამუშაოდ რჩება.