יום שלישי, פברואר 13, 2024

מצילים מערכת ע"י chroot במחשב מארח ? תוודאו שאם יש שימוש ב luks שהשם של מחיצת השורש יתאים למה שהיה קודם אחרת initramfs יתקע !

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

לאחר התקנת קרנל ובדיקה שהכל עובד ב chroot, לקחתי את הכונן למחשב  המקורי, ושם גיליתי שהמערכת נופלת ל shell ולא עולה, grub היה רואה את הכונן ומחיצת ה boot אבל כשה initramfs עלה הוא לא ביקש את סיסמת ה luks והגיע ל shell ההצלה (לאחר שחיכה די הרבה זמן).

לקח לי קצת זמן להזכר, אבל כאשר אנחנו מתקינים קרנל יש הפעלה של update-initramfs והיא עוברת על /dev.
עכשיו, עם פתחנו את הכונן עם luks על המחשב המארח ולא השתמשנו באותו השם שקיים כבר תחת /etc/crypttab מה שהולך להיות הוא שה update-initramfs ייכשל במהלך הבנייה אבל לא יכשיל את ההתקנה, התקנת הקרנל תצליח ותסיים את ההתקנה. במהלך ביצוע chroot אנחנו מעבירים את ה /dev של המחשב המארח לתוך ה chroot, והמערכת לוקחת את שמות ההתקנים מהמחשב המארח, וזה יכול להיות בעל שוני די גדול.

הפתרון די פשוט, צריך לוודא שהשם שיש תחת /etc/crypttab יהיה אותו השם איתו אנחנו פותחים בעלייה.
נפתח את הכונן בצורה רגילה נקרא את התוכן מהכונן המקורי ושם זה :
  cat /etc/crypttab 
   nvme0n1p1_crypt UUID=65c6f25f-40bb-300c-86a2-b0402340172d none luks,discard
  
השם פה הוא nvme0n1p1_crypt לכן אנחנו צריכים לסגור על ידי luksClose ואחרי זה לפתוח את הכונן המוצפן עם השם הזה הנכון.

עכשיו אם אנחנו משתמשים במתאם nvme ל usb, אנחנו נראה את ההתקנים כ /dev/sdx ולא כ /dev/nvme* , שזה המקור לבעייה בתיקון אצלי.

נניח והמחיצה מזוהה בממחשב המארח כ /dev/sdc8 אז צריך להתאים את השם בפקודה cryptsetup
sudo cryptsetup luksOpen /dev/sdc8 nvme0n1p1_crypt
עכשיו ה update-initramfs יוכל לזהות נכון את המקום במהלך ההתקנה , מפה או שמתקינים את הקרנל מחדש או שבונים ע" update-initramfs -c -k all וזה פותר את הבעייה.

אין תגובות: