פתרון בעיות בהפעלה של מכונות Linux ב-Compute Engine

במאמר הזה מוסבר למה מופע Linux Compute Engine לא מצליח לבצע אתחול, ואיך לפתור בעיות נפוצות.

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

  • מכונת החישוב במצב RUNNING, אבל אי אפשר להתחבר אליה באמצעות SSH.
  • הפלט של הקונסולה הטורית מפסיק באמצע רצף האתחול, או מסתיים בהנחיה לחירום או לחילוץ.
  • הפלט של הקונסולה הטורית מכיל את הערכים FAILED, error:, Kernel panic או emergency mode.

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

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

לפני שמתחילים

  • מוודאים שמופע המחשוב כותב פלט של קונסולה טורית. פלט של יציאה טורית זמין בזמן שהמכונה לחישובים פועלת. כדי לשמור אותו אחרי שהמכונה לחישובים מפסיקה לפעול, צריך להפעיל את רישום היומנים של היציאה הטורית ב-Cloud Logging. למידע נוסף, קראו את המאמר הצגת הפלט של היציאה הטורית.
  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

    1. התקינו את ה-CLI של Google Cloud. אחר כך, מאתחלים את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    2. הגדרת אזור ותחום כברירת מחדל.

זיהוי אוטומטי של הסיבה

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

המסוף

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. בשורה של המכונה הווירטואלית, לוחצים על SSH.

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

gcloud

כדי לבדוק מכונת Compute שלא ניתן להתחבר אליה באמצעות SSH, מריצים את הכלי לפתרון בעיות ב-SSH של ה-CLI של gcloud, שמריץ בדיקות קישוריות ובדיקת אתחול:

gcloud compute ssh INSTANCE_NAME --zone=ZONE --troubleshoot

כדי לבדוק את רצף האתחול ישירות, מריצים את פקודת האבחון של האתחול:

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

gcloud alpha compute diagnose boot INSTANCE_NAME --zone=ZONE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫INSTANCE_NAME: השם של המכונה הווירטואלית.
  • ‫ZONE: האזור שמכיל את מכונת ה-Compute.

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

קריאת הפלט של הקונסולה הטורית

אם הכלים לא מזהים בעיה, או אם רוצים לוודא מה הסיבה, אפשר לקרוא את הפלט של מסוף הטורים בעצמכם:

המסוף

  1. נכנסים לדף VM instances במסוף Google Cloud .

    לדף VM instances

  2. בוחרים את המכונה שרוצים לראות את הפלט של היציאה הטורית שלה.

  3. בקטע Logs, לוחצים על יציאה טורית 1 (console)‎.

gcloud 

gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫INSTANCE_NAME: השם של המכונה הווירטואלית.
  • ‫ZONE: האזור שמכיל את מכונת ה-Compute.

עוברים לאתחול האחרון. השורות השימושיות מופיעות בדרך כלל מיד לפני השורה הראשונה [FAILED], השורה Kernel panic או ההודעה על מצב חירום. משווים את מה שמוצאים לחתימות בקטעים הבאים.

בעיות נפוצות בהפעלה

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

אי אפשר לטעון את רשומת הקובץ /etc/fstab

התופעה: הפלט של הקונסולה הטורית מכיל שורות כמו אלה, ואחריהן You are in emergency mode:

UUID=1234abcd-... does not exist
Timed out waiting for device /dev/sdb1
mount: special device /dev/sdb1 does not exist
[DEPEND] Dependency failed for /mnt/data.mount

הסיבה: רשומה ב-/etc/fstab מפנה למכשיר או ל-UUID שלא מחובר למכונה הווירטואלית, או שלא ניתן לטעון את מערכת הקבצים. השירות systemd מפסיק את האתחול ועובר למצב חירום.

פתרון: במכונת ה-VM לשחזור, מתקנים את הרשומה ב-/etc/fstab בדיסק המצורף או מסירים אותה. כדי לפתור את הבעיה, קראו את המאמר פתרון בעיות באתחול של מכונות וירטואליות של Linux שנגרמות בגלל שגיאות fstab. כדי לראות את אפשרות הטעינה שמונעת ממכשיר חסר לחסום את ההפעלה, קראו את המאמר טעינת הדיסק.

‫GRUB לא יכול לטעון את ההגדרות שלו או את הליבה (kernel)

תסמין: תהליך האתחול נעצר בהודעת GRUB, והפלט של הקונסולה הטורית מכיל שורות כמו הבאות:

