VPS לא עולה אחרי עדכון kernel: מדריך שחזור

מה לעשות קודם כאשר VPS לא עולה לאחר עדכון kernel

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

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

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

כיצד ניתן לגשת למסוף (console) כאשר SSH אינו זמין?

פתחו את לוח הבקרה של ספק השרתים שלכם וחפשו אפשרות למסוף. השמות הנפוצים הם VNC console, web console, noVNC ו-serial console. העדיפו את ה-serial console אם קיימות שתי האפשרויות, כיוון שהוא מספק טקסט אמיתי שניתן לגלול ולהעתיק, בעוד ש-VNC הוא רק תמונה של המסך. אתרו את הפקד הזה כעת, בזמן שהמכונה תקינה, וודאו שהוא נפתח. חיפוש שלו בזמן תקלה גוזל מכם את השלווה הדרושה לכם. בדיקה זו צריכה להתבצע ב-עשר הדקות הראשונות ב-VPS חדש, לצד הגדרת חוקי ה-firewall ומפתחות ה-SSH.

רוב לוחות הבקרה מציעים גם מצב חילוץ (rescue mode) או תמונת שחזור (recovery image). מצב זה מאתחל מערכת קטנה מרשת הספק ומחבר את הדיסק שלכם כהתקן נוסף, כך ששום דבר מהדיסק שלכם אינו רץ. מצב חילוץ הוא מוצא אחרון כאשר ה-GRUB עצמו פגום, והוא גם הדרך להעתיק נתונים משרת שהחלטתם לא להציל.

בדרך כלל תזדקקו לביצוע hard reset מלוח הבקרה כדי להגיע לתפריט האתחול, כיוון שלא ניתן להריץ sudo reboot על מכונה שאינכם יכולים להתחבר אליה. ביצוע hard reset שקול לניתוק החשמל. מערכות הקבצים יחוו כיבוי לא תקין, לכן צפו לבדיקת תקינות מערכת קבצים (filesystem check) באתחול הבא.

כיצד בוחרים גרעין (kernel) ישן יותר בתפריט GRUB?

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

כאשר התפריט מופיע, בחרו ב-"Advanced options for Ubuntu". תפריט משנה זה מציג את כל הגרעינים המותקנים, מהחדש ביותר לישן, עם כניסה למצב recovery עבור כל אחד מהם. בחרו בכניסה הרגילה השנייה, שהיא הגרעין שמתחת לחדש ביותר, ולחצו על Enter. מצב recovery הוא עניין אחר: הוא מעלה מערכת מינימלית של משתמש יחיד, והוא מיועד לעבודות תיקון, לא להחזרת השירותים שלכם לפעולה.

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

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

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

תפריט ה-GRUB אינו מופיע. מה עושים?

תמונות ענן (Cloud images) מגיעות עם תצורה שמסתירה את התפריט. תמונות Ubuntu מגדירות בדרך כלל את זמן ההמתנה ל-0 בקובץ תחת /etc/default/grub.d/, כך שהקרנל החדש ביותר עולה מיד ולא ניתן ללחוץ על דבר.

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

תקנו את שני המקרים כשהמכונה תקינה. ערכו את /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

לאחר מכן החילו את השינויים וודאו שהעריכה נשמרה, כיוון שקבצים ב-/etc/default/grub.d/ נקראים לאחר /etc/default/grub ויכולים לדרוס את הגדרותיכם.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

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

באיזו מחלקת כשל מדובר?

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

GRUB אינו מוצא את הקבצים שלו. אתם מקבלים הנחיה מסוג grub rescue>, או שגיאה על מחיצה או קובץ שאינם קיימים, ואף הודעת ליבה אינה מופיעה. הליבה עדיין לא מעורבת בתהליך. מצב זה נובע משינוי בדיסק או במחיצה, או מכתיבת מנהל האתחול (bootloader) להתקן השגוי, ולא מעדכון חבילת ליבה כשלעצמו.

