Aktualizacja Ubuntu 24.04 do 26.04 na VPS

Kiedy można zaktualizować Ubuntu 24.04 do 26.04?

Aktualizację Ubuntu 24.04 do 26.04 na serwerze VPS można przeprowadzić po wydaniu wersji punktowej 26.04.1, zaplanowanej na 27 sierpnia 2026. Do tego czasu serwer z systemem 24.04 celowo nie wykryje nowej wersji. Ubuntu 26.04 LTS (Resolute Raccoon) zostało udostępnione 23 kwietnia 2026, jednak Canonical otwiera ścieżkę aktualizacji między wydaniami LTS dopiero przy pierwszej wersji punktowej. Wersja ta zawiera poprawki błędów instalacji i aktualizacji wykrytych w pierwszych miesiącach. Jeśli ta numeracja jest nowością, 26.04.1 nie jest innym systemem Ubuntu, lecz tym samym 26.04 z wdrożonymi czterema miesiącami poprawek. Jest to dokładnie ta wersja, którą Canonical jako pierwszą udostępni istniejącemu serwerowi.

Uruchomienie sprawdzenia na maszynie z 24.04 na początku sierpnia 2026 skutkuje następującym komunikatem:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Nie jest to błąd serwera. Plik /etc/update-manager/release-upgrades zawiera Prompt=lts w systemie Ubuntu Server, co oznacza, że narzędzie oferuje wyłącznie kolejne wydanie o długoterminowym wsparciu (LTS) i dopiero po pojawieniu się jego wersji punktowej .1. Ustawienie Prompt=normal wymusiłoby przejście przez wersje 24.10, 25.04 oraz 25.10, czyli wydania tymczasowe, których okres wsparcia już wygasł. Należy pozostawić wartość lts i czekać. Daty w harmonogramie Canonical mogą ulec zmianie, więc jeśli wyznaczony dzień minie bez zmian, należy sprawdzić dostępność ponownie.

Każde z poniższych poleceń należy wykonać samodzielnie, na własnym serwerze, w podanej kolejności. Aktualizacji wydania nie można przetestować na maszynie, która jest aktualizowana. Proces ten zastępuje jądro systemu oraz bibliotekę C i wymaga restartu w celu zakończenia.

Czy w ogóle przeprowadzać aktualizację?

Ubuntu 24.04 otrzymuje standardowe aktualizacje bezpieczeństwa do 2029 roku, więc działający serwer produkcyjny nie jest objęty żadnym terminem. Aktualizację należy przeprowadzić, jeśli wymagane są funkcje dostępne w 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 lub jądro 7.0. „Wzrost numeru wersji” nie jest powodem do ingerencji w maszynę obsługującą klientów.

Nie należy przeprowadzać aktualizacji w miejscu, jeśli występuje którykolwiek z poniższych przypadków:

• Nigdy nie otwarto konsoli dostawcy (VNC lub szeregowej) i nie zalogowano się przez nią. Konsola ta jest jedynym sposobem na odzyskanie dostępu do serwera w przypadku awarii SSH, a wykrycie jej niedziałania po utracie dostępu jest zbyt późne.
• Nie można pozwolić sobie na godzinę przestoju i brak jest planu wycofania zmian.
• Stos technologiczny zależy od zewnętrznego repozytorium, które nie opublikowało jeszcze wersji dla resolute.
• Serwer był konfigurowany ręcznie przez ponad dwa lata i nikt nie posiada pełnej wiedzy o jego zawartości.

Alternatywne rozwiązanie jest często lepsze: należy zbudować nowy serwer VPS z systemem 26.04, zainstalować stos technologiczny i przywrócić dane, a następnie zmienić rekordy DNS po potwierdzeniu poprawności działania. Stary serwer pozostaje uruchomiony do momentu, aż nowy udowodni swoją stabilność, a wycofanie zmian polega na zmianie DNS zamiast przywracania kopii zapasowej. W przypadku wyboru tej ścieżki, należy zacząć od pierwszych dziesięciu minut na nowym serwerze VPS i poprawnie skonfigurować nową maszynę.

Krok 1: wykonanie kopii zapasowej z możliwością przywrócenia

