Aktualizacja Ubuntu 24.04 do 26.04 na serwerze 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 roku. Do tego czasu serwer z systemem 24.04 celowo nie będzie wykrywał nowej wersji. Ubuntu 26.04 LTS (Resolute Raccoon) zostało wydane 23 kwietnia 2026 roku, jednak Canonical udostępnia ś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 po premierze.

Uruchomienie sprawdzania na maszynie z systemem 24.04 na początku sierpnia 2026 roku zwróci następujący wynik:

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 wpis Prompt=lts w systemie Ubuntu Server, co oznacza, że narzędzie oferuje wyłącznie kolejne wydanie o długoterminowym wsparciu (LTS) i tylko wtedy, gdy istnieje jego wersja punktowa .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, dlatego warto sprawdzić dostępność aktualizacji ponownie, jeśli wyznaczony termin minie bez zmian.

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 ponownego uruchomienia serwera w celu zakończenia operacji.

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 oferowane przez 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 prawdziwy jest którykolwiek z poniższych punktów:

• Nigdy nie otwierano konsoli dostawcy (VNC lub szeregowej) i nie logowano się przez nią. Konsola ta jest jedyną drogą powrotu do systemu w przypadku awarii SSH, a odkrycie jej niedziałania po utracie dostępu jest zbyt późne.
• Niedopuszczalna jest godzina przestoju, a brak jest możliwości 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.

Alternatywa jest często lepsza: należy zbudować nowy serwer VPS z systemem 26.04, zainstalować stos technologiczny, przywrócić dane, a następnie przełączyć DNS po potwierdzeniu poprawnego działania. Stary serwer pozostaje uruchomiony do czasu, aż nowy potwierdzi swoją stabilność, a wycofanie zmian sprowadza się do zmiany rekordu 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 application-consistent. 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 system zapyta podczas aktualizacji.

Kopia zapasowa, której nigdy nie przywrócono, jest jedynie przypuszczeniem. Pobierz z niej jeden plik już teraz, zanim zajdzie potrzeba wykonania tej czynności 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 system 24.04 utrudnia analizę każdej późniejszej awarii.

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 do wersji, która blokowałaby aktualizację. Odblokuj każdy pakiet wymieniony na liście za pomocą sudo apt-mark unhold oraz 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 system uważa za aktywny.

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

Następnie sprawdź wolne miejsce na dysku. Narzędzie aktualizacyjne pobiera cały nowy zestaw pakietów przed rozpoczęciem instalacji i przerywa pracę z komunikatem wskazującym system plików, jeśli ilość miejsca jest niewystarczająca.

df -h / /boot

Poniżej około 5 GB wolnego miejsca na / proces ten kończy się niepowodzeniem. Partycja /boot mniejsza niż 300 MB zawiedzie później, podczas instalacji jądra, z błędem No space left on device. Przyczyną są zazwyczaj stare jądra, a polecenie sudo apt --purge autoremove usuwa je.

Jeszcze jedna rzecz do zatrzymania przed rozpoczęciem: jeśli automatyczne aktualizacje bezpieczeństwa uruchomią się w trakcie procesu, zajmą blokadę dpkg, a narzędzie aktualizacyjne przerwie pracę z błędem Could not get lock /var/lib/dpkg/lock-frontend. Uruchom najpierw sudo systemctl stop unattended-upgrades i rozpocznij ponownie po zakończeniu tego procesu.

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 pochodzi z Ubuntu, ponieważ pakiet zbudowany dla noble może uszkodzić system resolute. Narzędzie ponownie włącza rozpoznane źródła, a resztę pozostawia zakomentowaną. Należy wiedzieć, co znajduje się w systemie, 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, jednowierszowego formatu plików .list oraz formatu deb822 w plikach .sources z polami Types: i Suites:. Oba formaty 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 utworzone dla noble będzie wymuszać wybór starego pakietu w nowym wydaniu systemu.