הליבה עולה אך אינה מצליחה לבצע mount למערכת הקבצים הראשית (root). הודעות הליבה רצות, ולאחר מכן אתם מגיעים ל-shell של busybox שההנחיה שלו היא (initramfs), או שהאתחול מסתיים ב-panic עקב חוסר יכולת לבצע mount ל-root. הליבה נטענה. ה-initramfs, שהיא מערכת קבצים זמנית קטנה שתפקידה לאתר ולבצע mount למערכת הקבצים האמיתית שלכם, לא מצאה את הדיסק. ב-Ubuntu, לפני ה-shell הזה תופיע בדרך כלל הודעה על ויתור המתנה להתקן ה-root, והיא תציין את ה-UUID המבוקש. העתיקו את ה-UUID הזה והשוו אותו מול הפלט של blkid בהמשך.

כרך לוגי (logical volume) אינו מופיע. זהו המקרה הקודם עם סיבה ספציפית אחת. בהנחיה (initramfs), הריצו את ls /dev/mapper. אם הערך היחיד שמופיע הוא control, סימן שאף כרך LVM (מנהל כרכים לוגיים) לא הופעל, ולכן התקן ה-root עדיין לא קיים. העלו את קבוצות הכרכים (volume groups) ידנית:

lvm vgchange -ay
ls /dev/mapper
exit

הפקודה exit מחזירה את השליטה לסקריפט ה-initramfs, שמנסה לבצע את ה-mount שוב. אם המערכת עולה לאחר מכן, ה-initramfs החדש חסר את רכיבי ה-LVM, והתיקון הוא לבנות מחדש את ה-image במקום לגעת בליבה.

שום דבר מ-Linux לא מופיע. הקונסולה מציגה טקסט של ה-firmware, מעטפת UEFI (ממשק קושחה מאוחד וניתן להרחבה), מסך ריק ללא פלט ליבה, או לולאת אתחול. הכשל מתרחש לפני ש-Linux רצה. בדקו באיזה מצב השרת שלכם משתמש בפועל לאחר שתחזרו למצב תקין, שכן מופעי VPS רבים עולים במצב legacy BIOS ולעולם אינם ניגשים לנתיב ה-EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

מצב שבו /boot/efi אינו מחובר (unmounted) במהלך השדרוג הוא סיבה נפוצה במכונות UEFI, כיוון שהחבילות שמנהלות את מחיצת ה-EFI כתבו לתוך תיקייה ריקה רגילה במקום למחיצה הנכונה. ה-firmware ממשיך להפעיל את רשומת האתחול הישנה עד שהיא מפסיקה להתאים למה שנמצא על הדיסק.

דפוס נוסף אינו מהווה כשל אתחול כלל. אם הגעתם ל-root shell שמציין שהמערכת במצב חירום (emergency mode), הליבה עלתה אך ה-userspace נעצר. זה בדרך כלל אומר שיש שורה שגויה ב-/etc/fstab או מערכת קבצים שנכשלה בבדיקה. הריצו את journalctl -xb בתוך ה-shell הזה וקראו את שם ה-unit שנכשל.

האם חבילת ה-kernel פגומה, או ה-initramfs?

שני המצבים נראים זהים מה-console, אך דורשים תיקונים שונים. בצעו boot ל-kernel הישן, ולאחר מכן השוו את הקבצים.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

עבור כל גרסה מותקנת, אתם זקוקים ל-vmlinuz- אחד ו-initrd.img- תואם, כאשר לכל אחד מהם גודל הגיוני. היעדר קובץ initrd, או קובץ שגודלו קטן משמעותית מהאחרים, מעיד על כשל ביצירת ה-initramfs. הסיבה הנפוצה לכך היא /boot מלא, והראיות לכך נמצאות בלוגים של החבילה:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

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

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

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

הפקודה ls האחרונה משמשת לבדיקה. קובץ בגודל תקין מעיד על כך שה-image קיים כעת. אם לעומת זאת ה-kernel image עצמו פגום, או ש-dpkg -l מציג את החבילה במצב שאינו ii, התקינו מחדש את החבילה:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

תיקון ממצב rescue כאשר שום kernel אינו עולה

אם כל הערכים בתפריט נכשלים, יש לבצע boot מתוך תמונת ה-rescue של ספק השרתים ולתקן את הדיסק מבחוץ. הדיסק שלכם יופיע כהתקן שאינו מחובר (unmounted), כך ששום תהליך עליו אינו רץ ושום דבר לא יחסום את הגישה שלכם.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

בדיקת ליבה (kernel) חדשה ללא סיכון האתחול הבא

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