Należy zastosować dwie warstwy zabezpieczeń, ponieważ każda z nich zawodzi w inny sposób. Migawka dostawcy obejmuje cały dysk i pozwala na przywrócenie danych w kilka minut, jednak jest wykonywana w trakcie zapisu do baz danych, co zapewnia spójność typu crash-consistent, a nie spójność na poziomie aplikacji. Kopia zapasowa na poziomie plików wykonana za pomocą restic, przechowywana poza serwerem umożliwia odzyskanie pojedynczych plików oraz zapewnia kopię, która przetrwa nawet w przypadku zablokowania konta.

W pierwszej kolejności należy ręcznie wykonać zrzut baz danych. Zrzut jest jedyną kopią zapasową bazy danych, której można zaufać bez konieczności jej zatrzymywania.

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 zapewnia spójny zrzut wyłącznie dla tabel InnoDB. Tabele MyISAM wymagają zatrzymania bazy danych. Archiwum /etc jest tym, po które faktycznie sięgniesz, ponieważ zawiera wszystkie pliki konfiguracyjne, o które proces aktualizacji będzie pytał.

Kopia zapasowa, której nigdy nie przywrócono, jest jedynie przypuszczeniem. Pobierz z niej jeden plik już teraz, zanim zajdzie potrzeba użycia jej pod presją czasu.

Krok 2: najpierw w pełni spatchuj 24.04

do-release-upgrade odmawia uruchomienia się w systemie z uszkodzonym stanem pakietów, a częściowo spatchowany 24.04 sprawia, że każda późniejsza awaria jest trudniejsza do zdiagnozowania.

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

dpkg --audit brak danych wyjściowych oznacza, że żaden pakiet nie jest w połowie skonfigurowany. apt-mark showhold brak danych wyjściowych oznacza, że żaden pakiet nie jest przypięty (pinned) do wersji, która blokowałaby aktualizację. Odblokuj każdy wymieniony pakiet za pomocą sudo apt-mark unhold i nazwy pakietu lub zaakceptuj fakt, że blokada istnieje z konkretnego powodu i przerwij w tym miejscu.

Zrestartuj system, jeśli jądro uległo zmianie, aby aktualizacja odbywała się z maszyny uruchomionej na kodzie, który faktycznie jest w użyciu.

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

Następnie sprawdź wolne miejsce na dysku. Instalator aktualizacji pobiera cały nowy zestaw pakietów przed rozpoczęciem instalacji i przerywa pracę z komunikatem wskazującym system plików, jeśli brakuje miejsca.

df -h / /boot

Problemy pojawiają się, gdy na / pozostaje mniej niż około 5 GB wolnego miejsca. Partycja /boot mniejsza niż 300 MB spowoduje późniejszą awarię podczas instalacji jądra z błędem No space left on device. Przyczyną są zazwyczaj stare jądra, a sudo apt --purge autoremove pozwala na ich usunięcie.

Jeszcze jedna kwestia do sprawdzenia przed rozpoczęciem: jeśli automatyczne aktualizacje bezpieczeństwa uruchomią się w trakcie procesu, przejmą blokadę dpkg, a instalator aktualizacji przerwie pracę z błędem Could not get lock /var/lib/dpkg/lock-frontend. Uruchom najpierw sudo systemctl stop unattended-upgrades, a po zakończeniu operacji rozpocznij aktualizację ponownie.

Krok 3: sprawdzenie repozytoriów zewnętrznych i przypiętych pakietów

do-release-upgrade wyłącza każde źródło apt, które nie należy do Ubuntu, ponieważ pakiet zbudowany dla noble może uszkodzić system resolute. Narzędzie ponownie włącza rozpoznane źródła, a pozostałe pozostawia zakomentowane. Należy wiedzieć, co jest zainstalowane, zanim narzędzie podejmie decyzję za użytkownika.

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 używa w tym katalogu dwóch formatów: starego formatu jednowierszowego plików .list oraz plików deb822 .sources z polami Types: i Suites:. Oba typy są wyłączane podczas aktualizacji. ubuntu-security-status --thirdparty wyświetla listę zainstalowanych pakietów, których nie dostarcza żadne archiwum Ubuntu; jest to rzeczywista liczba dodatków zainstalowanych w systemie. Każdy wpis w /etc/apt/preferences.d/ to przypięcie (pin), a przypięcie napisane dla noble będzie nadal wymuszać wybór starego pakietu w nowej wersji systemu.

