שדרוג Ubuntu 24.04 ל-26.04 בשרת VPS: המדריך המלא

מתי ניתן לשדרג מ-Ubuntu 24.04 ל-26.04?

ניתן לשדרג מ-Ubuntu 24.04 ל-26.04 בשרת VPS ברגע שגרסת ה-point release‏ 26.04.1 תשוחרר, מה שמתוכנן ל-27 באוגוסט 2026. עד אז, שרת 24.04 לא יזהה את הגרסה החדשה, וזאת במכוון. הגרסה Ubuntu 26.04 LTS (Resolute Raccoon) שוחררה ב-23 באפריל 2026, אך Canonical פותחת את נתיב השדרוג מ-LTS ל-LTS רק בגרסת ה-point release הראשונה, כיוון שגרסה זו מאגדת בתוכה תיקוני באגים בהתקנה ובשדרוג שנמצאו בחודשים הראשונים.

הריצו את הבדיקה בשרת 24.04 בתחילת אוגוסט 2026 ותקבלו את התוצאה הבאה:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

אין זו תקלה בשרת שלכם. הקובץ /etc/update-manager/release-upgrades מכיל את Prompt=lts ב-Ubuntu Server, מה שאומר שהכלי מציע רק את גרסת ה-long term support הבאה, ורק לאחר שגרסת ה-.1 point release שלה קיימת. הגדרת Prompt=normal תוביל אתכם דרך 24.10, 25.04 ו-25.10 בזו אחר זו, גרסאות ביניים שכבר הגיעו לסוף חייהן (end of life). השאירו את ההגדרה על lts והמתינו. התאריכים בלוח הזמנים של Canonical עשויים להשתנות, לכן בדקו שוב אם היום עבר ללא שינוי.

כל פקודה להלן היא פקודה שעליכם להריץ בעצמכם, בשרת שלכם, לפי הסדר המצוין. לא ניתן לבצע "חזרה גנרלית" לשדרוג גרסה על המכונה שאותה אתם משדרגים. השדרוג מחליף את ה-kernel ואת ספריית ה-C, והוא דורש אתחול (reboot) כדי להסתיים.

האם כדאי לשדרג בכלל?

Ubuntu 24.04 מקבלת עדכוני אבטחה סטנדרטיים עד שנת 2029, לכן אין דחיפות לשדרג שרת עובד בסביבת ייצור. שדרגו רק אם אתם זקוקים למאפיינים שקיימים בגרסה 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 או ליבת 7.0. "המספר עלה" אינו סיבה לגעת במכונה שמשרתת לקוחות.

אל תבצעו שדרוג במקום (in-place) אם אחד מהתנאים הבאים מתקיים:

• מעולם לא פתחתם את מסוף הניהול (VNC או serial) של ספק השרתים שלכם ולא התחברתם דרכו. מסוף זה הוא הדרך היחידה לחזור למכונה אם SSH מפסיק לעבוד, וגילוי שהמסוף אינו תקין בזמן שאתם נעולים מחוץ לשרת הוא מאוחר מדי.
• אינכם יכולים להרשות לעצמכם שעה של השבתה ואין לכם תוכנית חזרה לאחור (rollback).
• מחסנית הטכנולוגיות שלכם תלויה במאגר צד-שלישי שטרם פרסם גרסה עבור resolute.
• השרת הוקם ידנית במהלך שנתיים ואיש אינו יודע מה מותקן עליו.

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

שלב 1: יצירת גיבוי שניתן לשחזר ממנו

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

בצעו Dump למסדי הנתונים ידנית תחילה. Dump הוא הגיבוי היחיד למסד נתונים שניתן לסמוך עליו מבלי לעצור את השירות.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction מספק Dump עקבי רק עבור טבלאות InnoDB. עבור טבלאות MyISAM יש לעצור את מסד הנתונים. ה-tarball של /etc הוא זה שתזדקקו לו בפועל, כיוון שהוא מכיל את כל קובצי התצורה שהשדרוג עשוי לשאול אתכם לגביהם.

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

שלב 2: עדכון מלא של 24.04 תחילה

do-release-upgrade מסרב לפעול על מערכת עם חבילות במצב שבור, וגרסת 24.04 שאינה מעודכנת במלואה מקשה על ניתוח תקלות עתידיות.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

