GRUB krok po kroku - BIOS, UEFI i typowe problemy z rozruchem

Start komputera to krótki, ale bardzo ważny etap: zanim zobaczysz pulpit, firmware musi przekazać sterowanie bootloaderowi, a ten wybrać właściwe jądro systemu. GRUB stoi właśnie w tym miejscu i dlatego tak często pojawia się przy instalacji Linuxa, konfiguracji dual boot oraz naprawie problemów z rozruchem. Poniżej rozbieram ten mechanizm na części, pokazuję różnice między BIOS i UEFI oraz wyjaśniam, jak nie wpaść w typowe pułapki konfiguracyjne.

Czym jest GRUB i gdzie kończy się jego rola

GRUB to bootloader, czyli program startowy, który działa tuż po firmware i zanim kontrolę przejmie system operacyjny. Dokumentacja GNU GRUB opisuje go wprost jako pierwszy program uruchamiany po starcie komputera. W praktyce robi trzy rzeczy: znajduje właściwy system, ładuje jądro wraz z niezbędnymi parametrami i przekazuje sterowanie dalej.

Ja traktuję go jako warstwę pośrednią między sprzętem a systemem. Nie jest ani systemem operacyjnym, ani sterownikiem, ani menedżerem okien. To krótki, ale krytyczny etap, który decyduje, czy komputer wystartuje do Linuxa, Windowsa, trybu ratunkowego czy konkretnej wersji jądra. Dzięki temu GRUB jest szczególnie ważny tam, gdzie jeden komputer ma obsługiwać więcej niż jeden system albo więcej niż jedną konfigurację startową.

Warto też rozróżnić dwa pojęcia: bootloader i chainloading. Chainloading to przekazanie startu innemu loaderowi zamiast bezpośredniego uruchamiania jądra. Właśnie dlatego GRUB potrafi uruchamiać nie tylko Linux, ale też inne systemy, jeśli konfiguracja jest poprawna. Kiedy to uporządkujemy, łatwiej zobaczyć, co dokładnie dzieje się w pierwszych sekundach po włączeniu komputera.

Jak wygląda łańcuch startowy od firmware do jądra

Najprościej patrzeć na start komputera jak na łańcuch decyzji. Najpierw firmware inicjuje sprzęt, potem wybiera wpis startowy, a następnie przekazuje sterowanie bootloaderowi. Dopiero GRUB decyduje, co dokładnie zostanie uruchomione dalej.

1. Firmware wykrywa podstawowy sprzęt i sprawdza dostępne nośniki startowe.
2. GRUB ładuje własne moduły oraz konfigurację z dysku.
3. Na ekranie pojawia się menu albo uruchamia się domyślny wpis.
4. Bootloader ładuje jądro systemu oraz initramfs, czyli tymczasowy zestaw plików potrzebnych do startu.
5. Kernel przejmuje sterowanie i uruchamia resztę systemu.

W tym miejscu najłatwiej zrozumieć, dlaczego czasem wszystko psuje się po drobnej zmianie, na przykład po aktualizacji innego systemu albo po podłączeniu nowego dysku. GRUB nie działa w próżni: zależy od tego, jak firmware widzi nośniki i które pliki konfiguracyjne są aktualne. To naturalnie prowadzi do różnicy między BIOS i UEFI.

BIOS i UEFI wpływają na instalację i naprawę

Najczęstszy błąd, jaki widzę, to mieszanie trybów: system zainstalowany w UEFI, a naprawa wykonywana tak, jakby komputer działał w BIOS. Efekt bywa mylący, bo sam GRUB może być poprawny, ale firmware szuka go w innym miejscu niż powinien.

W praktyce różnica nie polega na tym, że GRUB działa tylko w jednym modelu. On po prostu osadza się inaczej. Na BIOS-ie częściej walczysz z rekordem startowym dysku, a na UEFI z wpisem firmware i dostępnością partycji EFI. Gdy to rozumiesz, dużo łatwiej dobrać właściwą metodę instalacji i naprawy.

To właśnie dlatego przy problemach z rozruchem zawsze zaczynam od jednego pytania: w jakim trybie komputer był uruchamiany podczas instalacji systemu? Od odpowiedzi zależy cały następny krok.

Jak konfiguruje się GRUB bez ręcznej edycji plików generowanych automatycznie

Ja zaczynam każdą zmianę od /etc/default/grub, bo tam trzyma się podstawowe ustawienia: czas wyświetlania menu, domyślny wpis, parametry jądra i zachowanie ekranu startowego. Dokumentacja Ubuntu zwraca uwagę, że grub.cfg jest wynikiem działania skryptów, więc nie powinno się go traktować jak pliku roboczego do ręcznych poprawek. To ważne, bo ręczna edycja działa tylko do następnej aktualizacji.

