Ist Ihr VPN-Binary für diese CPU gebaut? Lesen Sie den ELF-Header

Beide Dateien sind 32-Bit, und nur eine davon läuft auf Ihrer Platine. Ein ELF32-Build für Intel und ein ELF32-Build für ARM stimmen im Klassenfeld überein und unterscheiden sich in allem, was zählt. Eine Downloadseite mit einer 32-Bit-Option hat Ihnen fast nichts gesagt, bis Sie den Header der Datei lesen, die Sie tatsächlich heruntergeladen haben. Umbenennen ändert keine einzige Instruktion.

Klasse und Maschine beantworten verschiedene Fragen

Das Klassenfeld sagt, ob die Datei 32-Bit- oder 64-Bit-Strukturen verwendet. Das Maschinenfeld nennt den Befehlssatz, für den die Datei kompiliert wurde. Nur das erste zu lesen ist der Weg, auf dem ein x86-Build auf einer ARM-Platine landet, mit einem Dateinamen, der völlig plausibel aussieht. Beide Werte stammen aus demselben Befehl, deshalb ist es so leicht, einen zu überspringen.

Dieselbe Verwechslung gilt für 64-Bit-Bezeichnungen, bei denen aarch64 und x86-64 eine Wortgröße und überhaupt keine Instruktionen teilen. Eine Herstellerseite, die einen 64-Bit-Download auflistet, beschreibt ihr eigenes Build, nicht Ihre Maschine. Prüfen Sie den Header der Datei statt der Spaltenüberschrift auf der Seite.

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

Der erste Befehl gibt den Header aus, einschließlich Klasse und Maschine. Der zweite zeigt Programmheader, in denen eine Interpreter-Anforderung steht. Der dritte gibt Ihnen eine Zeile, wenn eine Tabelle mehr ist, als Sie brauchen.

Ausführungsrechte hinzuzufügen oder eine Distributionsprüfung zu patchen übersetzt nichts. Emulation ist, wo die Plattform sie unterstützt, eine Bereitstellungsentscheidung mit eigenen Kosten für Leistung und Abhängigkeiten.

Lesen Sie den Header, bevor Sie das Installationsprogramm ausführen

Untersuchen Sie ein vertrauenswürdiges Artefakt, bevor Sie etwas daraus ausführen. Ein Installationsprogramm, das auf halbem Weg scheitert, kann ersetzte Bibliotheken und nichts Funktionierendes hinterlassen, was ein schlechterer Ausgangspunkt ist als das Archiv, mit dem Sie begonnen haben. Die Header-Prüfung ist schreibgeschützt und in dem Sinne umkehrbar, dass sich am System nichts ändert.

Vergleichen Sie das Maschinenfeld mit der Paketarchitektur des laufenden Systems, nicht mit dem Marketingnamen der Platine. Eine 64-Bit-CPU mit 32-Bit-Userland braucht das 32-Bit-Build, und dieses Detail entscheidet, welcher Download nativ ist. Die Fähigkeit der Platine ist nicht die Einschränkung; das installierte Userland ist es.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Der erste Befehl meldet die Architektur, für die das System Pakete installiert, und das ist der Wert, der übereinstimmen muss. Die anderen beiden beschreiben den Kernel und die Wortgröße, und sie können beim Multiarch-Install vom Userland abweichen.

Wenn diese Antworten nicht übereinstimmen, entscheiden Sie, welche der Hersteller unterstützt, bevor Sie ein weiteres Archiv herunterladen. Raten erzeugt eine Schleife von Installationen, die jeweils an einer anderen Stelle scheitern, und jeder Fehlschlag sieht wie ein neues Problem aus.

Prüfen Sie den Interpreter, nicht nur die Architektur

Eine dynamische ausführbare Datei zeichnet den Loader, den sie erwartet, in einem Programmheader auf. Auf einem System mit anderem Loader-Pfad weigert sich der Kernel, die Datei zu starten, obwohl das Maschinenfeld exakt übereinstimmt. Das ist der Fehlschlag, der Leute nach fehlenden Bibliotheken suchen lässt.

Die Fehlermeldung sagt Ihnen, in welchem Fall Sie sich befinden, und die beiden Fälle sind leicht zu verwechseln. Eine Format- oder Architekturablehnung unterscheidet sich von einer fehlenden Datei oder einem fehlenden Interpreter, und nur einer von ihnen wird durch die Installation eines anderen Pakets behoben.

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

Der erste Befehl zeigt den Interpreter-Pfad, den die Binärdatei anfordert. Der zweite prüft, ob dieser Pfad existiert, was ein falsches Build von einem fehlenden Loader trennt.

Führen Sie keinen Abhängigkeitslister gegen eine nicht vertrauenswürdige Binärdatei aus, denn manche Implementierungen können die Datei ausführen, die sie untersuchen. Halten Sie die Prüfung schreibgeschützt und widerstehen Sie der Versuchung, Loader-Symlinks hinzuzufügen, um ein nicht unterstütztes Build zu starten.

Bitten Sie um ein Build mit den Fakten in der Hand

Senden Sie dem Hersteller die OS-Version, die Paketarchitektur, die Klasse- und Maschinenwerte und die erste Fehlermeldung. Diese Kombination erhält eine brauchbare Antwort, während ein Screenshot eines allgemeinen Fehlers eine Support-Vorlage erhält.

Halten Sie die Binary-Frage von der Konfigurationsfrage getrennt. Sobald das richtige Build startet, sind Profile, Anmeldedaten und Routen weiterhin ihre eigenen Probleme, und keine Profilbearbeitung bringt eine Binärdatei mit falscher Architektur zum Laufen.