אם dpkg --audit לא מדפיס דבר, סימן שאין חבילות במצב הגדרה חלקי. אם apt-mark showhold לא מדפיס דבר, סימן שאין חבילות שנעולות (pinned) לגרסה שעלולה לחסום את השדרוג. שחררו כל חבילה שמופיעה ברשימה באמצעות sudo apt-mark unhold ושם החבילה, או קבלו את העובדה שהנעילה קיימת מסיבה מוצדקת ועצרו כאן.

בצעו reboot אם הליבה (kernel) השתנתה, כדי שהשדרוג יתבצע ממכונה שמריצה את הקוד שהיא "חושבת" שהיא מריצה.

[ -f /var/run/reboot-required ] && sudo reboot

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

df -h / /boot

פחות מ-5 GB פנויים ב-/ הם נקודת כשל נפוצה. מחיצת /boot קטנה מ-300 MB תיכשל בהמשך, במהלך התקנת הליבה, עם השגיאה No space left on device. ליבות ישנות הן בדרך כלל הגורם לכך, ו-sudo apt --purge autoremove תנקה אותן.

דבר נוסף שיש לעצור לפני שמתחילים: אם עדכוני אבטחה אוטומטיים יופעלו באמצע התהליך, הם יחזיקו את ה-lock של dpkg, וכלי שדרוג הגרסה ייעצר עם Could not get lock /var/lib/dpkg/lock-frontend. הריצו את sudo systemctl stop unattended-upgrades תחילה והתחילו שוב כשתסיימו.

שלב 3: בדיקת מאגרים של צד שלישי וחבילות נעולות (pinned)

do-release-upgrade משבית כל מקור apt שאינו של Ubuntu, כיוון שחבילה שנבנתה עבור noble עלולה לשבור מערכת resolute. הכלי מפעיל מחדש את המקורות שהוא מזהה לאחר מכן, ומותיר את השאר כהערות. דעו מה מותקן אצלכם לפני שהכלי יחליט עבורכם.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 משתמשת בשני פורמטים בספרייה זו: קובצי .list הישנים בשורה אחת, וקובצי .sources בתקן deb822 עם שדות Types: ו-Suites:. השדרוג משבית את שניהם. ubuntu-security-status --thirdparty מציג את רשימת החבילות המותקנות שאינן מסופקות על ידי מאגרי Ubuntu, וזהו המדד המדויק לתוספות שהתקנתם. כל מה שנמצא ב-/etc/apt/preferences.d/ הוא הגדרת pin, ו-pin שנכתב עבור noble ימשיך לבחור בחבילה ישנה גם בגרסה החדשה.

עבור כל מאגר של צד שלישי, ודאו שהספק פרסם גרסה עבור שם הקוד החדש לפני שתתחילו. חבילות ה-suites של Docker מפורטות ב-https://download.docker.com/linux/ubuntu/dists/, וספקים אחרים חושפים ספרייה דומה. מקור המצביע על suite שאינו קיים יגרום לשגיאה הבאה ב-apt update הראשון לאחר השדרוג:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

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

שלב 4: הרצת השדרוג בתוך tmux, לא בתוך shell של SSH רגיל

אם החיבור שלכם מתנתק בזמן ש-do-release-upgrade רץ בתוך shell רגיל, התהליך מקבל אות SIGHUP וקורס באמצע תהליך הפריסה. מצב זה משאיר את dpkg במצב של הגדרה חלקית, ועלול להוביל לשרת שבו מחסנית הרשת אינה תקינה, מה שימנע מכם להתחבר אליו מחדש. הריצו את השדרוג בתוך terminal multiplexer, כך שהתהליך יישאר פעיל בשרת גם אם הלקוח שלכם מתנתק.

sudo apt install -y tmux
tmux new -s upgrade

בתוך הסשן הזה:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

המשדרג מפעיל daemon של SSH נוסף בפורט 1022 לפני שהוא משנה דבר מה, והוא מציין זאת:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

הוא אינו פותח את ה-firewall עבור פורט זה, כיוון שפתיחת חור ב-firewall ללא אישור היא פעולה לא רצויה. פתחו את פורט 1022 בעצמכם לפני שתתחילו, וסגרו אותו כשתסיימו בעזרת sudo ufw delete allow 1022/tcp. זכרו שספק השרתים שלכם עשוי להפעיל firewall נוסף בלוח הבקרה שלו, מחוץ לשרת עצמו.

אם החיבור מתנתק בכל זאת, התחברו מחדש והריצו את tmux attach -t upgrade. השדרוג המשיך לרוץ בזמן שלא הייתם מחוברים.

