Po aktualizacji komputer zatrzymuje się na czarnym ekranie, pokazuje menu GRUB albo przechodzi do trybu awaryjnego zamiast pulpitu. Te objawy wyglądają podobnie z perspektywy użytkownika, lecz dotyczą różnych etapów uruchamiania. Naprawa bootloadera nie pomoże przy niedziałającym sterowniku grafiki, a reinstalacja sterownika nie rozwiąże problemu z odnalezieniem partycji systemowej.
Najpierw zapisz ostatni komunikat i sprawdź, do którego miejsca komputer dochodzi. Jeżeli masz drugi system, pozostaw jego ustawienia bez zmian. Nie formatuj partycji i nie uruchamiaj instalatora z opcją zastąpienia obecnej instalacji. Poniższe kroki służą rozpoznaniu usterki; polecenia dotyczące pakietów wyraźnie rozdzielają Ubuntu i Debiana od innych dystrybucji.
Czy pojawia się menu wyboru systemu?
Gdy widzisz normalne menu GRUB z nazwą dystrybucji i wersjami kernela, firmware znalazł bootloader, a ten potrafił odczytać przynajmniej swoją konfigurację. W takim przypadku zacznij od wyboru wcześniejszego kernela, zamiast ponownie instalować GRUB. W Ubuntu starsze wersje zwykle znajdują się w podmenu Opcje zaawansowane. W innych dystrybucjach mogą być widoczne bezpośrednio na liście.
Wybierz starszą wersję, która działała przed aktualizacją. Nie usuwaj jeszcze nowej ani poprzedniej. Jeśli system uruchomi się poprawnie, masz użyteczny punkt odniesienia: sprzęt i przynajmniej część instalacji działają. Problem może dotyczyć nowego kernela, modułu sterownika lub obrazu initramfs przygotowanego podczas aktualizacji.
Po zalogowaniu odczytaj uruchomioną wersję poleceniem uname -r i zapisz wynik. Nie traktuj poprzedniego kernela jako stałego rozwiązania bez dalszego sprawdzenia. Pozwala odzyskać dostęp do systemu i danych, ale aktualizacje bezpieczeństwa oraz zgodność modułów nadal wymagają uporządkowania.
Jeżeli zamiast menu widzisz grub rescue> albo komunikat o braku urządzenia startowego, to inna sytuacja. Sprawdź w UEFI, czy dysk jest wykrywany i czy właściwy wpis systemu jest na liście startowej. Nie przełączaj losowo między UEFI a trybem Legacy: instalacja przygotowana w jednym trybie nie musi uruchomić się w drugim.
Czarny ekran po rozpoczęciu startu nie zawsze oznacza brak działającego systemu
Jeśli po wybraniu systemu ekran gaśnie, spróbuj otworzyć konsolę tekstową skrótem Ctrl + Alt + F3. W niektórych konfiguracjach używany jest inny klawisz funkcyjny lub trzeba dodatkowo nacisnąć Fn. Pojawienie się tekstowego logowania oznacza, że system uruchomił się przynajmniej do tego etapu. Poszukiwania można wtedy skierować na środowisko graficzne, menedżera logowania i sterownik.
Zaloguj się na swoje konto. Podczas wpisywania hasła terminal może nie wyświetlać żadnych znaków — to normalne. W systemie korzystającym z systemd sprawdź:
systemctl --failed
systemctl status display-managerPierwsze polecenie pokazuje jednostki, które zakończyły się niepowodzeniem. Drugie sprawdza menedżer logowania, jeśli dystrybucja udostępnia go pod tą nazwą. Brak takiej jednostki nie jest sam w sobie dowodem awarii. Zanotuj nazwę rzeczywiście używanego menedżera, na przykład GDM, SDDM lub LightDM, i odczytaj jego komunikaty. Pomocna jest instrukcja sprawdzania usług systemd.
Jeśli kłopot pojawił się po aktualizacji kernela i dotyczy komputera z dodatkowym sterownikiem graficznym, sprawdź zgodność modułu z nową wersją. Błąd budowania modułu lub weryfikacji jego podpisu wymaga innej naprawy niż uszkodzone ustawienia pulpitu. Nie wyłączaj Secure Boot tylko dlatego, że znalazłeś taką poradę: najpierw ustal, czy log faktycznie wskazuje problem z podpisem.
Odczytaj log z właściwej próby uruchomienia
Po wejściu przez wcześniejszy kernel lub konsolę tekstową można sprawdzić dziennik systemu. W dystrybucji z systemd rozpocznij od listy zarejestrowanych uruchomień:
sudo journalctl --list-bootsLista pozwala powiązać indeks uruchomienia z datą i godziną. Nie zakładaj, że poprzedni zapis dotyczy nieudanego startu — po kilku restartach może przedstawiać inną próbę. Dla poprzedniego uruchomienia użyjesz na przykład:
sudo journalctl -b -1 -p warning --no-pagerOpcja -b -1 wybiera poprzedni zapisany start, a -p warning ogranicza wynik do ostrzeżeń i poważniejszych komunikatów. Jeżeli logów z wcześniejszych uruchomień nie ma, system mógł nie zapisywać ich trwale lub nie zdążył wykonać zapisu przed awarią. Brak wpisu nie dowodzi braku błędu. Szersze wykorzystanie dziennika opisuje poradnik czytania logów przez journalctl.
Brak miejsca może przerwać przygotowanie nowego systemu do startu
Aktualizacja kernela obejmuje nie tylko pobranie pakietu. System przygotowuje także pliki potrzebne do uruchomienia. Jeśli zabrakło miejsca w /boot lub na głównej partycji, proces może zakończyć się błędem. Sprawdź zajętość systemów plików:
df -h
df -iPierwsze polecenie pokazuje wykorzystanie przestrzeni, drugie wykorzystanie inode, których brak również może uniemożliwić tworzenie plików. Odczytaj wiersze dotyczące partycji systemowej i ewentualnego osobnego /boot. Nie kasuj ręcznie plików kernela ani losowych katalogów systemowych, żeby szybko uzyskać wolne miejsce. Można w ten sposób usunąć jedyną wersję, która jeszcze startuje.
Jeżeli potrzebujesz ustalić, który katalog urósł, skorzystaj z instrukcji sprawdzania zajętości dysku w Linux. Sprzątanie wykonuj według reguł właściwych dla dystrybucji, zachowując działający kernel.
Przerwana aktualizacja w Ubuntu lub Debianie
W klasycznej instalacji Ubuntu albo Debiana, która korzysta z APT i dpkg, aktualizacja może pozostawić rozpakowane, ale nieskonfigurowane pakiety. Dopiero po sprawdzeniu wolnego miejsca i odzyskaniu działającego środowiska można spróbować dokończyć konfigurację:
sudo dpkg --configure -aOdczytaj wynik. Jeśli pojawią się problemy z zależnościami, następnym krokiem bywa sudo apt --fix-broken install. Przed zatwierdzeniem sprawdź proponowane zmiany. Gdy narzędzie chce usunąć dużą część środowiska graficznego, kernela lub innych kluczowych składników, przerwij i wyjaśnij przyczynę. Te polecenia modyfikują system, więc nie służą do bezrefleksyjnego uruchamiania w każdej sytuacji.
Nie stosuj ich w Fedorze, Arch Linux ani w systemach korzystających z innego modelu aktualizacji. Instalacje niezmienne lub zarządzające całymi obrazami systemu mogą wymagać powrotu do poprzedniego wdrożenia zamiast naprawy pojedynczych pakietów. Przed wykonaniem naprawy sprawdź, którego modelu używa Twoja instalacja.
Gdy żaden z dostępnych wpisów nie uruchamia systemu
Uruchom komputer z nośnika instalacyjnego odpowiedniej dystrybucji, wybierając środowisko do wypróbowania lub ratunkowe. Zacznij od zabezpieczenia ważnych danych. W przypadku szyfrowania potrzebne będzie hasło lub klucz do odblokowania nośnika. Następnie sprawdź układ dysków i partycji; nazwy urządzeń różnią się między komputerami, dlatego nie kopiuj poleceń odwołujących się do cudzego /dev/sda.
Naprawę bootloadera, initramfs albo systemu plików dobierz do faktycznej usterki oraz trybu UEFI/BIOS. Sprawdzanie i naprawianie systemu plików ma inne wymagania niż zwykły odczyt dokumentów z nośnika. Jeśli log wskazuje błędy wejścia/wyjścia lub dysk znika, dalsze próby zapisu mogą utrudnić odzyskanie danych. W takiej sytuacji pierwszeństwo ma kopia, a dopiero po niej naprawa instalacji.
Przy zgłaszaniu problemu podaj dystrybucję i jej wersję, dokładny komunikat, informację o działaniu starszego kernela oraz ostatnie aktualizowane pakiety. Zdjęcie końcowego komunikatu i wynik konkretnego testu są bardziej użyteczne niż opis „Linux po aktualizacji ma czarny ekran”.
