GRUB to warstwa, która decyduje, co uruchomi się jako pierwsze po włączeniu komputera: pojedynczy kernel, starszy wpis ratunkowy, Windows w dual boot albo specjalny tryb odzyskiwania. W dystrybucjach Linux ma znaczenie większe, niż się wydaje, bo od niego zależą nie tylko ekran startowy i menu, ale też sposób aktualizacji jądra, praca z UEFI oraz szybkie odzyskanie systemu po błędzie. Poniżej rozkładam temat na konkretne kroki i pokazuję, co naprawdę warto umieć.
Najważniejsze rzeczy o GRUB-ie, które warto mieć pod ręką
- GRUB jest bootloaderem - ładuje kernel i initramfs, a potem przekazuje sterowanie właściwemu systemowi.
- Na BIOS działa inaczej niż na UEFI: w BIOS ważny jest dysk i MBR, a w UEFI plik EFI na partycji ESP.
-
grub-installinstaluje bootloader, agrub-mkconfiggeneruje menu i wpisy startowe. - Najbezpieczniej zmieniać
/etc/default/grub, a nie ręcznie edytować wygenerowanygrub.cfg. - Przy awarii startu najpierw sprawdza się tryb rescue, potem reinstalację GRUB-a z live USB.
- Secure Boot, szyfrowany
/booti kilka dysków zwiększają złożoność, ale da się to utrzymać, jeśli konfiguracja jest spójna.
Jak GRUB wchodzi do gry podczas startu komputera
Najprościej patrzę na GRUB jak na tłumacza między firmware komputera a właściwym systemem operacyjnym. Firmware - BIOS albo UEFI - uruchamia pierwszy etap, GRUB pokazuje menu i wybiera wpis, a potem ładuje kernel oraz initramfs, czyli minimalny obraz systemu potrzebny do startu właściwej instalacji. To właśnie dlatego GRUB jest tak ważny w dystrybucjach Linux: bez niego nie ma wygodnego wyboru systemu, fallbacku ani sensownego dual boot.
Różnica między BIOS a UEFI jest praktyczna, nie teoretyczna. W BIOS-ie bootloader jest związany z dyskiem i jego wczesnym obszarem rozruchowym, a w UEFI działa jako plik EFI zapisany na partycji ESP. Ja zwykle upraszczam to do jednego zdania: w BIOS pilnujesz dysku, w UEFI pilnujesz partycji EFI i wpisu w firmware.
| Cecha | BIOS | UEFI |
|---|---|---|
| Gdzie trafia GRUB | Na dysk, w obszar rozruchowy i core image | Do pliku EFI na partycji ESP |
| Typowa instalacja | grub-install /dev/sdX |
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB |
| Najczęstszy błąd | Instalacja na partycji zamiast na całym dysku | Zły punkt montowania ESP albo brak wpisu w firmware |
| Co sprawdzić po zmianach | Kolejność dysków i poprawny nośnik startowy | Podpisy, wpis w Boot Managerze i montowanie ESP |
To wyjaśnia, dlaczego ten sam problem może wyglądać zupełnie inaczej na dwóch komputerach. Skoro sam mechanizm jest jasny, warto zobaczyć, jak różne dystrybucje Linux podchodzą do niego w praktyce.
Dlaczego dystrybucje Linux traktują GRUB-a inaczej
Tu widać największą różnicę między rodzinami dystrybucji. Jedne próbują jak najwięcej ukryć przed użytkownikiem i generują konfigurację automatycznie, inne stawiają na ręczną kontrolę. Z mojego doświadczenia wynika, że największy błąd popełniają osoby, które zakładają, że wszędzie GRUB działa identycznie. Nie działa - i właśnie dlatego warto znać układ swojej dystrybucji.
| Rodzina dystrybucji | Jak to zwykle wygląda | Co to oznacza w praktyce |
|---|---|---|
| Debian, Ubuntu i pochodne | Dużo rzeczy jest generowanych skryptami i aktualizowanych po zmianach kernela | Edytujesz źródła konfiguracji, a potem odświeżasz menu, zamiast poprawiać gotowy plik |
| Arch i systemy minimalistyczne | Więcej decyzji podejmujesz sam, od instalacji po regenerację menu | Masz pełną kontrolę, ale też pełną odpowiedzialność za każdy etap rozruchu |
| Fedora, openSUSE i podobne | Większy nacisk na integrację z polityką aktualizacji kernela, UEFI i podpisów | Boot chain trzeba traktować jak część zarządzaną przez system, a nie jako jednorazową instalację |
Najbardziej praktyczna zasada jest prosta: nie edytuję ręcznie wygenerowanego grub.cfg, jeśli nie muszę. W większości dystrybucji to plik wynikowy, który i tak zostanie nadpisany przy kolejnym odświeżeniu. Zmiany robi się w /etc/default/grub, w skryptach lub w dedykowanych fragmentach konfiguracyjnych, a potem dopiero generuje finalne menu.
To prowadzi do najważniejszego pytania użytkownika: co konkretnie ustawić, żeby GRUB był wygodny na co dzień, a nie tylko poprawny technicznie.
Jak ustawić menu, domyślny system i czas oczekiwania
W codziennym użyciu liczą się cztery rzeczy: który wpis startuje domyślnie, jak długo menu czeka na wybór, czy menu w ogóle ma być widoczne oraz jakie parametry dostaje kernel. W praktyce to właśnie te ustawienia decydują o tym, czy komputer jest przyjazny w dual boot, czy zamienia się w źródło frustracji po każdej aktualizacji.
| Ustawienie | Co robi | Rozsądny punkt wyjścia |
|---|---|---|
GRUB_DEFAULT |
Wybiera domyślny wpis menu |
0 dla prostych instalacji, saved albo konkretne ID, gdy często przełączasz systemy |
GRUB_TIMEOUT |
Określa czas oczekiwania przed automatycznym startem | 3-5 sekund na komputerze osobistym, 5-10 sekund przy dual boot lub testach |
GRUB_TIMEOUT_STYLE |
Decyduje, czy menu ma być widoczne, czy ukryte |
menu, jeśli chcesz mieć awaryjny wybór bez zgadywania skrótów klawiszowych |
GRUB_CMDLINE_LINUX_DEFAULT |
Dodaje parametry do kernela | Typowo quiet splash, a do diagnozy chwilowo nomodeset albo usunięcie tych flag |
| Własne wpisy | Dodają niestandardowe pozycje menu | Lepsze w /etc/grub.d/40_custom lub w osobnym pliku niż w finalnym grub.cfg
|
Po każdej zmianie robię dwie rzeczy: zapisuję konfigurację źródłową i generuję nowe menu. Standardowy rytm wygląda tak: edycja /etc/default/grub, potem grub-mkconfig -o /boot/grub/grub.cfg. Jeśli dystrybucja daje własny wrapper, można go użyć, ale logika pozostaje ta sama - zmieniasz źródło, a nie wynik.
Przy systemach wielobootowych polecam jeszcze jedną rzecz: zostawić menu widoczne choćby przez kilka sekund. Ukryte menu ma sens tylko wtedy, gdy naprawdę nie potrzebujesz awaryjnego wyboru. W praktyce 3-5 sekund zwykle wystarcza, a nie kosztuje nic poza odrobiną wygody.
Skoro ustawienia są już jasne, czas przejść do sytuacji, której każdy wolałby uniknąć: komputer staje na ekranie GRUB-a albo wpada w rescue shell.
Co zrobić, gdy komputer zatrzymuje się na GRUB-ie
Najczęstsze awarie nie oznaczają, że system zniknął. Zwykle coś rozjechało się po zmianie partycji, aktualizacji kernela, wymianie dysku albo po włączeniu Secure Boot bez pełnego przygotowania. Ja zaczynam zawsze od rozpoznania objawu, bo to oszczędza czas: inny scenariusz ratuje się z menu, inny z rescue shell, a jeszcze inny wymaga live USB.
| Objaw | Prawdopodobna przyczyna | Co robię najpierw |
|---|---|---|
grub> lub grub rescue>
|
Zły prefix, brak modułu normal albo źle widziana partycja |
Sprawdzam set i ls, ustawiam poprawny root oraz prefix, potem ładuję normal
|
| Menu jest, ale system nie startuje | Problem z parametrami kernela, initramfs albo sterownikiem grafiki | Edytuję wpis klawiszem e i testowo usuwam quiet splash lub dodaję nomodeset
|
| Nie widać drugiego systemu | Nie odświeżono konfiguracji albo wykrywanie innych systemów jest ograniczone | Regeneruję menu i sprawdzam, czy wpisy zostały wygenerowane z aktualnych danych |
| Po zmianie dysku nic nie bootuje | GRUB trafił na zły nośnik albo firmware bootuje inną kolejność | Reinstaluję bootloader na właściwym dysku i weryfikuję wpis UEFI lub boot order |
Jeśli system wpada w rescue shell, zwykle robię to w tej kolejności: najpierw ls, potem ustawienie root i prefix, następnie insmod normal i normal. Przykładowy układ może wyglądać tak: set prefix=(hd0,1)/boot/grub oraz set root=(hd0,1), ale ścieżka zależy od tego, jak dystrybucja ułożyła partycje. To rozwiązanie jest tymczasowe - pozwala wejść do systemu, ale nie zastępuje naprawy instalacji.
Prawdziwa naprawa zwykle wymaga live USB i ponownej instalacji bootloadera. Na UEFI korzystam z grub-install wskazującego właściwy katalog EFI, a na BIOS z instalacji na cały dysk, nie na partycję. Po tym zawsze odświeżam konfigurację poleceniem grub-mkconfig -o /boot/grub/grub.cfg. To ważne, bo bez nowego pliku menu system może nadal startować w stary układ albo w ogóle nie znaleźć kernela.
Gdy w tle dochodzą szyfrowanie, Secure Boot albo kilka dysków, problem staje się bardziej złożony, ale nadal przewidywalny, jeśli rozumie się ograniczenia.
Secure Boot, szyfrowanie i inne przypadki, które komplikują start
W prostych instalacjach GRUB jest niemal niewidoczny. W bardziej złożonych środowiskach zaczyna jednak pracować razem z dodatkowymi warstwami: Secure Boot, LUKS, LVM, RAID czy wieloma dyskami. To działa, ale każda z tych warstw dokłada kolejny punkt, który może pęknąć po aktualizacji albo zmianie sprzętu. Ja traktuję to bardzo praktycznie: im bardziej skomplikowany start, tym większa potrzeba testów po każdej większej zmianie.
Secure Boot
Secure Boot wymaga podpisanego łańcucha startowego. Sama obecność GRUB-a nie wystarczy, jeśli firmware nie ufa jego binariom albo modułom. W wielu dystrybucjach pośrednikiem jest shim, czyli mały podpisany loader, który pomaga uruchomić dalszą część łańcucha. Jeśli włączasz Secure Boot po fakcie, sprawdź nie tylko bootloader, ale też podpisy kernela i ewentualnych modułów, których używa twoja konfiguracja.
Szyfrowany /boot i LUKS
Szyfrowanie zwiększa bezpieczeństwo, ale podnosi próg złożoności. GRUB potrafi czytać wiele układów, jednak przy szyfrowanym /boot trzeba być pewnym, że dana konfiguracja jest wspierana przez twoją dystrybucję i obecny zestaw modułów. Jeśli nie masz wyraźnego powodu, aby szyfrować samą partycję rozruchową, prostszy układ jest zwykle stabilniejszy. To nie jest konserwatyzm dla zasady - po prostu mniej warstw to mniej miejsc, gdzie coś może się rozjechać po aktualizacji.
Przeczytaj również: ALT Linux - Czy to dobra alternatywa dla Ubuntu? Poznaj edycje
LVM, RAID i kilka dysków
GRUB obsługuje złożone układy, ale z punktu widzenia niezawodności liczy się jedno: czy bootloader nadal widzi pliki, których potrzebuje, zanim system przejmie kontrolę. Przy LVM i RAID najważniejsze są poprawne moduły, czytelne identyfikatory dysków i brak zgadywania z typu /dev/sdX. Ja wolę opierać się na UUID albo etykietach, bo kolejność dysków potrafi się zmienić szybciej, niż człowiek zdąży zauważyć. Jeśli dołożysz nowy nośnik, przeniesiesz partycję albo zmienisz układ macierzy, dobrze jest od razu odświeżyć konfigurację i przetestować start.
To prowadzi do prostego, ale bardzo skutecznego nawyku: kilka minut porządków po zmianie systemu oszczędza godziny walki z awarią.
Co warto sprawdzić, zanim będziesz musiał ratować start systemu
- Miej zapisane, gdzie montuje się partycja EFI w twojej dystrybucji:
/boot/efialbo inny punkt montowania. - Po instalacji nowego kernela albo zmianie parametrów startowych zawsze generuj nową konfigurację GRUB-a.
- Jeśli masz kilka systemów, zostaw menu widoczne przynajmniej przez kilka sekund zamiast ukrywać je całkowicie.
- Nie edytuj ręcznie wygenerowanego
grub.cfg, jeśli nie jest to absolutnie konieczne. - Po włączeniu Secure Boot wykonaj pełny test restartu, zanim uznasz konfigurację za zakończoną.
- Trzymaj pod ręką live USB i jeden znany, stabilny kernel, jeśli dystrybucja pozwala łatwo utrzymać więcej niż jedną wersję.
Ja traktuję GRUB jak element infrastruktury, nie jak ozdobę ekranu startowego. Kiedy jest dobrze ustawiony, po prostu działa i nie zwraca na siebie uwagi; kiedy jest zaniedbany, potrafi zatrzymać cały komputer na pierwszym kroku. Jeśli pilnujesz źródłowych plików konfiguracji, używasz właściwych narzędzi do instalacji i odświeżasz menu po każdej większej zmianie, bootloader przestaje być źródłem stresu, a staje się przewidywalnym elementem startu systemu.
