do-release-upgrade: no new release found - jak naprawić

Dlaczego do-release-upgrade informuje o braku nowej wersji

do-release-upgrade komunikat kończący się No new release found. niemal nigdy nie oznacza awarii narzędzia. Ścieżka, o którą pytasz, jest w danej chwili zamknięta, a narzędzie informuje o tym w najbardziej zwięzły sposób. Pięć czynników powoduje to zamknięcie: ustawienie Prompt w pliku /etc/update-manager/release-upgrades, blokada wydań punktowych przy aktualizacjach LTS (long term support), zewnętrzne repozytoria, pakiety wstrzymane lub częściowo skonfigurowane oraz wydanie, którego okres wsparcia dobiegł końca.

Przeanalizuj je w podanej kolejności. Każdy z tych punktów posiada polecenie weryfikujące, czy dotyczy ono Twojego serwera, dzięki czemu nie musisz zgadywać, z którym z pięciu przypadków masz do czynienia.

Co faktycznie raportuje flaga check-only

sudo do-release-upgrade -c
echo $?

-c to tryb sprawdzania. Odczytuje on metadane wydania Canonical przez HTTPS (hypertext transfer protocol secure) i wyświetla wynik. Nie pobiera żadnego narzędzia do aktualizacji ani nie nadpisuje plików źródłowych. Istotne są dwa rodzaje danych wyjściowych:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Kod wyjścia zawiera tę samą odpowiedź dla skryptów. Wynosi 0, gdy dostępne jest nowe wydanie, oraz 1, gdy go nie ma. Jest to odwrotność standardowej konwencji powłoki, dlatego należy zachować ostrożność przy tworzeniu automatyzacji w oparciu o ten kod.

Jeśli baner logowania nadal wyświetla starą informację, oznacza to, że jest ona w pamięci podręcznej. Ten wiersz pochodzi z /etc/update-motd.d/91-release-upgrade, który wyświetla zapisany wynik zamiast odpytywać sieć. Odśwież go za pomocą sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd lub po prostu zaufaj -c. Baner jedynie powtarza wynik ostatniego wykonanego sprawdzenia.

Sprawdzenie wymaga również połączenia z changelogs.ubuntu.com. Na serwerze za restrykcyjnym firewallem wyjściowym lub proxy narzędzie nie może wysłać zapytania, więc nie znajdzie żadnych informacji.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Wiersz HTTP/2 200 oznacza, że serwer ma dostęp do metadanych. Wiersz curl: (28) Connection timed out oznacza, że przyczyną są reguły ruchu wychodzącego i żadna edycja plików APT (advanced package tool) nie zmieni wyniku.

Jeśli polecenie w ogóle nie istnieje, znajduje się w pakiecie ubuntu-release-upgrader-core. Minimalne obrazy chmurowe czasami pomijają ten pakiet.

sudo apt install ubuntu-release-upgrader-core

Przed wprowadzeniem jakichkolwiek zmian należy przeczytać plik /etc/update-manager/release-upgrades

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Plik zawiera własną dokumentację w komentarzach. Dopuszczalne są trzy wartości:

• never: nigdy nie sprawdzaj dostępności nowej wersji i nie zezwalaj na aktualizację systemu.
• normal: oferuj wspieraną wersję, która bezpośrednio następuje po aktualnie uruchomionej.
• lts: oferuj pierwsze wydanie LTS, które następuje po aktualnie uruchomionej wersji.

Prompt=never jest najłatwiejszą do zdiagnozowania z tych trzech opcji, ponieważ narzędzie w swoim komunikacie wyjściowym wskazuje zarówno plik, jak i ustawienie:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Dostawcy usług hostingowych oraz narzędzia do zarządzania konfiguracją celowo ustawiają never, aby zapobiec rozbieżnościom wersji w zarządzanej infrastrukturze. Jeśli taka wartość występuje, została wybrana świadomie. Należy zmienić ją na lts w przypadku serwera, który ma korzystać ze ścieżki długoterminowego wsparcia (LTS), a następnie przywrócić poprzednią wartość, jeśli automatyzacja tego wymaga.