שלב 5: מענה מודע על הנחיות קובץ התצורה

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

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

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

לשמירה על הקובץ שלכם יש מחיר: לא תקבלו את הגדרות ברירת המחדל החדשות. בצעו התאמה לאחר מכן, כשהמערכת למעלה ואתם לא תחת לחץ זמן.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

כל קובץ שמוצג הוא הגרסה של מתחזק החבילה, שנשמרה לצד הקובץ שלכם. בצעו השוואת diff לכל אחד מהם בנפרד והעתיקו את ההגדרות הרלוונטיות. שני קבצים דורשים תשומת לב מיוחדת: /etc/ssh/sshd_config, כיוון שתשובה שגויה תנתק את ה-session שלכם, ותצורת שרת האינטרנט שלכם, כיוון שתשובה שגויה תפיל את האתרים.

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

שלב 6: ביצוע reboot ובדיקת המכונה

sudo reboot

לאחר שהמכונה עולה מחדש:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

הפקודה lsb_release -a אמורה לדווח על Release: 26.04 ועל Codename: resolute. הפקודה uname -r צריכה להציג גרסת kernel מסוג 7.0. הפקודה systemctl --failed אמורה להציג אפס יחידות (units), וכל יחידה שכן מופיעה ברשימה היא המשימה הבאה שלכם. הפקודה האחרונה, apt update, מושכת את העדכונים שפורסמו מאז יצירת תמונות ההפצה.

שדרוג מ-PostgreSQL 16 ל-18: ה-cluster שנשאר מאחור בשקט

הפצת Ubuntu 24.04 כוללת את PostgreSQL 16, בעוד ש-26.04 כוללת את PostgreSQL 18. תהליך השדרוג מתקין את גרסה 18 לצד גרסה 16 ואינו מעביר את הנתונים שלכם. שכבת ה-postgresql-common של Debian יוצרת cluster חדש וריק עבור הגרסה הראשית החדשה בפורט הפנוי הבא; כך, גרסה 16 ממשיכה להשתמש בפורט 5432 עם כל הנתונים שלכם, בעוד גרסה 18 נותרת ריקה בפורט 5433. היישום שלכם ממשיך לתקשר עם פורט 5432 ושום דבר לא נראה שגוי, וזו הסיבה שאנשים מגלים זאת רק חודשים לאחר מכן.

pg_lsclusters

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

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

מחקו תחילה את ה-cluster הריק של גרסה 18, כיוון ש-pg_upgradecluster לא יכתוב לתוך cluster יעד שכבר קיים. שיטת ברירת המחדל מבצעת dump לגרסה 16 וטוענת אותו מחדש לתוך גרסה 18, לכן עליכם לוודא שיש לכם שטח דיסק פנוי בערך בגודל בסיס הנתונים. הפקודה -m upgrade משתמשת ב-pg_upgrade במקום זאת, והיא מהירה בהרבה בבסיסי נתונים גדולים. בסיום התהליך, בדקו את עמודת ה-Port: ה-cluster החדש משתלט על פורט 5432 והישן נותר במצב עצור. בצעו את שלב ה-analyze בעצמכם, כיוון של-cluster שנטען זה עתה אין סטטיסטיקות והשאילתות הראשונות יהיו איטיות.

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

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

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

MySQL 8.0 ל-8.4: האופציה שהוסרה וגורמת לעצירת השרת

גרסה 26.04 מעבירה את MySQL מ-8.0 ל-8.4 LTS, ושני שינויים עלולים להכשיל שרתים.

ראשית, mysqld מסרב לעלות כאשר קובץ התצורה שלו מכיל אופציה שהוסרה בגרסה החדשה. default_authentication_plugin היא האופציה הנפוצה ביותר, כיוון שמדריכים ישנים רבים מורים להגדיר אותה. השירות נכשל, ו-journalctl -u mysql -n 50 מציין את שם המשתנה הלא מוכר באופן ישיר. מחקו את השורה הזו מהקובץ תחת /etc/mysql/mysql.conf.d/, ולאחר מכן בצעו sudo systemctl start mysql.

שנית, התוסף mysql_native_password אינו מופעל כברירת מחדל ב-8.4, ולכן חשבון שעדיין משתמש בו לא יוכל להתחבר כלל. בדקו זאת בעודכם בגרסה 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

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

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

