שדרוג 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 בזו אחר זו, גרסאות ביניים שכבר הגיעו לסוף חייהן. השאירו את ההגדרה על lts והמתינו. התאריכים בלוח הזמנים של Canonical עשויים להשתנות, לכן בדקו שוב אם היום עבר בשקט. בסופו של דבר, 26.04.1 שוחררה ב-27 באוגוסט, אך כלי השדרוג לא הציע אותה לשרתי 24.04 עד ה-29 בספטמבר, לכן קראו את מה השתנה ב-26.04.1 ומתי נפתח נתיב השדרוג לפני שתתחילו. שרת שעדיין מריץ 22.04 לא יכול לבצע את הקפיצה הזו ישירות, כיוון שכלי השדרוג מציע תמיד רק את גרסת ה-LTS הבאה, לכן שדרוג 22.04 ל-26.04 דרך 24.04 מכסה את הדילוג הראשון ואת ה-snapshot שיש לבצע לפני השני.

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

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

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

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

• מעולם לא פתחתם את ה-console של ספק השרתים (VNC או serial) ולא התחברתם דרכו. ה-console הוא הדרך היחידה לחזור למכונה אם SSH מפסיק לעבוד, וגילוי שהוא אינו תקין בזמן שאתם נעולים מחוץ לשרת הוא מאוחר מדי.
• אינכם יכולים להרשות לעצמכם שעה של downtime ואין לכם תוכנית חזרה לאחור (rollback).
• ה-stack שלכם תלוי במאגר (repository) צד-שלישי שטרם פרסם תמיכה עבור 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 לא מציג דבר, סימן שאין חבילות שנעולות על גרסה מסוימת שעלולה לחסום את השדרוג. שחררו כל חבילה שמופיעה ברשימה באמצעות 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 ישנים בשורה אחת, וקובצי .sources בתקן deb822 עם שדות Types: ו-Suites:. שני הפורמטים מושבתים במהלך השדרוג. ubuntu-security-status --thirdparty מציג את רשימת החבילות המותקנות שאינן מסופקות על ידי מאגרי Ubuntu, וזהו המדד המדויק לתוספות שהתקנתם. כל מה שנמצא ב-/etc/apt/preferences.d/ הוא הגדרת pin, ו-pin שנכתב עבור noble ימשיך לבחור בחבילה ישנה גם בגרסה החדשה.

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

אם החיבור מתנתק בכל זאת, התחברו מחדש והריצו את tmux attach -t upgrade. השדרוג המשיך לרוץ בזמן שלא הייתם מחוברים. אם הוא לא המשיך, ואתם חוזרים למצב שבו dpkg מוגדר חלקית או שקובצי ה-apt sources הם חלקם 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, כיוון שתשובה שגויה תסיים את ה-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, מושכת עדכונים שפורסמו מאז שנוצרו תמונות ההפצה (release images).

שדרוג PostgreSQL מגרסה 16 ל-18: האשכול שנשאר מאחור

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

pg_lsclusters

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

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

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

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

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

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

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

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

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

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

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

אתר ה-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.