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

מה לעשות תחילה כאשר VPS אינו עולה לאחר עדכון kernel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמונות ענן (Cloud images) מגיעות עם הגדרה שמסתירה את התפריט. תמונות של Ubuntu מגדירות בדרך כלל את ה-timeout ל-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" שולח את התפריט לקונסולה הגרפית וליציאה הטורית (serial port), כך שהוא יופיע בכל צופה שהפאנל שלכם מספק. ארגומנטי הקרנל console= עושים את אותו הדבר עבור הודעות האתחול שבאות לאחר מכן. עשר שניות של המתנה בכל אתחול הן מחיר זול עבור תפריט שבאמת ניתן להגיע אליו ב-2 לפנות בוקר.

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

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

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

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

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

lvm vgchange -ay
ls /dev/mapper
exit

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

שום דבר מ-Linux לא מופיע. הקונסולה מציגה טקסט של ה-firmware, מעטפת UEFI (ממשק קושחה מאוחד וניתן להרחבה), מסך ריק ללא פלט kernel, או לולאת אתחול. הכשל מתרחש לפני ש-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), ה-kernel עלה אך ה-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, ולא לילה לפני, כדי שנקודת השחזור תתאים בדיוק למכונה שאתם עומדים לשנות. אם השדרוג טרם הוצע בשרת שלכם, הסיבה היא תזמון ולא הגדרה שגויה, שכן המעבר בין גרסאות LTS נפתח רק ב-נקודת השחרור הראשונה, 26.04.1.

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

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

ראשית, הליבה החדשה מותקנת אך אינה פעילה. ליבה נכנסת לתוקף רק לאחר אתחול. הקובץ /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

כיצד ניתן לאתחל קרנל ישן בשרת VPS ללא מקלדת?

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

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

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

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

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

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

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