אם ספריית לקוח ישנה מדי מכדי לתמוך ב-caching_sha2_password, ניתן להפעיל מחדש את התוסף הישן ב-8.4 על ידי הוספת mysql_native_password=ON תחת [mysqld]. התייחסו לכך כאל פתרון זמני בלבד, שכן התוסף צפוי לצאת משימוש לחלוטין.

מעבר מ-PHP 8.3 ל-8.5: ה-vhosts שלכם מצביעים על socket שכבר אינו קיים

גרסה 24.04 מגיעה עם PHP 8.3 וגרסה 26.04 מגיעה עם PHP 8.5. החבילות מותקנות בנתיבים מבוססי גרסה, ושום תהליך אינו מעדכן אוטומטית את הגדרות שרת האינטרנט שלכם. הגדרת vhost ב-nginx שמכילה את fastcgi_pass unix:/run/php/php8.3-fpm.sock; מצביעה כעת על socket שאף תהליך אינו יוצר, ולכן כל בקשת PHP מחזירה שגיאת 502, ויומן השגיאות של nginx מציג:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

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

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

ב-Apache עם mod_php הסימפטומים שונים: Apache לא יופעל כלל, ו-sudo apache2ctl -t ידווח כי אינו יכול לטעון את libphp8.3.so כיוון שהקובץ אינו קיים. המודול המופעל הוא קישור סימבולי (symlink) לחבילה שכבר אינה קיימת.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

אם הקמתם את השרת לפי מדריך LAMP stack על Ubuntu 24.04, כדאי לבדוק את שני הנתיבים הללו, שכן המדריך משאיר אתכם עם שם מודול מבוסס גרסה ו-socket מבוסס גרסה.

גם כוונוני ה-php.ini שלכם אינם עוברים אוטומטית. memory_limit, upload_max_filesize וכל הגדרה אחרת שביצעתם נמצאים ב-/etc/php/8.3/, והעץ החדש מתחיל מהגדרות ברירת המחדל. בצעו השוואת diff בין שני הקבצים והעתיקו את הערכים ידנית. העתקת הקובץ הישן במלואו על החדש תגרום לשימוש בערכי ברירת מחדל של 8.3 בהתקנת 8.5. לאחר מכן הריצו את php -m ובצעו השוואה: תוסף שהותקן כ-php8.3-redis דורש את חבילת ה-php8.5- שלו, ואם הוא הגיע מ-PPA, תהליך השדרוג השבית את המקור הזה והתוסף פשוט חסר.

תעודות אבטחה דורשות בדיקה נפרדת. הריצו את sudo certbot renew --dry-run לאחר השדרוג. פקודה זו מריצה את כל תהליך החידוש, כולל ה-hook לטעינה מחדש של שרת האינטרנט, מבלי לגעת בתעודה הפעילה. hook שקורא לשם שירות או לקובץ בינארי שהשתנה ייכשל כאן, מול עיניכם, במקום להיכשל בשקט בעוד 60 יום. המדריך Certbot עם Let's Encrypt על nginx מפרט כיצד hooks אלו צריכים להיראות.

SSH: הכשל שסוגר את הסשן שבו אתם עובדים

ההנחיה sshd_config היא המקום שבו משתמשים נועלים את עצמם מחוץ לשרת. מענה ב־Y מתקין את הקובץ של מתחזק החבילה, מה שמוחק את PermitRootLogin, PasswordAuthentication, AllowUsers, Port וכל שורה אחרת שהוספתם. אם ה-firewall שלכם מאפשר רק פורט מותאם אישית והתצורה המגיעה עם החבילה מאזינה ב-22, החיבור הבא יידחה, והסשן שבו אתם יושבים כרגע יהיה האחרון שעומד לרשותכם.