Dla każdego zewnętrznego repozytorium należy potwierdzić, czy dostawca opublikował wersję dla nowej nazwy kodowej przed rozpoczęciem procesu. Pakiety Docker są wymienione pod adresem https://download.docker.com/linux/ubuntu/dists/, a inni dostawcy udostępniają analogiczne katalogi. Źródło wskazujące na pakiet, który nie istnieje, powoduje wystąpienie poniższego błędu przy pierwszym poleceniu 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 nie przygotował kompilacji, prowadzi do instalacji pakietów powiązanych z nieprawidłowymi 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, co uniemożliwi ponowne połączenie. Uruchom proces wewnątrz multipleksera terminala, dzięki czemu pozostanie on aktywny na serwerze nawet 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

Narzędzie aktualizujące uruchamia drugiego demona SSH na porcie 1022 przed wprowadzeniem jakichkolwiek zmian i informuje o tym:

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 ono automatycznie portu w zaporze sieciowej, ponieważ samowolne modyfikowanie reguł firewalla byłoby niepożądanym działaniem. 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 może utrzymywać dodatkową zaporę sieciową 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 edytowanego celowo, a naciśnięcie klawisza Enter w celu szybkiego zamknięcia monitu jest sposobem, w jaki 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 najpierw naciśnij D. Przeczytaj, co uległo zmianie, a następnie zachowaj swoją wersję za pomocą N. Wartością domyślną jest już N, co stanowi bezpieczną odpowiedź, ponieważ bieżący plik działa, 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 opiekuna pakietu, zapisana obok wersji 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ź zakończy sesję, oraz konfiguracja serwera WWW, ponieważ błędna odpowiedź spowoduje wyłączenie witryn.

Aktualizacja pyta również o to, które usługi należy zrestartować za pomocą 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 będzie monitorował 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 wykazać zero jednostek; każda pozycja na liście wymaga dalszej analizy. Ostatnie polecenie apt update pobiera aktualizacje opublikowane po utworzeniu obrazów instalacyjnych.

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

Ubuntu 24.04 dostarcza PostgreSQL 16, a 26.04 dostarcza 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 ze wszystkimi danymi, a wersja 18 pozostaje pusta na porcie 5433. Aplikacja nadal komunikuje się z portem 5432 i wszystko wydaje się poprawne, dlatego użytkownicy odkrywają ten stan dopiero po miesiącach.

pg_lsclusters

Dwa wymienione klastry oznaczają, że migracja nie została przeprowadzona. Należy ją wykonać w momencie, 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 wersji 18, dlatego wymagane jest wolne miejsce na dysku o rozmiarze zbliżonym do bazy danych. Opcja -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. Proces analizy statystyk należy przeprowadzić samodzielnie, ponieważ świeżo załadowany klaster nie posiada statystyk, co spowoduje spowolnienie pierwszych zapytań.

Należy przetestować aplikację z nowym klastrem przez kilka dni. 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 go usuwać w dniu aktualizacji.

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

Wersja 26.04 przenosi MySQL z 8.0 na 8.4 LTS, co wiąże się z dwiema zmianami wpływającymi na działanie serwerów.

Po pierwsze, mysqld odmawia uruchomienia, jeśli plik konfiguracyjny zawiera opcję usuniętą w nowej wersji. default_authentication_plugin jest najczęstszą przyczyną, ponieważ wiele starszych poradników zaleca jej ustawienie. Usługa nie startuje, 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 nie tworzy żaden proces, 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 na podstawie stosu LAMP na 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 przenosi się automatycznie. memory_limit, upload_max_filesize oraz inne ustawienia znajdują się w /etc/php/8.3/, a nowe drzewo katalogów startuje z wartościami domyślnymi. Porównaj oba pliki za pomocą diff i ręcznie przenieś wartości. Nadpisanie nowego pliku starym przeniesie domyślne ustawienia 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 tym skrypt przeładowujący serwer WWW, bez modyfikowania aktywnego certyfikatu. Skrypt wywołujący nazwę usługi lub plik binarny, który uległ zmianie, zawiedzie w tym momencie, zamiast przestać działać po cichu za 60 dni. Certbot z Let's Encrypt na nginx opisuje, jak powinny wyglądać takie skrypty.