Jeden szczegół w tych komentarzach często wprowadza w błąd. Gdy ustawione jest Prompt=lts, a aktualnie uruchomiona wersja nie jest wydaniem LTS, narzędzie aktualizujące traktuje to ustawienie jak normal. Na maszynie z wersją 25.10 obie wartości działają identycznie. Na maszynie z wersją 24.04 działają inaczej i ta różnica stanowi treść całej następnej sekcji.

Dlaczego aktualizacja z wersji LTS do LTS czeka na pierwsze wydanie punktowe

Prompt decyduje, który plik metadanych odczytuje narzędzie aktualizujące. Adresy znajdują się w /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts odczytuje meta-release-lts. Prompt=normal odczytuje meta-release. Oba pliki opisują każde wydanie w niewielkim bloku kluczy, a narzędzie aktualizujące oferuje wydanie tylko wtedy, gdy jego flaga Supported: ma wartość 1. Można sprawdzić je samodzielnie, pobierając z tego samego serwera:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Sprawdzone 13 sierpnia 2026 r. pliki różnią się w kwestii Ubuntu 26.04. Plik LTS podaje:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

Plik standardowy podaje:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Wartość Supported: 0 w pliku LTS stanowi blokadę. Serwer 24.04 korzystający z domyślnego Prompt=lts odczytuje ten plik, nie znajduje nowszego wydania LTS oznaczonego jako dostępne i wyświetla No new release found.. Z maszyną wszystko jest w porządku. Canonical po prostu jeszcze nie otworzyło ścieżki aktualizacji.

Flaga zmienia się na 1 w momencie wydania pierwszej wersji punktowej. Ubuntu 26.04.1 zaplanowano na 27 sierpnia 2026 r., a harmonogramy wydań ulegają zmianom, dlatego należy sprawdzać metadane, a nie kalendarz. Opóźnienie jest celowe: użytkownicy aktualizujący system w pierwszej kolejności wykrywają blokujące błędy, które są usuwane przed masową migracją serwerów LTS.

Pozostają dwie uczciwe opcje. Pierwsza to oczekiwanie na wydanie punktowe, co jest właściwym wyborem w przypadku serwera, którego nie chcemy nadzorować. Druga to ustawienie Prompt=normal, co wskazuje to samo narzędzie na meta-release, gdzie 26.04 jest już oznaczone jako wspierane. Druga ścieżka aktualizuje system do wydanego 26.04, a nie do wersji rozwojowej, więc jest dopuszczalna na maszynie, którą można przywrócić ze snapshotu. Po zakończeniu operacji należy przywrócić wartość lts. Procedura krok po kroku znajduje się w pełnym przewodniku aktualizacji serwera z 24.04 do 26.04.

Repozytoria stron trzecich oraz PPA blokujące aktualizację

Narzędzie aktualizujące modyfikuje źródła APT, aby wskazywały na nowe wydanie. Może to zrobić tylko dla repozytorium, które publikuje pakiety dla nowej wersji, dlatego każde inne zostaje zakomentowane. Przyczyny są wypisywane w osobnych liniach dla każdego wpisu i są one konkretne: was disabled (unknown mirror), was disabled (unknown dist) oraz was disabled (no Release file).

Repozytorium PPA (personal package archive) zbudowane dla noble nie posiada katalogu dla resolute na serwerze, więc narzędzie aktualizujące nie może pobrać pliku Release dla nowej serii i wyłącza dany wpis. Zazwyczaj jest to ostrzeżenie, które można zaakceptować. Problem staje się krytyczny, gdy repozytorium strony trzeciej dostarcza pakiet, który znajduje się również w nowym wydaniu, ponieważ mechanizm obliczania aktualizacji otrzymuje wtedy dwa kandydackie pakiety i nie ma możliwości spełnienia obu wymagań.