Dla każdego zewnętrznego repozytorium należy potwierdzić, czy dostawca opublikował wersję dla nowej nazwy kodowej przed rozpoczęciem prac. Pakiety Docker są wymienione w https://download.docker.com/linux/ubuntu/dists/, a inni dostawcy udostępniają analogiczne katalogi. Źródło wskazujące na nieistniejący zestaw (suite) powoduje wystąpienie poniższego błędu przy pierwszym apt update po aktualizacji:

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

Takie źródło należy pozostawić wyłączone do czasu publikacji przez dostawcę. Edycja nazwy kodowej na taką, dla której dostawca przygotował pakiety, jest sposobem na instalację oprogramowania powiązanego z nieodpowiednimi bibliotekami systemowymi.

Krok 4: uruchom aktualizację w tmux, a nie w zwykłej powłoce SSH

Jeśli połączenie zostanie przerwane podczas działania do-release-upgrade w zwykłej powłoce logowania, proces otrzyma sygnał SIGHUP i zostanie przerwany w trakcie rozpakowywania. Pozostawia to dpkg w stanie częściowej konfiguracji, a serwer może utracić działający stos sieciowy, uniemożliwiając ponowne połączenie. Uruchom proces wewnątrz multipleksera terminala, aby pozostał on aktywny na serwerze po rozłączeniu klienta.

sudo apt install -y tmux
tmux new -s upgrade

Wewnątrz tej sesji:

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

Program aktualizujący uruchamia drugiego demona SSH na porcie 1022 przed wprowadzeniem jakichkolwiek zmian, o czym informuje użytkownika:

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.

Nie otwiera on automatycznie portu w zaporze sieciowej, ponieważ samowolna modyfikacja reguł firewall byłaby niepożądana. Otwórz port 1022 samodzielnie przed rozpoczęciem i zamknij go po zakończeniu pracy z sudo ufw delete allow 1022/tcp. Pamiętaj, że dostawca usług może utrzymywać dodatkową zaporę w panelu sterowania, poza systemem operacyjnym serwera.

Jeśli połączenie mimo wszystko zostanie przerwane, zaloguj się ponownie i uruchom tmux attach -t upgrade. Aktualizacja działała w tle podczas Twojej nieobecności.

Krok 5: rozważne odpowiadanie na monity pliku konfiguracyjnego

Narzędzie dpkg wyświetla monity tylko dla plików, które zostały zmodyfikowane przez użytkownika lub skrypt. Każdy monit dotyczy zatem pliku, który został celowo zmieniony, a naciśnięcie klawisza Enter w celu szybkiego zamknięcia okna sprawia, że zabezpieczony serwer po cichu powraca do ustawień domyślnych.

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] ?

Za każdym razem należy najpierw nacisnąć D. Należy zapoznać się z wprowadzonymi zmianami, a następnie zachować własną wersję za pomocą N. Wartością domyślną jest już N, co stanowi bezpieczną odpowiedź, ponieważ bieżący plik działa poprawnie, a wersja z pakietu nigdy nie była uruchamiana na tej maszynie.

Zachowanie własnego pliku wiąże się z kosztem: użytkownik nie otrzymuje nowych ustawień domyślnych. Należy je uzgodnić później, gdy system będzie już uruchomiony i nie będzie presji czasu.

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

Każdy wymieniony plik to wersja dostarczona przez opiekuna pakietu, zapisana obok pliku użytkownika. Należy porównać je jeden po drugim i przenieść istotne ustawienia. Dwa z nich wymagają szczególnej uwagi: /etc/ssh/sshd_config, ponieważ błędna odpowiedź kończy sesję, oraz konfiguracja serwera WWW, ponieważ błędna odpowiedź powoduje wyłączenie witryn.

Aktualizacja pyta również o usługi do zrestartowania za pośrednictwem needrestart. Należy zaakceptować pełną listę. Demon działający w oparciu o współdzieloną bibliotekę, która została usunięta z dysku, ulegnie awarii przy późniejszym żądaniu, w momencie, gdy administrator nie monitoruje systemu.

Krok 6: restart i weryfikacja systemu

sudo reboot

Po ponownym uruchomieniu:

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 powinno zwrócić Release: 26.04 oraz Codename: resolute. uname -r powinno wskazywać jądro w wersji 7.0. systemctl --failed powinno wyświetlić zero jednostek, a każda pozycja, która się pojawi, wymaga dalszej analizy. Ostatnie polecenie apt update pobiera aktualizacje opublikowane po przygotowaniu obrazów instalacyjnych.

