פתרון בעיות בהפעלה של מכונות וירטואליות של Linux בגלל תגובה לשגיאת ליבה קריטית

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

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

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

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud

    gcloud

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

      gcloud init

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

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

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

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

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

תגובה לשגיאת ליבה קריטית

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

סוג אחר של פאניקה בקרנל יכול להתרחש במצב שבו הקרנל לא יודע איך לטפל בבקשה מסוימת, והוא מגן על עצמו על ידי עצירה. יכול להיות שתתרחש תגובה לשגיאת ליבה קריטית במכונה וירטואלית של Compute Engine שמריצה RedHat,‏ SUSE,‏ CentOS או Ubuntu.

הודעות שגיאה נפוצות

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

Kernel panic - not syncing: hung_task: blocked tasks
 
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Kernel panic - not syncing: NMI: Not continuing
 
Kernel panic - not syncing: out of memory. panic_on_oom is selected
 
Kernel panic - not syncing: Fatal Machine check

גורמים נפוצים

יכולות להיות כמה סיבות לשגיאת Kernel Panic. אלה כמה מהסיבות הנפוצות:

  • הרשומה שקשורה לקובץ initramfs שמתאים לליבה לא קיימת בקובץ grub.cfg.
  • קובץ initramfs לא נוצר בספרייה /boot במהלך התקנת ליבת המערכת.
  • קובץ ה-initramfs נוצר באופן חלקי בלבד או שהוא פגום.

תסמינים

כשחווים פאניקה בקרנל במכונת VM, סימפטום נפוץ הוא שהקרנל לא מאפשר להתחבר ל-VM, גם כשמשתמשים במסוף הטורי.

כדאי לבדוק את היומנים של המסוף הטורי כדי לזהות את ליבת המערכת (kernel) שנטענה על ידי מערכת ההפעלה של האורח. לדוגמה: 

[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-1160.95.1.el7.x86_64 (mockbuild@x86-vm-42.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Thu Aug 10 10:46:21 EDT 2023
כדאי גם לבדוק את השגיאה 'panic' בקרנל. השגיאה הזו מופיעה בדרך כלל בשורת הליבה כשהמכונה הווירטואלית מופעלת, או בסוף היומנים של מסוף הטורים עם כמה עקבות של קריאות למחסנית.

בדוגמה הבאה מוצג אירוע של תגובה לשגיאת ליבה קריטית בגלל בעיות ב-initramfs:

[    1.520840] No filesystem could mount root, tried:
[    1.520840]
[    1.521964] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.523495] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.0-1160.95.1.el7.x86_64 #1
[    1.524932] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
[    1.526901] Call Trace:
[    1.527421]  dump_stack+0x41/0x60
[    1.527978]  panic+0xe7/0x2ac
[    1.528578]  mount_block_root+0x2be/0x2e6
[    1.529693]  ? do_early_param+0x95/0x95
[    1.530441]  prepare_namespace+0x135/0x16b
[    1.531237]  kernel_init_freeable+0x203/0x22d
[    1.532081]  ? rest_init+0xaa/0xaa
[    1.532808]  kernel_init+0xa/0x103
[    1.533395]  ret_from_fork+0x35/0x40
[    1.535229] Kernel Offset: 0x23a00000 from 0xffffffff81000000

פתרון השגיאה 'תגובה לשגיאת ליבה קריטית'

כדי לפתור את שגיאת Kernel Panic, מבצעים את השלבים הבאים:

  1. מתחברים למסוף הטורי ונכנסים ל-VM ממסוף Google Cloud .

  2. לוחצים על איפוס עבור מכונה וירטואלית במסוף Google Cloud .

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

    תגובה לשגיאת ליבה קריטית

  4. כשהמכונה הווירטואלית נגישה, אפשר ליזום חיבור SSH למכונה הווירטואלית.

  5. מזהים את הגורם לבעיה ופועלים בהתאם.

    לדוגמה, אם הקובץ initramfs חסר או פגום, מבצעים את השלבים הבאים:

    1. יוצרים את הקובץ initramfs שמתאים לליבה המקורית באמצעות הפקודה dracut:

      dracut -f /boot/initramfs-KERNEL_VERSION.img KERNEL_VERSION

      מחליפים את KERNEL_VERSION בגרסת הליבה הנוכחית של המכונה הווירטואלית. לדוגמה, 3.10.0-1160.95.1.el7.x86_64.

    2. מעדכנים את הקובץ grub2.cfg באמצעות הפקודה grub2-mkconfig, לדוגמה:

      grub2-mkconfig -o /boot/grub2/grub.cfg

    3. אחרי שקובץ initramfs נוצר, אפשר להפעיל מחדש את ה-VM בלי שגיאות.