Należy podjąć decyzję samodzielnie przed rozpoczęciem procesu, zamiast pozwalać narzędziu na decydowanie w trakcie długiej, nieobsługiwanej sesji.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy przy nazwie pakietu wyświetla, z którego repozytorium pochodzi każda zainstalowana wersja, co pozwala dokładnie sprawdzić, które pakiety zależą od źródła, które ma zostać wyłączone. Usunięcie źródła nie powoduje automatycznego przywrócenia starszej wersji pakietu (downgrade), więc pakiet zainstalowany z PPA pozostaje w wersji z PPA i może być nowszy niż ten dostępny w nowym wydaniu systemu. Jeśli ma to znaczenie, należy również usunąć taki pakiet i zainstalować go ponownie z oficjalnego archiwum po zakończeniu aktualizacji. Repozytorium, które planuje się przywrócić, na przykład Tailscale, wymaga aktualizacji nazwy kodowej do nowego wydania, zanim pakiet będzie mógł zostać ponownie zainstalowany; stąd biorą się najczęstsze błędy instalacji Tailscale w Ubuntu.

Istnieje flaga dla przeciwnego wyboru. Strona podręcznika systemowego opisuje --allow-third-party jako "Spróbuj przeprowadzić aktualizację z włączonymi lustrami i repozytoriami stron trzecich zamiast ich komentowania". Należy jej używać tylko po potwierdzeniu, że repozytorium publikuje już pakiety dla docelowego wydania. Jeśli tego nie robi, wymusza się na APT rozwiązanie grafu zależności w oparciu o serię, dla której repozytorium nigdy nie było budowane.

W Ubuntu 24.04 i nowszych większość źródeł znajduje się w /etc/apt/sources.list.d/ubuntu.sources w formacie deb822. To samo repozytorium zapisane w starym i nowym formacie stanowi osobny błąd z własnym komunikatem, omówiony w błędzie zduplikowanego wpisu źródła w formacie deb822.

Wstrzymane i nieskonfigurowane pakiety przerywają obliczenia

Aktualizacja wydania wymaga przeniesienia niemal każdego pakietu w systemie. Jeśli choć jeden pakiet nie może zostać przeniesiony, obliczenia kończą się niepowodzeniem, a instalator przerywa pracę, aby nie pozostawić systemu w stanie pośrednim. Dwa polecenia pozwalają zidentyfikować przyczynę.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold wyświetla wstrzymane pakiety, po jednym w linii; w czystym systemie polecenie nie zwraca żadnych danych. Wstrzymanie (hold) to ręczna instrukcja blokująca zmiany w danym pakiecie. Ktoś mógł przypiąć wersję jądra lub bazy danych i o tym zapomnieć. Odblokuj pakiety, które nie są już potrzebne, za pomocą sudo apt-mark unhold, podając nazwę pakietu.

dpkg --audit wymienia pakiety, które zostały rozpakowane, ale nie zostały skonfigurowane. Taki stan wynika z przerwania instalacji, najczęściej w wyniku zerwania sesji. Instalator podejmuje próbę naprawy i wyświetla dpkg interrupted, calling dpkg --configure -a, jednak samodzielne uruchomienie naprawy pozwala odczytać błąd, zamiast obserwować jego przewijanie na ekranie. Pakiet, którego narzędzie nie może naprawić, generuje komunikat Package in inconsistent state; wymaga on uwagi przed ponowną próbą aktualizacji.