error: file '/boot/grub/grub.cfg' not found
error: file '/vmlinuz-6.1.0-18-amd64' not found
error: no such partition
error: no such device
error: unknown filesystem
error: you need to load the kernel first
grub rescue>
Minimal BASH-like line editing is supported

הסיבה: טוען האתחול GRUB לא יכול למצוא את קובץ ההגדרות שלו, את המודולים שלו או את ליבת ה-RAM הדינמי הראשונית שאליה מתייחסות ההגדרות. הבעיה הזו מתרחשת אחרי שדרוג חבילה שנכשל, שינוי בפריסת המחיצות, מחיצה /boot שעברה פורמט או פגומה, או דיסק משובט שמזהי ה-UUID של מערכת הקבצים שלו השתנו.

פתרון: ב-VM החילוץ, טוענים את דיסק האתחול ונכנסים לסביבת chroot כמו שמתואר במאמר חילוץ VM, ואז יוצרים מחדש את קובץ התצורה של GRUB כמו שמתואר במאמר הגדרת מנהל האתחול. אם אי אפשר לתקן את טוען האתחול, צריך לשחזר את הדיסק מקובץ snapshot.

אי אפשר לטעון את מערכת הקבצים הבסיסית לדיסק ה-RAM הראשוני

התופעה: הפלט של הקונסולה הטורית מכיל שורות כמו אלה:

dracut-initqueue[452]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut: FATAL: ...
Failed to mount /sysroot
ALERT! UUID=1234abcd-... does not exist. Dropping to a shell!
Gave up waiting for root file system device
VFS: Unable to mount root fs on unknown-block(0,0)

הסיבה: דיסק ה-RAM הראשוני (initramfs) הופעל, אבל הוא לא הצליח למצוא את מערכת קבצי הבסיס או לטעון אותה. הסיבות הנפוצות הן פרמטר ליבה (kernel) של root= או UUID שכבר לא תואם לדיסק, קובץ אימג' של initramfs שחסר בו מנהל ההתקן של הדיסק או קובץ אימג' פגום של initramfs. בסדרות של מכונות שמשתמשות בממשק הדיסק NVMe, הגדרת אתחול שבה הדיסק נקרא לפי נתיב המכשיר, כמו /dev/sda, כבר לא תואמת. במקום זאת, צריך להשתמש ב-UUID.

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

פגם במערכת הקבצים

תיאור הבעיה: הפלט של קונסולה טורית מכיל שורות כמו אלה:

Bad magic number in super-block
EXT4-fs error (device sda1): ...
XFS (sda1): Metadata corruption detected
XFS (sda1): log mount/recovery failed
BTRFS error (device sda1): ...
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

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

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

פאניקה בליבה

התופעה: הפלט של הקונסולה הטורית מכיל את ההודעה Kernel panic - not syncing: ואחריה הסיבה, למשל Attempted to kill init!,‏ Fatal exception,‏ hung_task: blocked tasks,‏ Out of memory,‏ Fatal Machine check או NMI: Not continuing. קובץ אימג' פגום של הליבה מפסיק מוקדם יותר עם -- System halted.

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

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

מדיניות SELinux לא נטענת

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

Failed to load SELinux policy
Unable to load SELinux policy

יכול להיות שיוצג גם Warning -- SELinux targeted policy relabel is required, שזו לא שגיאה: מופעלת מחדש המכונה לחישוב, אחרי שהיא משנה את התווית של מערכת הקבצים.

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

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

המערכת לא יכולה להתחיל את התהליך init

תיאור הבעיה: הפלט של קונסולה טורית מכיל שורות כמו אלה:

Failed to switch root
Target filesystem doesn't have requested /sbin/init
No working init found
run-init: /sbin/init: No such file or directory
/sbin/init: error while loading shared libraries: ...

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

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

מצב חירום וחשבון הבסיס הנעול

תיאור הבעיה: הפלט של הקונסולה הטורית מסתיים באחת מהאפשרויות הבאות:

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Give root password for maintenance (or press Control-D to continue):
Cannot open access to console, the root account is locked.

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

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

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

הקושחה לא מוצאת דיסק שאפשר לאתחל ממנו

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

No bootable device.
BdsDxe: failed to load Boot0001
Invalid partition table!
Verification failed: (0x1A) Security Violation

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

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

תיקון הדיסק במצב אופליין

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

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

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

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

המאמרים הבאים