Canonical opublikował Ubuntu 26.04 LTS Resolute Raccoon 23 kwietnia 2026 r. Dla użytkownika desktopowego to kolejna wersja z nowym środowiskiem GNOME, lepszą obsługą Waylanda i odświeżonym zestawem aplikacji. Dla administratora, inżyniera DevOps i osoby utrzymującej serwery ważniejsze jest jednak coś innego: 26.04 LTS zmienia kilka bazowych założeń, do których wiele środowisk Ubuntu przyzwyczaiło się przez lata.
To wydanie warto potraktować nie jako rutynowy upgrade LTS do LTS, lecz jako punkt kontrolny dla całej infrastruktury: usług startowanych starymi skryptami SysV, kontenerów zakładających obecność cgroup v1, własnych repozytoriów używających apt-key, hostów polegających na systemd-timesyncd, a także maszyn z nietypowym boot chainem. W 26.04 LTS pojawiają się jednocześnie Linux kernel 7.0, systemd 259, APT 3.1, Netplan 1.2 i Dracut jako domyślna infrastruktura initramfs. To zestaw, który realnie wpływa na utrzymanie systemów, automatyzację i procedury awaryjne.
Co dokładnie zostało wydane 23 kwietnia 2026 r.
Ubuntu 26.04 LTS nosi nazwę kodową Resolute Raccoon. Oficjalny harmonogram wydania wskazywał final release na 23 kwietnia 2026 r., a pierwsze wydanie punktowe 26.04.1 zaplanowano na 9 lipca 2026 r. Dla zespołów utrzymujących produkcję oznacza to jasny podział: można rozpocząć testy integracyjne na obrazach 26.04 od razu, ale masowe przejście większych flot warto powiązać z własnym oknem serwisowym i wynikiem testów po pierwszym cyklu poprawek.
Najważniejsze zmiany bazowe dla administratorów to:
- Linux kernel 7.0 zamiast 6.8 w ścieżce GA dla użytkowników przechodzących z Ubuntu 24.04 LTS.
- systemd 259 oraz koniec wsparcia dla cgroup v1 w trybach legacy i hybrid.
- ostatnie wydanie Ubuntu LTS ze zgodnością skryptów System V w systemd, co jest wyraźnym sygnałem do migracji usług do natywnych unitów.
- APT 3.1, usunięcie
apt-key, nowy resolver zależności i historia transakcji APT. - Chrony jako domyślny daemon czasu dla nowych instalacji zamiast
systemd-timesyncd. - Dracut jako domyślna infrastruktura initramfs zamiast
initramfs-tools, przy zachowaniu możliwości przełączenia w razie potrzeby. - OpenSSH 1:10.2p1 przy upgrade z 24.04 LTS, z istotnymi zmianami kryptograficznymi, w tym usunięciem słabego DSA.
Kernel 7.0: nie tylko numer wersji
W Ubuntu 26.04 LTS kernel został podniesiony do wersji 7.0. Z punktu widzenia admina najciekawsze nie jest samo „7.0”, lecz zakres konsekwencji: lepsze wsparcie nowego sprzętu, zmiany dla workloadów real-time, crash dumpy włączone domyślnie oraz szerszy kontekst pod systemy AI i edge.
Canonical podkreśla obsługę procesorów Intel Core Ultra Series 3, znanych pod nazwą kodową Panther Lake, wraz z optymalizacjami dla zintegrowanej grafiki Intel Xe3 i NPU. To ważne dla stacji roboczych developerów, laboratoriów ML i małych węzłów edge, gdzie inference lokalny coraz częściej działa poza klasycznym centrum danych. W praktyce oznacza to, że Ubuntu 26.04 LTS może być naturalnym wyborem dla nowych laptopów, mini-PC i stacji roboczych kupowanych w cyklu 2026/2027, szczególnie jeśli organizacja nie chce utrzymywać własnego kernela HWE na starszej bazie systemu.
Drugą zmianą wartą odnotowania jest dostępność kernela real-time w głównym archiwum w Ubuntu 26.04. Po upstreamowaniu łatek PREEMPT_RT Canonical udostępnia real-time kernel bez wymogu Ubuntu Pro. To może uprościć testy w środowiskach przemysłowych, audio, telco i labach automatyki, ale nie zwalnia z walidacji. Real-time kernel nie jest magicznym przełącznikiem wydajności. Trzeba mierzyć opóźnienia, sprawdzić sterowniki, przerwania, affinity CPU i zachowanie aplikacji pod obciążeniem.
systemd 259: cgroup v1 znika, SysV dostaje ostatnie ostrzeżenie
Najbardziej operacyjnie ryzykowna zmiana dotyczy systemd. Ubuntu 26.04 LTS przechodzi z systemd 255 do 259. W release notes znalazły się dwie informacje, które powinny trafić do każdej checklisty migracyjnej: usunięto obsługę cgroup v1 w wariantach legacy i hybrid, a 26.04 LTS jest ostatnim wydaniem wspierającym zgodność skryptów System V w systemd.
Jeżeli utrzymujesz starsze aplikacje, appliance’y, agentów backupu, własne demony lub narzędzia vendorowe instalujące pliki w /etc/init.d, nie odkładaj tematu do następnego LTS. W 26.04 takie skrypty mogą jeszcze działać przez warstwę zgodności, ale jest to wyraźny okres przejściowy. Migracja do natywnych unitów systemd daje lepsze logowanie przez journal, jawne zależności, restart policy, sandboxing, limitowanie zasobów i czytelniejsze zachowanie przy bootowaniu.
find /etc/init.d -maxdepth 1 -type f -perm /111 -print
systemctl list-unit-files --type=service | grep -E 'generated|bad|masked'
stat -fc %T /sys/fs/cgroup
systemctl --versionJeżeli stat -fc %T /sys/fs/cgroup zwraca cgroup2fs, system pracuje na cgroup v2. Dla nowych Ubuntu to normalny kierunek, ale problem pojawi się tam, gdzie stare runtime’y kontenerów, agenty monitoringu albo narzędzia do limitowania zasobów zakładały ręcznie montowane kontrolery cgroup v1. Przed migracją warto sprawdzić wersje containerd, Docker Engine, Kubernetes node components, Nomad, systemowych exporterów i oprogramowania bezpieczeństwa działającego w trybie hostowym.
APT 3.1: porządki w kluczach i lepsza audytowalność zmian
APT w Ubuntu 26.04 LTS został podniesiony z 2.7 do 3.1. Najbardziej praktyczna zmiana: polecenie apt-key zostało usunięte. To nie jest kosmetyka. W wielu starszych instrukcjach instalacji repozytoriów zewnętrznych nadal pojawia się schemat curl ... | sudo apt-key add -. W 26.04 taki proces trzeba zastąpić repozytoriami z kluczami wskazanymi przez Signed-By, zwykle w katalogu /etc/apt/keyrings.
Druga zmiana to historia transakcji. APT udostępnia komendy pozwalające listować, przeglądać i odwracać część zmian. Dla admina to bardzo użyteczne podczas analizy awarii po aktualizacji pakietów, szczególnie na hostach, gdzie nie ma pełnego systemu zarządzania konfiguracją albo gdzie ręczne działania serwisowe nadal się zdarzają.
apt --version
apt history-list
apt history-info 0
sudo install -d -m 0755 /etc/apt/keyrings
# Przykładowy kierunek migracji: repozytorium z opcją signed-by,
# bez używania usuniętego apt-key.Warto przejrzeć skrypty bootstrapujące serwery, obrazy Packer, role Ansible, moduły Puppet/Chef oraz dokumentację wewnętrzną. Jeżeli gdziekolwiek występuje apt-key, to jest to dług techniczny do usunięcia przed wdrożeniem 26.04. Przy okazji warto wymusić jawne repozytoria w plikach .sources albo klasycznych .list z signed-by, zamiast polegać na globalnym zaufaniu kluczy.
Chrony, OpenSSH i czas w środowisku produkcyjnym
Nowe instalacje Ubuntu 26.04 LTS używają Chrony jako domyślnego daemona czasu, zastępując systemd-timesyncd. Canonical podaje również prostą ścieżkę migracji dla systemów po upgrade. Dla serwerów to dobry moment, aby ustandaryzować politykę NTP/NTS, zwłaszcza w środowiskach z Kerberosem, logowaniem zdarzeń bezpieczeństwa, podpisywaniem artefaktów, bazami danych i klastrami rozproszonymi. Rozjechany czas nadal potrafi generować awarie trudniejsze do zdiagnozowania niż brakujący pakiet.
sudo apt-mark auto systemd-timesyncd
sudo apt install chrony
systemctl status chrony --no-pager
chronyc tracking
chronyc sources -vOpenSSH w ścieżce upgrade z 24.04 LTS przechodzi z pakietu 1:9.6p1 do 1:10.2p1. W release notes wymieniono między innymi ostrzeżenia dla SHA1 SSHFP DNS records, ostrzeżenia przy negocjacji niepostkwantowego algorytmu wymiany kluczy, usunięcie wsparcia dla słabego DSA, nową opcję PerSourcePenalties i domyślnie dostępny hybrydowy algorytm wymiany kluczy mlkem768x25519-sha256. Przed migracją serwerów bastionowych i starszych appliance’ów trzeba sprawdzić kompatybilność klientów, kluczy hosta oraz automatyzacji używającej starych bibliotek SSH.
Dracut i /tmp jako tmpfs: małe zmiany, duży wpływ na nietypowe hosty
Ubuntu 26.04 LTS używa Dracut jako domyślnej infrastruktury initramfs. initramfs-tools pozostaje wspierane i można przełączać się między implementacjami, ale domyślny kierunek jest jasny: initramfs oparty o Dracut i systemd. W typowej instalacji administrator nie powinien odczuć problemów, lecz środowiska z niestandardowym szyfrowaniem, rootem na sieci, iSCSI, NVMe-oF, własnymi hookami albo modułami kernela powinny przejść pełny test bootowania i recovery.
Równie istotne jest to, że Ubuntu dostarcza upstreamowy unit tmp.mount, przez co /tmp jest domyślnie systemem plików tmpfs. To rozsądne bezpieczeństwowo i wydajnościowo, ale potrafi zaskoczyć aplikacje zapisujące duże pliki tymczasowe. Przed migracją warto przejrzeć batch jobs, pipeline’y CI, procesy ETL, narzędzia backupu i aplikacje legacy. Jeśli coś używa /tmp jako taniego magazynu roboczego na dziesiątki gigabajtów, po upgrade może wymagać korekty konfiguracji.
Bezpieczeństwo i memory safety: Rust, sudo-rs, uutils i sandboxing obrazów
Canonical opisuje Ubuntu 26.04 LTS jako wydanie rozszerzające liczbę komponentów systemowych tworzonych w języku Rust. Wskazuje między innymi nowe sterowniki i podsystemy kernela, sudo-rs oraz uutils coreutils jako memory-safe reimplementacje narzędzi fundamentu systemu. Nie oznacza to, że cała dystrybucja nagle stała się wolna od błędów pamięci, ale kierunek jest istotny: mniej krytycznego kodu w C w miejscach, które są stale wystawione na kontakt z użytkownikiem, wejściem z plików albo uprawnieniami administracyjnymi.
Na desktopach i stacjach roboczych warto odnotować przejście gdk-pixbuf na parser glycin dla wielu aplikacji używających ładowania obrazów. Release notes opisują to jako zmianę obejmującą około 700 pakietów zależnych od gdk-pixbuf. Z punktu widzenia bezpieczeństwa to interesujące, bo parsery obrazów są klasycznym źródłem błędów pamięciowych: plik graficzny trafia do komunikatora, klienta poczty, przeglądarki plików albo narzędzia graficznego i uruchamia złożony kod dekodujący. Sandboxing parsera ogranicza skutki potencjalnych błędów.
Jak podejść do migracji z 24.04 LTS
Najgorszy scenariusz to traktowanie Ubuntu 26.04 LTS jako „kolejnego apt upgrade”. Lepszy model to mały projekt migracyjny z inwentaryzacją ryzyk. Dla środowisk produkcyjnych sensowna checklista obejmuje:
- Utworzenie obrazu testowego 26.04 LTS dla każdego typu hosta: VM, bare metal, stacja robocza, runner CI, node kontenerowy, bastion, serwer bazodanowy.
- Sprawdzenie usług SysV i przygotowanie natywnych unitów systemd dla wszystkiego, co nadal startuje z
/etc/init.d. - Weryfikację cgroup v2 z runtime’ami kontenerów, agentami observability i politykami limitów zasobów.
- Usunięcie
apt-keyze skryptów oraz przeniesienie kluczy repozytoriów do modeluSigned-By. - Test Chrony i polityki NTP/NTS, szczególnie w środowiskach domenowych, klastrowych i regulowanych.
- Test bootowania po zmianie initramfs na Dracut, w tym scenariusze awaryjne: starszy kernel, recovery mode, szyfrowany root, snapshot, rollback.
- Audyt użycia
/tmp, jeśli systemy wykonują duże joby lub mają ograniczony RAM. - Sprawdzenie kompatybilności SSH ze starszymi klientami, kluczami i urządzeniami sieciowymi.
Warto również wdrożyć własne testy powtarzalne. Minimum to start usług, healthcheck aplikacji, połączenie SSH, synchronizacja czasu, test zapisu do katalogów tymczasowych, instalacja pakietu z każdego zewnętrznego repozytorium i restart po aktualizacji kernela. Dla infrastruktury jako kodu dobrze jest przygotować osobną gałąź dla 26.04, zamiast doklejać wyjątki do istniejących ról dla 22.04 i 24.04.
Krótkie podsumowanie praktyczne
Ubuntu 26.04 LTS z 23 kwietnia 2026 r. jest ważnym wydaniem dla adminów nie dlatego, że ma nowy numer, lecz dlatego, że przesuwa bazę technologiczną Ubuntu w stronę cgroup v2, systemd 259, APT 3.1, Dracut, Chrony, nowszego OpenSSH i większego udziału komponentów memory-safe. Najważniejsze zadanie na najbliższe tygodnie to nie natychmiastowy upgrade produkcji, ale inwentaryzacja: SysV, cgroup v1, apt-key, własne hooki initramfs, duże użycie /tmp i stare zależności SSH. Kto zrobi to przed migracją, ten potraktuje 26.04 LTS jako uporządkowanie platformy, a nie jako źródło nocnych awarii.