Przed przystąpieniem do aktualizacji wydania doprowadź bieżącą wersję systemu do pełnej aktualności.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Opcja aktualizacji etapowych (phased updates) ma większe znaczenie, niż mogłoby się wydawać. Ubuntu udostępnia niektóre aktualizacje stopniowo, dla określonego odsetka maszyn, więc standardowe apt upgrade może pozostawić część pakietów w starszej wersji, przez co serwer nie będzie tak aktualny, jak zakładasz. Ta opcja wymusza pobranie wszystkich dostępnych aktualizacji. Zrestartuj system, jeśli wśród nich znalazło się jądro, aby aktualizacja odbywała się z poziomu jądra, które jest faktycznie uruchomione. Maszyna, która samodzielnie instaluje automatyczne aktualizacje zabezpieczeń, ma w tym zakresie mniej pracy, jednak mechanizm ten z założenia nigdy nie przekracza granic wydania systemu.

Gdy wydanie utraciło wsparcie techniczne

Wydanie tymczasowe Ubuntu jest wspierane przez dziewięć miesięcy. Po zakończeniu tego okresu flaga Supported: zmienia się na 0, a standardowa ścieżka aktualizacji przestaje oferować przejście do nowszej wersji. Stan na 13 sierpnia 2026 roku, meta-release podaje następujące informacje o wersji 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

W tym samym czasie przenoszone jest archiwum. Pakiety dla wydania, którego cykl życia dobiegł końca, są usuwane z archive.ubuntu.com i przenoszone do old-releases.ubuntu.com. W rezultacie apt update zaczyna zwracać 404 Not Found, system nie może zostać zaktualizowany, a ponieważ proces aktualizacji wymaga aktualnego stanu systemu, operacja zostaje przerwana. Należy najpierw poprawić źródła.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Skieruj zarówno archive.ubuntu.com, jak i security.ubuntu.com na old-releases.ubuntu.com, pozostawiając nazwę kodową bez zmian. Zmienia się wyłącznie nazwa hosta.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Uruchom to samo polecenie względem /etc/apt/sources.list, jeśli serwer nadal przechowuje źródła w tym jednym pliku. Opcja -i.bak tworzy kopię zapasową obok pliku oryginalnego, co pozwala na przywrócenie stanu pierwotnego w razie błędnej edycji. Poprawne wykonanie apt update oznacza, że archiwum jest ponownie dostępne, a do-release-upgrade nawiąże połączenie.

Należy realistycznie ocenić skuteczność tego podejścia. Ubuntu wspiera przejście tylko o jeden krok wydania naraz, więc serwer, który pominął dwa lub trzy wydania, wymaga wykonania każdego kroku po kolei. Każdy z nich może zakończyć się niepowodzeniem z powodu zewnętrznego repozytorium lub zablokowanego pakietu. W przypadku VPS często szybszym rozwiązaniem jest postawienie nowego serwera z aktualnym wydaniem LTS, przeniesienie usług i zachowanie starej instancji do czasu potwierdzenia poprawnego działania. Zapewnia to również możliwość wycofania zmian, czego nie oferuje aktualizacja w miejscu. Jeśli planujesz wybór ścieżki wydawniczej na przyszłość, warto zapoznać się z artykułem różnice między LTS a wydaniami tymczasowymi na serwerze przed podjęciem decyzji.

Co faktycznie robi flaga wydania rozwojowego

-d, lub --devel-release, powoduje, że narzędzie aktualizujące odczytuje meta-release-development zamiast pliku wybranego przez Prompt. Strona podręcznika systemowego opisuje to następująco: „W przypadku korzystania z najnowszego wspieranego wydania, zaktualizuj do wydania rozwojowego”.

Sprawdzono 13 sierpnia 2026 r., najnowszy wpis w tym pliku to nie 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Zatem -d nie dostarcza serwerowi 24.04 wydanej wersji 26.04. Celuje w 26.10, wydanie, które jest wciąż w fazie przygotowań. Starsze porady, aby „po prostu dodać -d”, zostały napisane w okresie przed wydaniem wersji LTS, a ich powielanie obecnie kieruje serwer w miejsce, którego nie zamierzałeś odwiedzić. Przy wciąż obecnym Prompt=lts, flaga zatrzymuje się z własnym komunikatem:

There is no development version of an LTS available.

Dokumentacja serwerowa Ubuntu jasno określa tę flagę: „korzystanie z wydania rozwojowego (lub flagi -d) nie jest zalecane w środowiskach produkcyjnych”. Wydanie rozwojowe zmienia się codziennie i nie posiada gwarancji wsparcia bezpieczeństwa, więc pakiet działający rano może uszkodzić usługę po południu. Używaj go na maszynie wirtualnej przeznaczonej do testów, którą zbudowałeś w celu sprawdzenia własnej konfiguracji. Nie używaj go na serwerze, od którego ktokolwiek jest zależny. Gdy chcesz uzyskać wydaną wersję 26.04 przed otwarciem bramki LTS, właściwą drogą jest Prompt=normal.

Uruchamianie aktualizacji w sposób odporny na zerwanie sesji SSH

Aktualizacja wydania zastępuje większość systemu, w tym openssh-server oraz systemd. Jeśli sesja SSH (secure shell) zostanie przerwana w trakcie pracy openssh-server, proces zostanie zabity, pozostawiając pakiety w stanie rozpakowanym i nieskonfigurowanym, co uniemożliwi kolejną próbę aktualizacji. Zawsze uruchamiaj proces aktualizacji wewnątrz terminalowego multipleksera.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Jeśli połączenie zostanie zerwane, zaloguj się ponownie i wykonaj tmux attach -t upgrade. Aktualizacja działała nadal, ponieważ jest procesem potomnym serwera tmux, a nie sesji SSH. screen -S upgrade oraz screen -r upgrade wykonują to samo zadanie, jeśli preferujesz screen.

Narzędzie aktualizujące posiada własne zabezpieczenie dla użytkowników niekorzystających z multipleksera. Gdy wykryje, że działa w sesji SSH, oferuje uruchomienie drugiego sshd na porcie 1022, dzięki czemu zerwana główna sesja nadal pozostawia drogę dostępu. Decyzja podejmowana jest poprzez analizę procesów nadrzędnych w poszukiwaniu procesu o nazwie sshd. Wewnątrz tmux lub screen analiza ta wskazuje na serwer multipleksera, więc propozycja się nie pojawia, a plik pid /var/run/release-upgrader-sshd.pid jest zapisywany tylko wtedy, gdy dodatkowy demon faktycznie zostanie uruchomiony. Brak tego komunikatu nie oznacza błędu. Korzystasz już z lepszego zabezpieczenia.

Jeśli zaakceptujesz ofertę, port nie zostanie otwarty automatycznie. Narzędzie informuje o tym wprost, ponieważ otwarcie portu jest decyzją dotyczącą bezpieczeństwa, której program nie powinien podejmować za użytkownika. Otwórz port na czas trwania aktualizacji, a następnie zamknij go ponownie.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

Większość dostawców VPS stosuje drugą zaporę sieciową w panelu sterowania, poza systemem operacyjnym. Port 1022 musi być otwarty również tam, w przeciwnym razie zapasowy proces nasłuchujący będzie działał, ale pozostanie nieosiągalny, co jest najgorszym z możliwych scenariuszy.

Przed wpisaniem komendy upewnij się, że spełnione są cztery warunki:

• Wykonaj snapshot lub pełną kopię zapasową. Aktualizacja wydania w miejscu nie posiada funkcji cofania zmian i jest to jedyna szansa na odzyskanie danych.
• Potwierdź, że masz dostęp do konsoli dostawcy, zanim będzie ona potrzebna. Jeśli serwer nie uruchomi się po restarcie, dostęp przez SSH będzie niemożliwy. Jądro, które nie startuje, to osobny problem z własnymi krokami naprawczymi, opisanymi w VPS, który nie uruchamia się po aktualizacji jądra.
• Sprawdź wolne miejsce za pomocą df -h / /boot. Aktualizacja pobiera pełny zestaw pakietów, a partycja /boot zawierająca kilka starych jąder jest częstym miejscem zatrzymania procesu.
• Przeczytaj informacje o wydaniu dla usług, które uruchamiasz. Duży skok wersji w PostgreSQL lub PHP nastąpi wraz z aktualizacją, niezależnie od tego, czy został zaplanowany.