הגדירו את GRUB_DEFAULT=saved בתוך /etc/default/grub, הריצו את sudo update-grub, ולאחר מכן הציגו את רשימת כותרות הרשומות כדי שתוכלו לציין אחת מהן במדויק:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

הפקודה grub-editenv list אמורה להדפיס את הכותרת שבחרתם בתור saved_entry. פלט זה מהווה הוכחה לכך שהמנגנון פועל, שכן שמירה דורשת /boot/grub/grubenv שניתן לכתיבה, ובמבנים מסוימים הוא אינו כזה ללא התרעה. רשומה 0 היא הראשונה בתפריט, והיא מייצגת את הליבה החדשה ביותר. שימוש בכותרות בטוח יותר משימוש במספרים במקרה זה, כיוון שהמספרים משתנים בכל פעם שמותקנת או מוסרת ליבה.

מדוע הפקודה autoremove מסוכנת בשרת ללא ממשק גרפי (headless)

APT שומרת רשימה של חבילות ליבה (kernel) שאסור לה להסיר באופן עצמאי. ניתן לעיין ברשימה שלך כאן:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

קובץ זה נוצר מחדש בכל פעם שחבילות הליבה משתנות, והוא מגן על הליבה הפעילה ועל הגרסאות העדכניות ביותר. המלכוד טמון בתזמון. אם תריץ את sudo apt autoremove --purge מיד לאחר אתחול לתוך ליבה חדשה, הרשימה המוגנת כבר תתעדכן, והליבה הישנה שעליה הסתמכת לא תהיה מוגנת עוד. במחשב עם מקלדת מחוברת מדובר באי-נוחות. בשרת ללא ממשק גרפי, זהו ההבדל בין בחירה פשוטה בתפריט האתחול לבין הצורך בביצוע mount לכונן מתוך image של מערכת הצלה.

שמור תמיד שתי גרסאות ליבה כמינימום, ושלוש אם ל-/boot יש מספיק מקום. הסר גרסאות ישנות לפי שם לאחר בדיקה ב-uname -r, כך שלעולם לא תמחק את הליבה שבה אתה משתמש כרגע:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

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

ביצוע Snapshot לפני השדרוג

Snapshot שנלקח לפני apt upgrade הוא נתיב השחזור היחיד שאינו דורש אתחול של שום רכיב. שחזור שלו מחזיר את הדיסק למצב שבו הקרנל הישן היה ברירת המחדל, ומאפשר לכם לנסות את השדרוג שוב כשהקונסולה כבר פתוחה. Snapshot של מכונה פעילה הוא crash consistent, כלומר הוא מתעד את הדיסק כאילו נותק החשמל; לכן, כבו את השרת לפני כן אם ספק התשתית שלכם תומך ב-Snapshot במצב לא מקוון (offline). Snapshot אינו מהווה גיבוי, כיוון שהוא בדרך כלל מאוחסן על אותה תשתית של הכרך (volume) שאותו הוא מעתיק. הבנת ההבדל בין Snapshot של VPS לבין גיבויים אמיתיים תקבע מה יציל אתכם כאשר הכשל רחב יותר מבעיית קרנל.

נושא זה קריטי במיוחד בעת שדרוג גרסה, שבו הקרנל, כלי ה-initramfs, מנהל האתחול (bootloader) ותצורת ה-GRUB משתנים כולם בריצה אחת. בצעו את ה-Snapshot מיד לפני תחילת שדרוג מ-Ubuntu 24.04 ל-26.04, ולא לילה לפני, כדי שנקודת השחזור תתאים בדיוק למצב המכונה שאתם עומדים לשנות.

כיצד unattended-upgrades מטפל בחבילות ליבה (kernel)

הכלי unattended-upgrades ב-Ubuntu מתקין עדכוני אבטחה ללא התערבות, וחבילות ליבה מגיעות דרך ה-security pocket כמו כל חבילה אחרת. לכך יש שתי השלכות.

ראשית, הליבה החדשה מותקנת אך אינה פעילה. ליבה נכנסת לתוקף רק לאחר אתחול (reboot). הקובץ /var/run/reboot-required יופיע, ו-/var/run/reboot-required.pkgs יציין מה גרם לדרישת האתחול, אך דבר לא יופעל מחדש אלא אם הפעלתם את Unattended-Upgrade::Automatic-Reboot בתוך /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

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