PostgreSQL 16 do 18: klaster, który pozostaje w tyle

Ubuntu 24.04 dostarcza PostgreSQL 16, a 26.04 zawiera PostgreSQL 18. Aktualizacja instaluje wersję 18 obok wersji 16 i nie przenosi danych. Warstwa postgresql-common w systemie Debian tworzy nowy, pusty klaster dla nowej wersji głównej na kolejnym wolnym porcie. W rezultacie wersja 16 zachowuje port 5432 wraz ze wszystkimi danymi, a wersja 18 pozostaje pusta na porcie 5433. Aplikacja nadal komunikuje się z portem 5432 i wszystko wydaje się poprawne, dlatego problem ten jest często wykrywany dopiero po miesiącach.

pg_lsclusters

Obecność dwóch klastrów na liście oznacza, że migracja nie została przeprowadzona. Należy ją wykonać w czasie, gdy możliwe jest zatrzymanie aplikacji:

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

Najpierw należy usunąć pusty klaster 18, ponieważ pg_upgradecluster nie zapisze danych do istniejącego klastra docelowego. Domyślna metoda wykonuje zrzut danych z wersji 16 i ładuje je do 18, co wymaga wolnego miejsca na dysku o rozmiarze zbliżonym do rozmiaru bazy danych. Narzędzie -m upgrade wykorzystuje pg_upgrade, co jest znacznie szybsze w przypadku dużych baz danych. Po zakończeniu operacji należy sprawdzić kolumnę Port: nowy klaster przejmuje port 5432, a stary pozostaje w stanie zatrzymanym. Operację analizy (analyze) należy wykonać samodzielnie, ponieważ świeżo załadowany klaster nie posiada statystyk, co spowoduje spowolnienie pierwszych zapytań.

Przez kilka dni należy testować aplikację z nowym klastrem. Dopiero po tym czasie można usunąć stary klaster:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Katalog danych starego klastra stanowi najszybszą metodę przywrócenia poprzedniego stanu. Nie należy usuwać go w dniu aktualizacji.

MySQL 8.0 do 8.4: usunięta opcja blokująca serwer

Wersja 26.04 wprowadza zmianę MySQL z 8.0 na 8.4 LTS, co powoduje dwa problemy z uruchomieniem serwerów.

Po pierwsze, mysqld odmawia startu, jeśli plik konfiguracyjny zawiera opcję usuniętą w nowej wersji. Często spotykanym przypadkiem jest default_authentication_plugin, ponieważ wiele starszych poradników zaleca jej ustawienie. Usługa nie uruchamia się, a journalctl -u mysql -n 50 wskazuje bezpośrednio na nieznaną zmienną. Należy usunąć tę linię z pliku w /etc/mysql/mysql.conf.d/, a następnie wykonać sudo systemctl start mysql.

Po drugie, wtyczka mysql_native_password nie jest już domyślnie włączona w wersji 8.4, więc konto nadal z niej korzystające nie może się zalogować. Należy to sprawdzić jeszcze przed migracją z wersji 8.0:

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

Przed aktualizacją należy przenieść każde konto wykazujące mysql_native_password, a następnie zaktualizować hasło w konfiguracji aplikacji:

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

Jeśli biblioteka kliencka jest zbyt stara, aby obsługiwać caching_sha2_password, można ponownie włączyć starą wtyczkę w wersji 8.4, dodając mysql_native_password=ON w sekcji [mysqld]. Należy traktować to jako rozwiązanie tymczasowe, ponieważ wtyczka ta jest całkowicie wycofywana.

PHP 8.3 do 8.5: vhosty wskazują na nieistniejący socket

Wersja 24.04 dostarcza PHP 8.3, a 26.04 dostarcza PHP 8.5. Pakiety instalowane są w ścieżkach zawierających wersję, a proces aktualizacji nie modyfikuje konfiguracji serwera WWW. Vhost nginx zawierający fastcgi_pass unix:/run/php/php8.3-fpm.sock; wskazuje teraz na socket, którego żaden proces nie tworzy, więc każde żądanie PHP zwraca błąd 502, a log błędów nginx zawiera:

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

