איך לשדרג 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 הראשונה. הסיבה לכך היא שגרסה זו מאגדת בתוכה את כל תיקוני ההתקנה והשדרוג שנמצאו בחודשים הראשונים. אם שיטת המספור חדשה עבורך, 26.04.1 אינה הפצה שונה של Ubuntu אלא אותה 26.04 עם ארבעה חודשי תיקונים משולבים במדיה, וזו בדיוק הסיבה שהיא הגרסה הראשונה ש-Canonical תציע לשרת קיים.

הריצו את הבדיקה בשרת 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) אם אחד מהתנאים הבאים מתקיים:

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

החלופה לרוב עדיפה: הקימו VPS חדש עם 26.04, התקינו את ה-stack שלכם ושחזרו את הנתונים, ולאחר מכן בצעו החלפת 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 יגרום לכשל מאוחר יותר, במהלך התקנת ה-kernel, עם השגיאה No space left on device. גרסאות kernel ישנות הן בדרך כלל הסיבה לכך, ו-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, ופורמט deb822 של קובצי .sources עם שדות Types: ו-Suites:. השדרוג משבית את שניהם. ubuntu-security-status --thirdparty מציג את החבילות המותקנות שאינן מסופקות על ידי אף מאגר של Ubuntu; זהו המדד האמיתי לתוספות שהתקנתם. כל מה שנמצא ב-/etc/apt/preferences.d/ הוא קיבוע (pin), וקיבוע שנכתב עבור noble ימשיך לבחור בחבילה ישנה בגרסה החדשה.

עבור כל מאגר של צד שלישי, ודאו שהספק פרסם גרסה עבור שם הקוד החדש לפני שתתחילו. סוויטות (suites) של Docker מפורטות ב-https://download.docker.com/linux/ubuntu/dists/, וספקים אחרים חושפים ספרייה דומה. מקור המצביע על סוויטה שאינה קיימת יפיק את השגיאה הבאה ב-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. השדרוג המשיך לפעול בזמן שלא הייתם מחוברים. אם הוא לא המשיך, ובחזרתכם אתם מוצאים dpkg שהוגדר באופן חלקי או מקורות apt שחלקם הם noble וחלקם הם resolute, שחזור לאחר שדרוג גרסה שנכשל מסביר כיצד לתקן את מצב החבילות ומתי להפסיק לנסות לתקן ולעבור לשחזור ה־snapshot במקום.

שלב 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, כיוון שתשובה שגויה תסיים את הסשן שלכם, ותצורת שרת האינטרנט שלכם, כיוון שתשובה שגויה תוריד את האתרים מהאוויר.

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

שלב 6: אתחול ובדיקת המכונה

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 להציג ליבת 7.0. על systemctl --failed להציג רשימה ריקה של יחידות, וכל מה שיופיע בה הוא המשימה הבאה שלכם. הפקודה האחרונה, 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 על 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, ואתחלו את השירות. אותו מסוף הוא בדיוק הסיבה לכך שבודקים גישת קונסולה לפני שדרוג ולא במהלכו.

FAQ

Why does do-release-upgrade say "No new release found" on Ubuntu 24.04?

Because /etc/update-manager/release-upgrades contains Prompt=lts on Ubuntu Server, and that setting offers the next long term support release only after its first point release exists. Ubuntu 26.04 LTS shipped on 23 April 2026, and 26.04.1 is scheduled for 27 August 2026. Until that day, a 24.04 server sees nothing. Leave the setting alone rather than switching to Prompt=normal, which would route you through the interim releases instead.

Do I have to reboot the server to finish the upgrade?

Yes. The upgrade installs a new kernel, a new C library and a new init system, and the running system keeps using the old ones until it restarts. do-release-upgrade asks to reboot at the end, and a machine left running until "later" is a machine running a mix of two releases. After it comes back, check uname -r for the new kernel and systemctl --failed for services that did not survive.

Should I upgrade in place or build a fresh 26.04 server?

Build fresh when you can. A new VPS lets you install the stack, restore the data, and test everything while the old server still serves traffic, so rollback is a DNS change rather than a restore from backup. Upgrade in place when the server holds state that is painful to move, when the provider bills per machine, or when you have a snapshot and proven console access. The in-place path is well trodden, but it is a one-way door for the hour it runs.

What happens if my SSH connection drops during the upgrade?

In a plain login shell the process receives SIGHUP and dies partway through, which leaves dpkg half configured. Start it inside tmux or screen and the process survives, so you reconnect and run tmux attach -t upgrade to pick it up. The upgrader also starts a spare SSH daemon on port 1022 as a second way in, but it does not open the firewall for that port, so allow 1022 yourself first and close it afterwards.

My PHP site returns 502 after upgrading. What broke?

The PHP FPM socket path changed with the version. Ubuntu 24.04 runs PHP 8.3 and 26.04 runs PHP 8.5, so /run/php/php8.3-fpm.sock no longer exists while your nginx vhost still names it. The nginx error log shows connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Update fastcgi_pass to the 8.5 socket, run sudo nginx -t, then reload nginx. On Apache with mod_php the equivalent fix is sudo a2dismod php8.3 followed by sudo a2enmod php8.5 and a restart.