שם ההפצה, glibc או מהדר: מה המתקין בודק

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

התסמין: המתקין נעצר בגזירה שלכם

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

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

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

שלוש גרסאות שאנשים קוראים להן גרסת המערכת

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

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

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

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

קראו את השגיאה, לא את הבדיקה

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

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

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

מדוע עריכת המחרוזת אינה עוזרת

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

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

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

כתבו דוח שהמתחזק יכול לפעול לפיו

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

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

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