Ваш бінарний файл VPN зібрано для цього процесора? Прочитайте заголовок ELF

Обидва файли 32-бітні, і лише один із них працює на вашій платі. Збірка ELF32 для Intel і збірка ELF32 для ARM збігаються в полі класу й розходяться в усьому, що має значення. Сторінка завантаження з варіантом 32 біти майже нічого вам не сказала, доки ви не прочитаєте заголовок файлу, який справді завантажили. Перейменування не змінює жодної інструкції.

Клас і машина відповідають на різні питання

Поле класу повідомляє, чи використовує файл 32-бітні або 64-бітні структури. Поле машини називає набір інструкцій, для якого файл скомпільовано. Читати лише перше — це шлях, яким збірка x86 потрапляє на плату ARM з іменем файлу, що виглядає цілком правдоподібно. Обидва значення походять з однієї команди, тому пропустити одне так легко.

Та сама плутанина стосується 64-бітних позначок, де aarch64 і x86-64 поділяють розмір слова й жодної інструкції. Сторінка постачальника, яка пропонує одне завантаження 64 біти, описує його власну збірку, а не вашу машину. Перевіряйте заголовок файлу, а не заголовок стовпця на сторінці.

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

Перша команда друкує заголовок, включно з класом і машиною. Друга показує заголовки програми, де міститься запит інтерпретатора. Третя дає один рядок, коли таблиця — це більше, ніж вам потрібно.

Додавання дозволу на виконання або виправлення перевірки дистрибутива нічого не перекладає. Емуляція, там де платформа її підтримує, — це рішення про розгортання з власною ціною продуктивності та залежностей.

Прочитайте заголовок перед запуском інсталятора

Огляньте довірений артефакт, перш ніж щось із нього виконувати. Інсталятор, що зривається на півдорозі, може залишити замінені бібліотеки й нічого працюючого, а це гірша відправна точка, ніж архів, з якого ви почали. Огляд заголовка лише для читання й оборотний у тому сенсі, що в системі нічого не змінюється.

Порівняйте поле машини з архітектурою пакетів працюючої системи, а не з маркетинговою назвою плати. Процесору 64 біти з 32-бітним простором користувача потрібна 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

Перша команда показує шлях інтерпретатора, який запитує бінарний файл. Друга перевіряє, чи існує цей шлях, що відокремлює неправильну збірку від відсутнього завантажувача.

Не запускайте засіб списку залежностей на недовіреному бінарному файлі, бо деякі реалізації можуть виконувати файл, який перевіряють. Тримайте огляд лише для читання й опирайтеся бажанню додати символічні посилання завантажувача, щоб запустити непідтримувану збірку.

Попросіть збірку, маючи факти на руках

Надішліть постачальнику версію ОС, архітектуру пакетів, значення класу й машини та перше повідомлення про помилку. Така комбінація заслуговує на корисну відповідь, тоді як знімок екрана загальної невдачі заслуговує на шаблон підтримки.

Тримайте питання про бінарний файл окремо від питання про конфігурацію. Щойно правильна збірка запуститься, профілі, облікові дані й маршрути залишаються їхніми власними проблемами, і жодне редагування профілю не змусить бінарний файл із неправильною архітектурою працювати.