מנעו זאת לפני השדרוג. /etc/ssh/sshd_config בגרסה 24.04 מתחיל ב-Include /etc/ssh/sshd_config.d/*.conf, ו-OpenSSH שומר את הערך הראשון שהוא קורא עבור כל הגדרה; לכן, קובץ drop-in שמופיע בראש הרשימה גובר על כל מה שמתחתיו. העבירו את ההגדרות שלכם לקובץ ש-dpkg אינו הבעלים שלו:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

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

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

systemctl is-enabled ssh.socket

אם הפקודה מדפיסה enabled, אזי systemd הוא זה שמנהל את פורט ההאזנה והשורה Port בתוך sshd_config מתעלמת מההגדרה. אובונטו משתמשת ב-socket activation עבור sshd מאז גרסה 22.10, וזו הסיבה שעריכה של Port 2222 נראית כאילו אינה משפיעה. הגדירו זאת ביחידת ה-socket במקום, באמצעות sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

הערך הריק ListenStream= הוא הכרחי. הוא מנקה את הערך שעבר בירושה, ובלי זה ה-socket יאזין גם ב-22 וגם ב-2222. החילו את השינוי בעזרת sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

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

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

לאחר מכן, פתחו טרמינל שני במחשב שלכם והתחברו שוב. shell תקין בטרמינל השני הוא ההוכחה היחידה שקובעת. השאירו את הסשן הראשון פתוח עד שתצליחו להתחבר בשני. המדריך אבטחת SSH ב-VPS עובר על ההגדרות שכדאי לשמור בתוך קובץ ה-drop-in.

אם כבר מאוחר מדי, מסוף הניהול (web console) של ספק השרתים שלכם מספק גישה שאינה עוברת דרך SSH כלל. התחברו דרכו, תקנו את התצורה, הריצו את sudo sshd -t, ובצעו restart לשירות. המסוף הזה הוא בדיוק הסיבה לכך שבודקים גישת קונסולה לפני שדרוג ולא במהלכו.

FAQ

מדוע הפקודה do-release-upgrade מציגה "No new release found" בגרסת Ubuntu 24.04?

מכיוון ש־/etc/update-manager/release-upgrades מכיל את Prompt=lts בגרסת Ubuntu Server, והגדרה זו מציעה את גרסת ה-LTS הבאה רק לאחר שחרור ה-point release הראשון שלה. גרסת Ubuntu 26.04 LTS שוחררה ב-23 באפריל 2026, והגרסה 26.04.1 מתוכננת ל-27 באוגוסט 2026. עד לאותו יום, שרת 24.04 לא יזהה עדכון זמין. מוטב להשאיר את ההגדרה כפי שהיא במקום לעבור ל-Prompt=normal, שכן מעבר כזה ינתב אתכם דרך גרסאות הביניים.

האם עלי לבצע אתחול (reboot) לשרת כדי לסיים את השדרוג?

כן. השדרוג מתקין kernel חדש, ספריית C חדשה ומערכת init חדשה, והמערכת הפעילה תמשיך להשתמש בישנים עד להפעלה מחדש. do-release-upgrade מבקש לבצע אתחול בסיום, ומכונה שנותרה דולקת עד "מאוחר יותר" היא מכונה שמריצה תערובת של שתי גרסאות. לאחר שהשרת יעלה, בדקו את uname -r עבור ה-kernel החדש ואת systemctl --failed עבור שירותים שלא שרדו את התהליך.

האם כדאי לשדרג במקום (in-place) או להקים שרת 26.04 חדש?

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

מה קורה אם חיבור ה-SSH מתנתק במהלך השדרוג?

ב-login shell רגיל, התהליך מקבל SIGHUP ונהרג באמצע הדרך, מה שמותיר את dpkg במצב של הגדרה חלקית. התחילו את התהליך בתוך tmux או screen והתהליך ישרוד את הניתוק; כך תוכלו להתחבר מחדש ולהריץ את tmux attach -t upgrade כדי להמשיך מהנקודה שבה עצר. המשדרג מפעיל גם daemon SSH נוסף בפורט 1022 כדרך גישה חלופית, אך הוא אינו פותח את ה-firewall עבור פורט זה, לכן פתחו את הפורט בעצמכם מראש וסגרו אותו לאחר מכן.

אתר ה-PHP שלי מחזיר שגיאת 502 לאחר השדרוג. מה השתבש?

נתיב ה-socket של PHP FPM השתנה עם הגרסה. Ubuntu 24.04 מריצה PHP 8.3 ו-26.04 מריצה PHP 8.5, לכן /run/php/php8.3-fpm.sock כבר אינו קיים בעוד ה-vhost של nginx עדיין מפנה אליו. לוג השגיאות של nginx יציג connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). עדכנו את fastcgi_pass ל-socket של גרסה 8.5, הריצו את sudo nginx -t, ולאחר מכן בצעו reload ל-nginx. ב-Apache עם mod_php, התיקון המקביל הוא sudo a2dismod php8.3 ולאחריו sudo a2enmod php8.5 וביצוע restart.