בצעו אתחול באופן יזום, ביום שבחרתם, כאשר חלון ה-console פתוח. הרגל יחיד זה הופך תקלה מסתורית לבחירה בתפריט של שתי דקות. אם אתם מעוניינים באוטומציה ללא הפתעות, השאירו את ההתקנות האוטומטיות פעילות ואת האתחולים האוטומטיים כבויים, וראו את המדריך להגדרת unattended-upgrades ב-Ubuntu עבור ההגדרות המדויקות. הקפאת חבילות ליבה באמצעות sudo apt-mark hold linux-image-generic תעצור אותן לחלוטין, אך היא תעצור גם תיקוני אבטחה קריטיים לליבה, לכן התייחסו לכך כאל פשרה מודעת ולא כאל אמצעי בטיחות.

FAQ

כיצד ניתן להעלות kernel ישן יותר בשרת VPS ללא גישה למקלדת?

פתחו את מסוף הניהול (VNC או serial) של ספק השרתים ובצעו hard reset דרך לוח הבקרה, שכן לא ניתן לבצע reboot מסודר ללא כניסה למערכת. עם עליית המכונה, לחצו על Esc שוב ושוב, או החזיקו את Shift במערכות BIOS ישנות, כדי לעצור את תפריט GRUB. בחרו ב-"Advanced options for Ubuntu" ובחרו בערך שמתחת ל-kernel העדכני ביותר. לאחר שתגיעו לשורת הפקודה, הריצו את uname -r כדי לוודא באיזה kernel אתם משתמשים, ואת dpkg -l 'linux-image-*' כדי לראות אילו גרסאות נוספות מותקנות. בצעו אבחון רק לאחר שהמערכת פועלת שוב.

מדוע ה-VPS שלי לא מציג את תפריט GRUB כלל?

תמונות ענן (cloud images) מגדירות לרוב את זמן ההמתנה של GRUB ל-0 בקובץ תחת /etc/default/grub.d/, כך שה-kernel החדש ביותר עולה ללא אפשרות לעצור את התהליך. הגדירו את GRUB_TIMEOUT=10 ו-GRUB_TIMEOUT_STYLE=menu בתוך /etc/default/grub, הוסיפו את GRUB_TERMINAL="console serial" כדי שהתפריט יוצג גם במסוף ה-serial, ולאחר מכן הריצו את sudo update-grub. ודאו את התקינות עם grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, כיוון שקבצים באותה תיקייה נקראים לאחר הקובץ הראשי ועלולים לדרוס את השינויים שלכם.

האם כדאי להסיר kernels ישנים כדי לפנות מקום ב-/boot?

הסירו את הישנים ביותר ושמרו לפחות שניים. מחיצה /boot מלאה היא כשל בפני עצמו, שכן יצירת ה-initramfs נכשלת ואתם נותרים עם kernel ללא image תקין. בצעו הסרה (purge) לפי שם חבילה מדויק לאחר בדיקת uname -r, כדי שה-kernel הפעיל לעולם לא יהיה מועמד למחיקה. הימנעו משימוש גורף ב-sudo apt autoremove --purge במכונה ללא מסך, כיוון שרשימת ה-kernels המוגנים נוצרת מחדש בכל שינוי, והרצה לא מתוזמנת עלולה להשאיר אתכם עם kernel אחד ללא אפשרות גיבוי בתפריט.

האם unattended-upgrades עלול לשבש את תהליך ה-boot?

השירות עלול להתקין kernel שלא יעלה בהצלחה, אך הוא אינו מבצע הפעלה מחדש של המכונה אלא אם Unattended-Upgrade::Automatic-Reboot מוגדר כ-true בתוך /etc/apt/apt.conf.d/50unattended-upgrades. התרחיש הנפוץ הוא כשל מושהה: ה-kernel מותקן במהלך הרצה אוטומטית, /var/run/reboot-required מופיע, והבעיה צפה רק ב-reboot הבא שלכם, שבועות לאחר מכן. בצעו reboot יזום כשהמסוף כבר פתוח, וקראו את /var/log/apt/history.log כדי לגלות איזו הרצה התקינה את ה-kernel שאתם מנסים להעלות.