האם קובץ ה-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

הפקודה הראשונה מציגה את נתיב המפרש שהקובץ הבינארי מבקש. השנייה בודקת אם הנתיב הזה קיים, מה שמפריד בין בנייה שגויה לבין טוען חסר.

אל תריץ מציג תלויות על קובץ בינארי לא מהימן, כי כמה מימושים יכולים להריץ את הקובץ שהם בודקים. שמור את הבדיקה לקריאה בלבד והתנגד להוספת קישורים סימבוליים של טוען כדי להפעיל בנייה לא נתמכת.

בקש בנייה כשהעובדות ביד

שלח לספק את גרסת מערכת ההפעלה, ארכיטקטורת החבילות, ערכי המחלקה והמכונה והודעת השגיאה הראשונה. השילוב הזה מזכה בתשובה מועילה, בעוד צילום מסך של כישלון כללי מזכה בתבנית תמיכה.

שמור את שאלת הקובץ הבינארי בנפרד משאלת התצורה. ברגע שהבנייה הנכונה עולה, פרופילים, אישורים ומסלולים הם עדיין בעיות משלהם, וכל עריכת פרופיל לא תגרום לקובץ בינארי בארכיטקטורה שגויה לרוץ.