هل ملف 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

يعرض الأمر الأول مسار المفسّر الذي يطلبه الملف الثنائي. والثاني يتحقق من وجود ذلك المسار، وهو ما يفصل بين بناء خاطئ ومحمّل مفقود.

لا تشغّل أداة سرد الاعتماديات على ملف ثنائي غير موثوق، لأن بعض التنفيذات تستطيع تشغيل الملف الذي تفحصه. أبقِ الفحص للقراءة فقط وقاوم إضافة روابط رمزية للمحمّل لجعل بناء غير مدعوم يبدأ.

اطلب بناءً والحقائق في يدك

أرسل إلى المورّد إصدار نظام التشغيل، ومعمارية الحزم، وقيم الفئة والآلة، وأول رسالة خطأ. تلك التركيبة تستحق إجابة مفيدة، بينما لقطة شاشة لفشل عام تستحق قالب دعم.

أبقِ سؤال الملف الثنائي منفصلًا عن سؤال الإعداد. فبمجرد أن يبدأ البناء الصحيح، تظل الملفات الشخصية وبيانات الاعتماد والمسارات مشاكلها الخاصة، ولن يجعل أي قدر من تحرير الملف الشخصي ملفًا ثنائيًا بمعمارية خاطئة يعمل.