Skieruj konfigurację na nowy socket, przetestuj ją i przeładuj usługę:

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

W przypadku Apache z mod_php objawy są inne: Apache nie uruchomi się w ogóle, a sudo apache2ctl -t zgłosi błąd ładowania libphp8.3.so z powodu braku pliku. Włączony moduł jest dowiązaniem symbolicznym do pakietu, który już nie istnieje.

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

Jeśli serwer został przygotowany zgodnie z a LAMP stack on Ubuntu 24.04, warto sprawdzić obie te ścieżki, ponieważ poradnik pozostawia nazwę modułu oraz ścieżkę do socketu z numerem wersji.

Twoje dostrojenie php.ini również nie jest przenoszone automatycznie. memory_limit, upload_max_filesize oraz wszelkie inne ustawienia znajdują się w /etc/php/8.3/, a nowe drzewo konfiguracji startuje z wartościami domyślnymi. Porównaj oba pliki za pomocą diff i ręcznie przenieś wartości. Nadpisanie nowego pliku starym spowoduje przeniesienie domyślnych ustawień 8.3 do instalacji 8.5. Następnie uruchom php -m i porównaj wyniki: rozszerzenie zainstalowane jako php8.3-redis wymaga pakietu php8.5-, a jeśli pochodziło z PPA, proces aktualizacji wyłączył to źródło i rozszerzenie jest po prostu niedostępne.

Certyfikaty wymagają osobnej weryfikacji. Po aktualizacji uruchom sudo certbot renew --dry-run. Polecenie to sprawdza całą ścieżkę odnawiania, włącznie z wywołaniem przeładowania serwera WWW, bez modyfikowania aktywnego certyfikatu. Jeśli skrypt typu hook odwołuje się do nazwy usługi lub pliku binarnego, który uległ zmianie, błąd wystąpi teraz, na Twoich oczach, zamiast po cichu za 60 dni. Certbot with Let's Encrypt on nginx opisuje, jak powinny wyglądać takie skrypty.

SSH: awaria kończąca bieżącą sesję

Monit sshd_config to miejsce, w którym użytkownicy często blokują sobie dostęp. Odpowiedź Y instaluje plik dostarczony przez opiekuna pakietu, co powoduje nadpisanie PermitRootLogin, PasswordAuthentication, AllowUsers, Port oraz wszystkich innych linii dodanych przez użytkownika. Jeśli firewall zezwala tylko na niestandardowy port, a konfiguracja pakietowa nasłuchuje na 22, kolejne połączenie zostanie odrzucone, a sesja, w której aktualnie pracujesz, będzie ostatnią dostępną.

