ایک ڈاؤن لوڈ صفحہ 32-bit کہتا ہے، فائل Raspberry Pi پر آتی ہے، اور انسٹالر ایسے پیغام کے ساتھ ناکام ہوتا ہے جو مسئلے کے کسی مفید حصے کا نام نہیں لیتا۔ دو بالکل مختلف قابلِ عمل فائلیں ELF کے معنی میں دونوں 32-bit شمار ہوتی ہیں، اور ان میں سے صرف ایک ہی اس بورڈ پر چل سکتی ہے۔ کلاس فیلڈ ایک حقیقت ہے، مشین فیلڈ دوسری، اور فائل کا نام آپ کو دونوں میں سے کوئی بھی قابلِ اعتبار طور پر نہیں بتاتا۔ لائبریری بدلنے یا دوسرا آئینہ آزمانے سے پہلے ہیڈر پڑھیں۔

کلاس لفظ کا سائز بتاتی ہے، مشین ہدایات کا مجموعہ

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 صارف کی جگہ تبھی چلا سکتا ہے جب وہ جگہ اور اس کا لوڈر نصب ہوں، لہٰذا پروسیسر کی صلاحیتیں فیصلہ کن عنصر نہیں ہیں۔ ایک مختصر جانچ انٹرپریٹر کا نام ایک ہی سطر میں بتاتی ہے، اور یہ معاونتی ٹکٹ سے کم وقت لیتی ہے۔ شیل اسکرپٹ پھر مختلف انداز میں ناکام ہوتی ہے، کیونکہ اس کا انٹرپریٹر ELF ہیڈر میں نہیں بلکہ پہلی سطر میں نامزد ہوتا ہے، اور اس سطر کو پڑھنے میں کچھ نہیں لگتا۔

file --brief ./vendor-vpn

ڈاؤن لوڈ کو پیکیج کی ساخت سے ملائیں

تقسیموں کی پیکیج ساختیں اسی فرق کو اپنی اصطلاحات میں انکوڈ کرتی ہیں، اور فروش کا معاونتی بیان انہی اصطلاحات کا حوالہ دیتا ہے۔ آپ کے پیکیج مینیجر کا بتایا ہوا قدر فروش کے دستاویزی قدر سے موازنہ کریں، مارکیٹنگ لیبل کا فائل نام سے موازنہ کرنے کے بجائے۔ مشکلات پیدا کرنے والے جوڑے amd64 بمقابلہ arm64، اور armhf بمقابلہ armel ہیں، کیونکہ ہر جوڑا ڈاؤن لوڈ فہرست میں قابلِ تبادلہ نظر آتا ہے۔ x64 یا ia32 پر ختم ہونے والا فائل نام build کا ہدف بتاتا ہے، اسے رکھنے والی مشین نہیں۔

Label on the downloadELF classe_machineInterpreter the kernel wantsHow it fails on the wrong host
amd64ELF64x86-64/lib64/ld-linux-x86-64.so.2Immediate exec failure on an ARM board
armhfELF32ARM/lib/ld-linux-armhf.so.3Loads on a soft-float system, then fails on a float ABI call
i386ELF32Intel 80386/lib/ld-linux.so.2Exec format error where no 32-bit loader package exists

ہر سطر وہ موقع ہے جہاں لفظ کا سائز درست لگتا ہے اور کوڈ پھر بھی غلط برتاؤ کرتا ہے، یا جہاں یہ شروع ہو کر پھر ایک طبقہ نیچے ناکام ہوتا ہے۔ انٹرپریٹر کے کالم کو اشارہ نہیں بلکہ سخت تقاضا سمجھ کر پڑھیں، کیونکہ کرنل آپ کے کسی بھی کوڈ کے چلنے سے پہلے وہ راستہ حل کر دیتا ہے۔ ایمولیشن اپنے کارکردگی اور معاونت کے نتائج کے ساتھ تعیناتی کا فیصلہ ہے، اور چوڑے لفظ کے سائز کی تشہیر کرنے والا پروسیسر اسے کبھی مضمر نہیں کرتا۔

dpkg --print-architecture

ENOEXEC اور ENOENT مختلف ناکامیاں ہیں

لانچ مرحلہ دو خرابیوں میں سے ایک کی اطلاع دیتا ہے، اور وہ مختلف مسائل کی طرف اشارہ کرتی ہیں۔ خرابی کی قدر پڑھنا کسی اور چیز کے چلانے سے پہلے ناکامی کی درجہ بندی کرتا ہے۔

ENOEXEC کا مطلب ہے کہ شکل پہچانی نہیں گئی: غلط ساخت، غلط کلاس یا ایسی چیز جو بالکل قابلِ عمل فائل نہ ہو۔ ELF فائل پر ENOENT عام طور پر مطلب ہے کہ انٹرپریٹر موجود نہیں، حالانکہ آپ کی مانگی ہوئی فائل موجود ہے۔ وہی ENOENT یہ بھی بتا سکتا ہے کہ اسکرپٹ کا انٹرپریٹر موجود نہیں، اسی لیے اسکرپٹ کی پہلی سطر اہم ہے۔ بہرحال پیغام طبقے کا نام لیتا ہے، اور ہر «نہیں ملا» کو گمشدہ ترتیب سمجھنا تحقیق کو غلط سمت بھیجتا ہے۔ ٹکٹ میں خرابی کی قدر نقل کریں، کیونکہ یہ اردگرد کے جملے سے بہتر دوبارہ بیان برداشت کرتی ہے۔

بائنری شروع نہ ہونے پر کیا نہ کریں

غیر واضح بائنری کو شیل کے غلاف سے زبردستی گزارنا اسے چلاتا نہیں۔ جس فائل پر بھروسہ نہ ہو اس پر انحصار جانچنے والا لاپرواہی سے نہ چلائیں، کیونکہ اسے چلانا بعض حالات میں بائنری سے کوڈ چلا سکتا ہے۔ لوڈر کے علامتی روابط شامل نہ کریں، میزبان کی لائبریریاں نہ بدلیں اور پیغام سے بچنے کے لیے تیسرے فریق کے آئینے سے پرانا محفوظہ نہ لائیں۔ ان میں سے ہر ایک تبدیلی کا دائرہ وسیع کرتا ہے بغیر اس عدم مطابقت کو چھوئے جس کا نام ہیڈر پہلے ہی لے چکا ہے۔

فروش سے رابطہ کرتے وقت کہانی نہیں قدریں بھیجیں: OS کا ورژن، پیکیج کی ساخت، کلاس اور مشین کی strings، مطلوبہ انٹرپریٹر اور خرابی کی پہلی سطر۔ وہ مجموعہ معاونتی سوالات کو ناکام انسٹالر کے اسکرین شاٹ سے زیادہ تیزی سے حل کرتا ہے۔ پرانے نمونے اور یاد رہنے والے فورم کے نتائج موجودہ معاونتی میٹرکس نہیں ہیں، اور مقامی بائنری لوڈ ہونے کے بعد پروفائل، تصدیق اور روٹنگ الگ کام رہتے ہیں۔

متعلقہ مضامین