FAQ

Dlaczego do-release-upgrade informuje o braku nowej wersji na Ubuntu 24.04?

Domyślny wpis Prompt=lts w pliku /etc/update-manager/release-upgrades powoduje, że narzędzie odczytuje https://changelogs.ubuntu.com/meta-release-lts, a Ubuntu 26.04 zawiera Supported: 0 w tym pliku aż do pierwszego wydania punktowego. Program aktualizujący nie znajduje nowszego wydania LTS oznaczonego jako dostępne, więc przerywa działanie. Sprawdź plik samodzielnie za pomocą curl -s https://changelogs.ubuntu.com/meta-release-lts i przeczytaj ostatni blok. Stan na 13 sierpnia 2026 roku wskazywał, że flaga nadal miała wartość 0, a wydanie Ubuntu 26.04.1 zaplanowano na 27 sierpnia 2026 roku.

Czy ustawienie Prompt=normal jest bezpieczne zamiast czekania na wydanie punktowe?

Powoduje to aktualizację do wydanego Ubuntu 26.04, a nie do wersji rozwojowej, ponieważ Prompt=normal odczytuje meta-release, gdzie 26.04 ma już ustawione Supported: 1. Ryzykiem jest czas. Przeprowadzasz aktualizację, zanim błędy zgłoszone przez pierwszych użytkowników zostaną naprawione. Wykonaj to na serwerze, z którego możesz przywrócić snapshot i do którego masz dostęp przez konsolę dostawcy w razie problemów po restarcie. Po zakończeniu przywróć wartość lts.

Czy flaga -d aktualizuje system do 26.04?

Nie. -d odczytuje meta-release-development, którego najnowszy wpis w dniu 13 sierpnia 2026 roku wskazywał na Ubuntu 26.10, czyli wydanie w fazie rozwoju. Na maszynie LTS z ustawieniem Prompt=lts flaga wyświetla There is no development version of an LTS available. i kończy pracę. Dokumentacja serwerowa Ubuntu odradza stosowanie wersji rozwojowych w środowiskach produkcyjnych, dlatego użyj Prompt=normal, jeśli chcesz zainstalować wydane Ubuntu 26.04 wcześniej.

Polecenie apt update zwraca błędy 404 dla starej wersji. Jak ją zaktualizować?

Wsparcie dla tej wersji wygasło, więc pakiety zostały przeniesione z archive.ubuntu.com do old-releases.ubuntu.com. Zmień jedynie nazwy hostów w /etc/apt/sources.list.d/ubuntu.sources lub w /etc/apt/sources.list w starszych układach plików, zachowując nazwę kodową systemu bez zmian. Następnie uruchom sudo apt update oraz sudo apt full-upgrade. Gdy system będzie aktualny, do-release-upgrade pozwoli na przejście do kolejnej wersji.

Czy muszę usuwać PPA przed uruchomieniem do-release-upgrade?

Nie jest to konieczne, ponieważ program aktualizujący komentuje każde źródło, które nie publikuje pakietów dla nowej wersji, i wyświetla komunikat typu was disabled (no Release file) dla każdego z nich. Lepiej jednak zrobić to samodzielnie, aby zachować kontrolę nad kolejnością i widzieć wynik operacji. Uruchom apt policy dla interesujących Cię pakietów, aby sprawdzić, które pochodzą z danego PPA, a następnie zainstaluj je ponownie z oficjalnego archiwum, jeśli wersja z PPA jest nowsza niż ta dostępna w nowym wydaniu systemu.