Zapobiegnij temu przed aktualizacją. /etc/ssh/sshd_config w wersji 24.04 rozpoczyna się od Include /etc/ssh/sshd_config.d/*.conf, a OpenSSH zachowuje pierwszą napotkaną wartość dla każdego ustawienia, więc plik typu drop-in umieszczony na początku ma pierwszeństwo przed wszystkim, co znajduje się poniżej. Przenieś swoje ustawienia do pliku, którego dpkg nie zarządza:

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

Gdy w /etc/ssh/sshd_config nie ma już Twoich własnych ustawień, monit przestaje mieć znaczenie: każda odpowiedź zachowa Twoją konfigurację, ponieważ znajduje się ona w innym pliku.

Niestandardowy port wymaga dodatkowej weryfikacji, ponieważ może nie znajdować się tam, gdzie oczekujesz:

systemctl is-enabled ssh.socket

Jeśli polecenie zwróci enabled, to systemd zarządza portem nasłuchiwania, a linia Port w sshd_config jest ignorowana. Ubuntu korzysta z aktywacji gniazd (socket activation) dla sshd od wersji 22.10 i jest to powód, dla którego edycja Port 2222 wydaje się nie przynosić efektów. Ustaw port w jednostce gniazda za pomocą sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Pusta linia ListenStream= jest wymagana. Czyści ona odziedziczoną wartość; bez niej gniazdo nasłuchuje zarówno na porcie 22, jak i 2222. Zastosuj zmiany za pomocą sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Po aktualizacji, przed zamknięciem bieżącej sesji:

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

Następnie otwórz drugi terminal na własnej maszynie i zaloguj się ponownie. Działająca powłoka w drugim terminalu jest jedynym wiarygodnym dowodem poprawności konfiguracji. Nie zamykaj pierwszej sesji, dopóki nie uzyskasz dostępu w drugiej. Zabezpieczanie SSH na VPS zawiera zestawienie ustawień, które warto zachować w pliku drop-in.

Jeśli jest już za późno, konsola internetowa dostawcy oferuje logowanie z pominięciem SSH. Zaloguj się przez nią, popraw konfigurację, wykonaj sudo sshd -t i zrestartuj usługę. Ta konsola jest właśnie powodem, dla którego dostęp do niej należy przetestować przed aktualizacją, a nie w jej trakcie.

FAQ

Dlaczego do-release-upgrade zgłasza "No new release found" na Ubuntu 24.04?

Ponieważ /etc/update-manager/release-upgrades zawiera Prompt=lts w wersji Ubuntu Server, a to ustawienie oferuje kolejne wydanie o przedłużonym wsparciu (LTS) dopiero po pojawieniu się jego pierwszego wydania punktowego. Ubuntu 26.04 LTS zostało wydane 23 kwietnia 2026, a wersja 26.04.1 jest zaplanowana na 27 sierpnia 2026. Do tego dnia serwer 24.04 nie wykryje żadnej aktualizacji. Należy pozostawić to ustawienie bez zmian, zamiast przełączać się na Prompt=normal, co wymusiłoby ścieżkę aktualizacji przez wydania tymczasowe.

Czy muszę zrestartować serwer, aby zakończyć aktualizację?

Tak. Aktualizacja instaluje nowe jądro, nową bibliotekę C oraz nowy system init, a działający system korzysta ze starych wersji aż do momentu restartu. do-release-upgrade prosi o restart po zakończeniu procesu, a maszyna pozostawiona w działaniu "do później" pracuje na mieszance dwóch wydań. Po ponownym uruchomieniu sprawdź uname -r pod kątem nowego jądra oraz systemctl --failed w poszukiwaniu usług, które nie przetrwały procesu.

Czy powinienem wykonać aktualizację w miejscu, czy postawić nowy serwer 26.04?

Jeśli to możliwe, stawiaj nowy serwer. Nowy VPS pozwala zainstalować stos oprogramowania, przywrócić dane i przetestować wszystko, podczas gdy stary serwer nadal obsługuje ruch. Dzięki temu wycofanie zmian sprowadza się do zmiany rekordu DNS, a nie przywracania z kopii zapasowej. Aktualizację w miejscu wybierz, gdy serwer przechowuje stan trudny do przeniesienia, gdy dostawca nalicza opłaty za każdą maszynę lub gdy posiadasz snapshot i sprawdzony dostęp przez konsolę. Ścieżka aktualizacji w miejscu jest dobrze przetestowana, ale na czas jej trwania jest to proces nieodwracalny.

Co się stanie, jeśli połączenie SSH zostanie przerwane podczas aktualizacji?

W zwykłej powłoce logowania proces otrzymuje sygnał SIGHUP i kończy działanie w trakcie pracy, co pozostawia dpkg w stanie częściowej konfiguracji. Uruchomienie procesu wewnątrz tmux lub screen sprawia, że proces przetrwa rozłączenie, co pozwala na ponowne połączenie i użycie tmux attach -t upgrade w celu wznowienia pracy. Instalator uruchamia również zapasowy demon SSH na porcie 1022 jako alternatywną drogę dostępu, jednak nie otwiera dla niego firewalla, więc należy samodzielnie zezwolić na ruch na porcie 1022 przed rozpoczęciem i zamknąć go po zakończeniu.

Moja strona PHP zwraca błąd 502 po aktualizacji. Co uległo awarii?

Ścieżka do gniazda PHP FPM zmieniła się wraz z wersją. Ubuntu 24.04 korzysta z PHP 8.3, a 26.04 z PHP 8.5, więc /run/php/php8.3-fpm.sock już nie istnieje, podczas gdy Twój vhost nginx nadal się do niego odwołuje. Dziennik błędów nginx wskazuje na connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Zaktualizuj fastcgi_pass do gniazda 8.5, wykonaj sudo nginx -t, a następnie przeładuj nginx. W przypadku Apache z mod_php odpowiednią poprawką jest sudo a2dismod php8.3, po której należy wykonać sudo a2enmod php8.5 i restart usługi.