SSH: błąd kończący bieżącą sesję

Monit sshd_config to miejsce, w którym użytkownicy najczęściej tracą dostęp do serwera. Odpowiedź Y instaluje plik dostarczony przez opiekuna pakietu, co powoduje nadpisanie PermitRootLogin, PasswordAuthentication, AllowUsers, Port oraz wszystkich innych dodanych linii. Jeśli firewall zezwala tylko na niestandardowy port, a domyślna konfiguracja nasłuchuje na 22, kolejne połączenie zostanie odrzucone, a bieżąca sesja będzie ostatnią dostępną.

Należy temu zapobiec przed aktualizacją. /etc/ssh/sshd_config w wersji 24.04 zaczyna się od Include /etc/ssh/sshd_config.d/*.conf, a OpenSSH zachowuje pierwszą napotkaną wartość dla każdego ustawienia. Plik typu drop-in umieszczony na początku ma pierwszeństwo przed wszystkimi poniższymi wpisami. Przenieś własne ustawienia do pliku, który nie jest zarządzany przez 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

Gdy w /etc/ssh/sshd_config nie ma już żadnych własnych wpisów, monit przestaje stanowić zagrożenie: każda odpowiedź zachowa Twoją konfigurację, ponieważ znajduje się ona w innym pliku.

Niestandardowy port wymaga dodatkowej weryfikacji, ponieważ może nie znajdować się w miejscu, w którym go oczekujesz:

systemctl is-enabled ssh.socket

Jeśli polecenie zwróci enabled, 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 wartość ListenStream= jest wymagana. Czyści ona odziedziczoną wartość; bez tego 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 drugą terminal na własnej maszynie i zaloguj się ponownie. Działająca powłoka w tym drugim terminalu jest jedynym wiarygodnym dowodem poprawności konfiguracji. Nie zamykaj pierwszej sesji, dopóki nie uzyskasz dostępu w drugiej. Hardening SSH on a VPS zawiera opis 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ę. Konsola ta jest 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ż plik /etc/update-manager/release-upgrades zawiera wpis Prompt=lts w wersji Ubuntu Server, a to ustawienie oferuje kolejne wydanie o długoterminowym wsparciu (LTS) dopiero po pojawieniu się jego pierwszego wydania punktowego. System Ubuntu 26.04 LTS został wydany 23 kwietnia 2026, a wersja 26.04.1 jest zaplanowana na 27 sierpnia 2026. Do tego dnia serwer z 24.04 nie wykryje nowej wersji. 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. Narzędzie 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 należy sprawdzić uname -r pod kątem nowego jądra oraz systemctl --failed w celu wykrycia 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, należy stawiać nowy serwer. Nowy VPS pozwala zainstalować stos oprogramowania, przywrócić dane i przetestować wszystko, podczas gdy stary serwer nadal obsługuje ruch, więc wycofanie zmian sprowadza się do zmiany wpisu DNS, a nie przywracania z kopii zapasowej. Aktualizację w miejscu należy stosować, gdy serwer przechowuje stan trudny do przeniesienia, gdy dostawca nalicza opłaty za każdą maszynę lub gdy dysponuje się snapshotem i sprawdzonym dostępem przez konsolę. Ścieżka aktualizacji w miejscu jest dobrze przetestowana, ale w trakcie 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 połowie, 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 automatycznie tego portu w zaporze sieciowej, więc należy zezwolić na ruch na porcie 1022 samodzielnie przed rozpoczęciem i zamknąć go po zakończeniu.

Moja witryna 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 plik /run/php/php8.3-fpm.sock już nie istnieje, podczas gdy wirtualny host 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). Należy zaktualizować fastcgi_pass do gniazda wersji 8.5, wykonać sudo nginx -t, a następnie przeładować nginx. W przypadku Apache z mod_php odpowiednim rozwiązaniem jest sudo a2dismod php8.3, po którym następuje sudo a2enmod php8.5 oraz restart usługi.