Na Debianie i Ubuntu najczęściej kończy się to poleceniem update-grub, a w innych dystrybucjach zwykle odpowiednikiem opartym o grub-mkconfig. Jeśli chcesz dodać własny wpis, robię to w skryptach pod /etc/grub.d/, a nie przez grzebanie w gotowym pliku. To prosty schemat, ale naprawdę rzadko zawodzi, jeśli trzymasz się kolejności.

1. Zmieniam /etc/default/grub.
2. Dodaję własny wpis tylko wtedy, gdy standardowe wykrywanie nie wystarcza.
3. Odświeżam konfigurację menu.
4. Jeśli zmienił się dysk lub tryb firmware, ponownie instaluję bootloader na właściwym urządzeniu.

Gdy ten porządek jest zachowany, konfiguracja pozostaje przewidywalna. A właśnie brak przewidywalności jest najczęstszą przyczyną problemów, które później wyglądają jak poważna awaria.

Najczęstsze problemy, które widzę w praktyce

Jeśli ktoś mówi mi, że „GRUB nie działa”, zwykle po chwili okazuje się, że problem leży gdzie indziej: w trybie startu, w kolejności bootowania albo w nadpisanej konfiguracji. Sam bootloader rzadko psuje się bez powodu. Dużo częściej dostaje sprzeczne informacje z firmware albo z systemu, który właśnie został zaktualizowany.

Menu znika albo system startuje za szybko

To zwykle kwestia timeoutu albo ukrytego menu. Czasem wpis domyślny uruchamia się tak szybko, że użytkownik nawet nie widzi możliwości wyboru. W praktyce sprawdzam wtedy ustawienia czasu oczekiwania i zachowanie menu, a na niektórych komputerach testuję też klawisze Shift lub Esc podczas startu.

Drugi system nie pojawia się na liście

Tu najpierw patrzę na zgodność trybu firmware. Jeśli jeden system był instalowany w UEFI, a drugi w legacy, automatyczne wykrywanie potrafi nie złożyć pełnego obrazu. Potem odświeżam konfigurację i sprawdzam, czy dystrybucja nie wymaga dodatkowego kroku do wykrycia innych systemów. W dual boot to jeden z tych momentów, w których porządek instalacji ma większe znaczenie niż sama marka systemu.

Przeczytaj również: Kod ASCII - Zrozum standard i uniknij pułapek z tekstem

Start kończy się rescue mode albo czarnym ekranem

W takich przypadkach nie zakładam od razu najgorszego. Najpierw sprawdzam, czy bootloader widzi właściwą partycję i czy pliki jądra są w miejscu, którego oczekuje konfiguracja. Jeśli problem pojawia się po zmianie dysku, aktualizacji firmware albo przeniesieniu systemu, zwykle pomaga uruchomienie komputera z nośnika ratunkowego, ponowne zamontowanie systemu i wykonanie instalacji GRUB od nowa.

Ja w takiej sytuacji nie zaczynam od reinstalacji całego systemu, bo to najczęściej przesada. Najpierw weryfikuję trzy rzeczy: tryb startu, aktywny dysk i to, czy partycja EFI albo obszar startowy naprawdę zawiera to, czego oczekuje firmware. Dopiero potem sięgam po mocniejsze narzędzia.

Co sprawdzam, zanim ruszę start systemu

Jeśli miałbym wskazać jedną praktyczną zasadę, byłaby prosta: przed zmianą dysku, instalacją drugiego systemu albo aktualizacją bootloadera trzeba wiedzieć, co jest źródłem konfiguracji, a co tylko jej wygenerowanym wynikiem. To oszczędza mnóstwo czasu, zwłaszcza na laptopach z jednym albo dwoma SSD, gdzie jedna pomyłka wystarczy, by firmware przestał trafiać w poprawny wpis.

• Sprawdzam, czy komputer startuje w BIOS czy UEFI.
• Notuję, na którym dysku i w której partycji leży bootloader.
• Robię kopię /etc/default/grub oraz własnych wpisów menu.
• Trzymam pod ręką nośnik ratunkowy, jeśli eksperymentuję z partycjami.
• Ustalam, który system ma zarządzać menu, jeśli działam w dual boot.

GRUB daje dużą kontrolę, ale oczekuje porządku: spójnego trybu startu, poprawnie wskazanego dysku i świadomości, które pliki są źródłem konfiguracji, a które tylko jej efektem. Jeśli potraktujesz go jak element infrastruktury startowej, a nie jednorazowy dodatek do instalatora, większość problemów zniknie jeszcze zanim przerodzą się w awarię.