Od BIOSu do UEFI: krótka historia startu systemu, który mało kto rozumie

0
10
Rate this post

Nawigacja:

Decyzja startowa: co tak naprawdę wybierasz przy „Legacy vs UEFI”

Instalujesz system, widzisz w ustawieniach płyty głównej „Legacy / CSM / UEFI” i pojawia się konkretne pytanie: co wybrać, żeby zadziałało od razu i nie marnować wieczoru na kombinacje?

Żeby odpowiedzieć rozsądnie, wystarczy prosty model: od włączenia komputera dzieją się cztery rzeczy w stałej kolejności:

  • Sprzęt dostaje zasilanie i wykonuje podstawowe testy.
  • Firmware (BIOS lub UEFI) inicjalizuje podzespoły i szuka nośnika startowego.
  • Bootloader (np. Windows Boot Manager, GRUB) ładuje system.
  • System operacyjny (Windows, Linux itd.) przejmuje kontrolę.

Twój wybór „Legacy vs UEFI” dotyczy wyłącznie drugiego etapu – firmware. Reszta musi się do tego dopasować: jakie partycjonowanie dysku (MBR czy GPT), jak zrobiony pendrive instalacyjny, jakie bootloadery zadziałają bez kombinacji.

Najprostsza, skuteczna reguła:

  • Nowy sprzęt + nowy system (Windows 10/11, współczesny Linux) = UEFI + GPT.
  • Stary sprzęt + stary system (Windows 7 i starsze, stare dystrybucje) = Legacy + MBR.

Tryb Legacy na nowoczesnym komputerze ma sens tylko w kilku niszowych sytuacjach:

  • chcesz uruchomić bardzo stary system (Windows XP, kilka starszych narzędzi serwisowych),
  • używasz obrazu ISO lub pendrive’a, który w ogóle nie obsługuje UEFI,
  • masz specyficzne środowisko (np. stare oprogramowanie diagnostyczne w warsztacie), które było pisane tylko „pod BIOS”.

Dlaczego ta decyzja jest tak ważna? Bo wpływa bezpośrednio na:

  • Widoczność dysku w instalatorze – UEFI lubi GPT, Legacy lubi MBR. Mieszanie często kończy się komunikatami typu „nie można zainstalować na tej partycji”.
  • Widoczność pendrive’a – jeśli pendrive jest przygotowany jako UEFI, a masz włączony tylko Legacy (lub odwrotnie), komputer udaje, że nośnika nie ma.
  • Dual-boot – systemy w różnych trybach (jeden w UEFI, drugi w Legacy) rzadko współpracują bez ręcznych kombinacji.
  • Późniejszą naprawę – narzędzia odzyskiwania systemu zakładają zgodność trybu startu i typu partycji.

Dobrze dobrany tryb (Legacy vs UEFI) oszczędza naprawdę sporo czasu: zamiast szukać „magicznych” ustawień, trzymasz się kilku zasad, które bazują właśnie na historii i logice rozruchu.

Wskazówka 1 – Zrozum prosty schemat: od przycisku zasilania do pulpitu

Uproszczona „ścieżka startu”

Kiedy wciskasz przycisk zasilania, nie dzieje się jedna rzecz, tylko krótki łańcuch zdarzeń. Wystarczy zrozumieć je w wersji „dla praktyka”:

  1. Zasilanie i płyta główna

    Zasilacz podaje napięcia, kontroler na płycie sprawdza podstawowe sygnały („czy jest prąd, czy napięcia są w normie, czy procesor wstaje”). Jeżeli coś jest poważnie nie tak, często słychać sygnały dźwiękowe (beepy) albo nic nie widać na ekranie.

  2. Firmware: BIOS lub UEFI

    To pierwszy program, który faktycznie się uruchamia. Odpowiada za:

    • inicjalizację pamięci RAM, kontrolerów, części urządzeń,
    • test POST (Power-On Self Test) – w uproszczeniu: „czy podstawowe rzeczy działają”,
    • wyszukanie urządzenia startowego według listy: np. „najpierw dysk, potem pendrive”.

    Firmware nie jest systemem operacyjnym, ale jest jego przedsionkiem – musi doprowadzić do wskazania konkretnego pliku startowego (bootloadera).

  3. Bootloader

    To mały program na dysku (lub innym nośniku), którego zadaniem jest załadowanie właściwego systemu operacyjnego. Przykłady:

    • Windows Boot Manager – odpowiedzialny za start Windows; zwykle wpis „Windows Boot Manager” widzisz na liście UEFI.
    • GRUB w Linuksie – częsty menedżer rozruchu dla wielu systemów.

    Bootloader wie, na jakiej partycji i w jakim pliku znajduje się jądro systemu (kernel) i przekazuje mu kontrolę.

  4. System operacyjny

    Tutaj dzieje się większość „magii”: ładowanie sterowników, montowanie systemu plików, uruchamianie usług, logowanie użytkownika, pulpit. Firmware i bootloader są już dawno „w tle”.

Ten schemat jest wspólny zarówno dla BIOS, jak i UEFI. Różnica jest jak firmware i bootloader wykonują swoją część roboty i jakie mają ograniczenia.

Jak rozumienie etapów startu pomaga przy awariach

Przy problemach z uruchomieniem systemu warto najpierw odpowiedzieć sobie: na którym etapie stoję? To często od razu zawęża poszukiwania.

  • Brak obrazu, dziwne „beepy”, wentylatory kręcą, ale nic dalej się nie dzieje
    Zwykle awaria na poziomie sprzętu / POST. Szukasz tu przyczyn typu: pamięć RAM, karta graficzna, zasilacz, zwarcia. Ustawienia UEFI/BIOS praktycznie nic nie pomogą.
  • Logo producenta, czasem komunikat o klawiszu „Press F2/DEL to enter Setup”, potem „No bootable device”
    Firmware działa, ale nie znalazł urządzenia startowego. Sprawdzasz:

    • czy dysk fizycznie jest widoczny w BIOS/UEFI,
    • czy kolejność bootowania obejmuje właściwy dysk / pendrive,
    • czy tryb Legacy/UEFI pasuje do tego, jak przygotowany jest nośnik.
  • Komunikaty typu „Bootmgr is missing”, „No such partition”, „grub rescue>”
    Firmware nośnik znalazł, ale problem jest po stronie bootloadera. Tu przydają się narzędzia naprawy rozruchu, przywrócenie GRUB, naprawa sektora rozruchowego.
  • Pojawia się logo Windows / Linux, ale potem błąd, zawieszka, pętla restartów
    System startuje, lecz coś się wysypuje już w jego własnym zakresie: sterownik, usługa, pliki systemowe. Tu pomaga tryb awaryjny, przywracanie systemu, reinstall – kombinacje w BIOS/UEFI nie zmienią wiele.

Szybkie przypisanie objawu do etapu skraca diagnostykę. Zamiast np. zmieniać tryb UEFI/Legacy pięć razy, od razu sprawdzasz, czy firmware widzi dysk i czy na nim jest jakikolwiek poprawny bootloader.

Przykład: komputer zatrzymuje się na logo producenta

Typowy scenariusz: komputer pokazuje tylko logo (Asus, Lenovo, MSI itd.) i nic dalej. Co można zrobić krok po kroku, bez błądzenia:

  1. Spróbuj wejść do ustawień firmware – zwykle klawisz Del, F2, F10, Esc zaraz po włączeniu. Jeśli nie da się wejść: problem był raczej na poziomie sprzętu lub poważnego zacięcia firmware.
  2. Jeśli wejście do BIOS/UEFI działa, sprawdź:
    • czy dysk jest widoczny na liście urządzeń (zakładka typu „Storage”, „SATA Configuration”, „NVMe Configuration”),
    • czy kolejność bootowania wskazuje jakiś system lub boot manager,
    • czy nie masz wyświetlonego ostrzeżenia (czasami firmware sygnalizuje np. padnięty dysk).
  3. Jeśli dysku nie ma – to raczej kwestia sprzętowa (kabel, złącze, sam dysk), a nie ustawień.
  4. Jeśli dysk jest, ale nie ma wpisu „Windows Boot Manager” / systemu – bootloader może być uszkodzony. Wtedy ratunkiem jest najczęściej uruchomienie pendrive’a z instalatorem w odpowiednim trybie (Legacy/UEFI) i użycie opcji naprawy rozruchu.

Świadomość, gdzie kończy się odpowiedzialność BIOS/UEFI, a gdzie zaczyna bootloader i system, pozwala lepiej planować, na co faktycznie wpływa zmiana trybu Legacy/UEFI, a na co nie.

Wskazówka 2 – Poznaj ograniczenia starego BIOS-u, żeby rozumieć dziwne błędy

Skąd się wziął BIOS i jaką rolę pełnił

BIOS (Basic Input/Output System) powstał w czasach, kiedy:

  • dyski miały śmiesznie małą pojemność względem dzisiejszych standardów,
  • pamięci RAM liczyło się w kilobajtach, nie w gigabajtach,
  • komputery PC miały być proste i tanie.

Producenci potrzebowali wspólnej warstwy, która:

  • uruszy komputer po włączeniu,
  • udostępni prosty interfejs dla systemu operacyjnego do podstawowych operacji (np. odczyt z dysku, obsługa klawiatury),
  • nie będzie wymagała dużych zasobów ani komplikowanej architektury.

BIOS był więc 16-bitowym oprogramowaniem zapisanym w pamięci płyty głównej, projektowanym na zupełnie inne realia niż dzisiejsze. Mimo to przetrwał dekady, bo:

  • był już dobrze poznany i „wystarczająco dobry” dla wielu zastosowań,
  • większość systemów i narzędzi była do niego dostosowana,
  • producenci nie mieli pilnej potrzeby drastycznie zmieniać czegoś, co po prostu działa.

Ograniczenia BIOS-u, które dziś przeszkadzają

Z perspektywy współczesnego użytkownika BIOS ma kilka kluczowych wad:

  • Powiązanie z MBR
    Klasyczny BIOS zakłada rozruch z dysków z tablicą partycji MBR. Ten schemat partycjonowania ma ograniczenia:

    • ograniczoną liczbę partycji podstawowych,
    • problemy przy bardzo dużych dyskach (część pojemności może być niewidoczna lub wymagać „obejść”).

    To właśnie te historyczne założenia powodują różne dziwne błędy przy nowoczesnych dyskach.

  • Brak świadomości dużych, nowoczesnych nośników
    W epoce BIOS-u nikt nie planował dysków o dzisiejszej pojemności ani tak szybkich interfejsów jak NVMe. Stąd:

    • problemy z pełnym wykorzystaniem pojemności na starych płytach,
    • konieczność stosowania dodatkowych kontrolerów lub aktualizacji firmware (o ile producent je w ogóle wydał).
  • Przestarzałe środowisko programistyczne
    BIOS to 16-bitowe środowisko bez wsparcia dla nowoczesnych funkcji bezpieczeństwa, grafiki, sieci czy szyfrowania. Rozbudowa go o nowe możliwości była po prostu mało sensowna.
  • Toporny interfejs
    Tekstowe menu, nawigacja tylko klawiaturą, skrócone opisy. Do prostych rzeczy wystarcza, ale przy bardziej skomplikowanych konfiguracjach staje się mało czytelny.

Jak ograniczenia BIOS-u przekładają się na praktyczne problemy

Kilka typowych, życiowych przykładów:

  • Stary laptop + nowy, duży dysk
    Po podłączeniu nowego dysku okazuje się, że system widzi tylko część pojemności lub pojawiają się problemy przy instalacji systemu. Powód: stary BIOS i jego obsługa MBR nie były projektowane z myślą o takich nośnikach. Czasem można:
  • użyć tylko części pojemności (podział na mniejszy wolumen),
  • zaktualizować BIOS (jeśli producent wydał nowszą wersję),
  • przeznaczyć ten komputer do mniej wymagających zadań (np. lekki Linux, maszynka do prostych zadań).
  • Instalacja nowego systemu na bardzo starej płycie głównej
    Komputer technicznie „ciągnie” nowszy Windows lub nowy Linux, ale:

    • instalator wymaga GPT i UEFI do pełnego wsparcia (np. szyfrowania, Secure Boot),
    • brak obsługi niektórych funkcji sprzętowych przez BIOS.

    W praktyce często taniej i rozsądniej jest:

    • zostać przy lekkim, mniej wymagającym systemie,
    • nie próbować na siłę przerabiać starej platformy na pełnowartościowy nowoczesny komputer.
  • „Magiczne” limity przy rozbudowie
    Przy dołożeniu większej ilości RAM-u czy wymianie procesora komputer wstaje, ale:

    • nie widzi całej pamięci,
    • nie wykorzystuje pełnych możliwości CPU,
    • daje niestabilność pod obciążeniem.

    Część takich ograniczeń siedzi w samym BIOS-ie: brak mikrokodów dla nowszych procesorów, brak poprawek dla dużych modułów RAM, stare algorytmy zarządzania energią. Aktualizacja firmware czasem pomaga, ale jeśli płyta ma już swoje lata, inwestowanie w lepszy CPU czy więcej RAM-u ponad „zdrowy rozsądek” często kończy się słabym zwrotem z wydanych pieniędzy.

Wniosek z tych historycznych ograniczeń jest prosty: przy bardzo starych konstrukcjach szybciej i taniej bywa pogodzić się z limitem platformy niż na siłę wymuszać pełną zgodność z nowoczesnym systemem. Zamiast walczyć tydzień z dziwnymi błędami instalatora, zwykle lepiej dobrać system i dysk „pod epokę” danego BIOS-u i traktować sprzęt jako maszynę pomocniczą, a nie główny komputer roboczy.

Przy planowaniu jakichkolwiek zmian sprzętowych da się też z góry przewidzieć, czy BIOS nie stanie się wąskim gardłem. Warto przejrzeć dokumentację płyty głównej: maksymalny obsługiwany RAM, lista wspieranych procesorów, ewentualne uwagi o dużych dyskach. Kilka minut czytania specyfikacji oszczędza potem wiele godzin eksperymentów z partycjonowaniem, zmienianiem trybu rozruchu i reinstalacjami bez efektu.

Jeśli sprzęt działa stabilnie, ale ma „dziwactwa” przy bootowaniu (konieczność ręcznego wyboru dysku, brak startu z niektórych pendrive’ów, losowe komunikaty błędów przy bardzo dużych nośnikach), nie zawsze jest sens dochodzić do absolutnego dna problemu. Często bardziej opłaca się przyjąć praktyczne obejście: mniejszy dysk systemowy, prostszy układ partycji MBR, jedna dystrybucja zamiast trzech na jednej maszynie, klasyczny tryb Legacy zamiast kombinacji z pół‑UEFI na nieobsługiwanym przez producenta BIOS-ie.

Na koniec prosta checklista, która pomaga szybciej podjąć decyzję: 1) sprawdź, czy płyta główna ma pełne UEFI i obsługę GPT; jeśli tak – ustaw ją jako domyślną bazę przyszłych instalacji. 2) Przy starszych komputerach ustal maksymalną sensowną konfigurację (RAM, typ dysku, wersja systemu) i trzymaj się jej, zamiast dokładać losowe komponenty „bo są pod ręką”. 3) Gdy trafiasz na niejasne błędy rozruchu, najpierw ustal: czy zawodzi firmware, bootloader, czy sam system – dopiero potem zmieniaj tryb Legacy/UEFI lub przebudowuj partycje. Dzięki temu każda godzina grzebania w rozruchu ma uzasadnienie i realny efekt.

Wskazówka 3 – Traktuj UEFI jak „system startowy”, a nie tylko ładniejsze BIOS‑owe menu

Co faktycznie wnosi UEFI ponad stary BIOS

UEFI to nie tylko kolorowe okienka i obsługa myszki. To zupełnie inny model działania:

  • Start w trybie 32/64‑bit – firmware może uruchamiać znacznie bardziej rozbudowane programy niż prosty kod dla 16‑bitowego BIOS‑u.
  • Obsługa partycji GPT – standardowo współpracuje z nowszym schematem partycjonowania dysków, co rozwiązuje większość historycznych ograniczeń MBR.
  • Własny menedżer rozruchu – potrafi bezpośrednio uruchamiać pliki EFI (np. Windows Boot Manager, GRUB w trybie UEFI) z dedykowanej partycji EFI.
  • Modułowość – producenci mogą dodawać rozszerzenia: diagnostykę RAM‑u, narzędzia RAID, a czasem nawet prostą przeglądarkę lub klienta aktualizacji.
  • Secure Boot – mechanizm weryfikacji podpisów cyfrowych, który ma uniemożliwić start nieautoryzowanego kodu.

W praktyce UEFI jest bliżej „mini‑systemu operacyjnego”, który startuje jako pierwszy i dopiero potem przekazuje stery Twojemu OS‑owi. To tłumaczy, czemu tak wiele rzeczy da się dziś załatwić jeszcze przed uruchomieniem Windowsa czy Linuxa – od aktualizacji firmware po podstawową diagnostykę.

Jak rozpoznać, że korzystasz z pełnego UEFI, a nie „udawanego” trybu

Najszybsze wskaźniki, że komputer działa w trybie UEFI:

  • Podczas instalacji systemu pendrive widnieje w menu bootowania jako „UEFI: nazwa_pendrive’a”.
  • Na dysku systemowym w narzędziu do partycjonowania widzisz:
    • schemat GPT,
    • małą partycję typu EFI/ESP (zwykle kilkaset MB).
  • W ustawieniach firmware widnieją opcje typu:
    • „UEFI/Legacy Boot”, „CSM Support”,
    • „Secure Boot”,
    • lista bootowania zawiera wpisy w stylu „Windows Boot Manager”.

Jeśli płyta ma graficzne menu, ale nie ma trybu UEFI w listach bootowania, to często tylko „odmłodzony” BIOS z myszką, a nie pełne UEFI. Wtedy nie ma sensu projektować instalacji systemu pod GPT i funkcje typu Secure Boot – sprzęt po prostu ich nie wykorzysta.

Prosty schemat: kiedy wybierać UEFI, a kiedy zostać przy Legacy

Decyzja nie musi trwać godzinami. Da się ją sprowadzić do kilku prostych reguł:

  • Nowy sprzęt (z ostatnich lat) + współczesny system (Windows 10/11, aktualny Linux)
    • domyślny wybór: UEFI + GPT,
    • włączony Secure Boot, chyba że wiesz, że instalujesz system, który tego nie lubi.
  • Mieszanka starego i nowego – np. stary Windows 7 + nowszy laptop
    • często mniej problemów sprawia Legacy + MBR (o ile firmware jeszcze to obsługuje),
    • Secure Boot zwykle trzeba wyłączyć, a czasem również całe CSM/Legacy, żeby instalator w ogóle ruszył.
  • Bardzo stary sprzęt, bez sensownego UEFI
    • nie ma co kombinować: zostajesz przy Legacy + MBR,
    • w zamian wybierasz system i dysk, które dobrze grają z tą epoką.

Najwięcej kłopotów robią konfiguracje „na pół gwizdka”: UEFI włączone, ale system instalowany jak pod starego BIOS‑a, albo odwrotnie – GPT na dysku, a firmware zmuszony do startu w trybie Legacy. Im prostszy i bardziej konsekwentny schemat, tym mniej czasu ucieka na debugowanie rozruchu.

Wskazówka 4 – Zaplanuj instalację: Legacy/UEFI i MBR/GPT w jednym prostym wyborze

Minimalny plan przed instalacją systemu

Zamiast klikać „Dalej” w instalatorze w ciemno, najlepiej odpowiedzieć sobie na kilka pytań:

  • Jaki system instalujesz (konkretna wersja Windowsa / dystrybucja Linuxa)?
  • Na jakim sprzęcie (pełne UEFI czy tylko stary BIOS, typ dysku: HDD/SSD/NVMe)?
  • Czy na dysku ma być tylko jeden system, czy kilka (dual‑boot jest wrażliwszy na mieszanie trybów)?

Po odpowiedziach dobór schematu robi się prosty:

  • jeden nowoczesny system na nowym sprzęcie → UEFI + GPT,
  • stary system lub mieszanka z bardzo starym OS‑em → częściej wygodniejsze Legacy + MBR, ale tylko jeśli firmware i system naprawdę tego wymagają,
  • dual‑boot dwóch w miarę nowych systemów → lepiej od razu UEFI + GPT, oba w tym samym trybie.

Typowe konflikty i szybkie rozwiązania

Większość problemów przy instalacji to powtarzalne schematy. Kilka najczęstszych i proste remedia:

  • Instalator mówi, że nie może zainstalować systemu na partycjach GPT
    Zwykle oznacza to, że komputer ruszył w trybie Legacy, a dysk jest w GPT.

    • albo przełączasz firmware na UEFI i uruchamiasz ponownie instalator,
    • albo konwertujesz dysk na MBR (utrata danych, więc tylko jeśli możesz wyczyścić dysk).
  • Instalator krzyczy, że system nie może startować z MBR przy tym sprzęcie
    Najczęściej instalator ruszył jako UEFI i widzi dysk w MBR.

    • jeśli chcesz nowoczesne UEFI → konwertuj MBR → GPT (przed lub w trakcie instalacji),
    • jeśli chcesz zostać przy MBR → uruchom pendrive w trybie Legacy zamiast „UEFI: pendrive”.
  • Brak opcji bootowania z pendrive’a
    Często firmware pokazuje dwa wpisy:

    • „nazwa_pendrive’a” (Legacy),
    • „UEFI: nazwa_pendrive’a”.

    Jeśli wybierzesz nie ten, co trzeba, dostaniesz inne błędy partycjonowania. W praktyce:

    • jeśli celujesz w UEFI+GPT → startuj z „UEFI: nazwa_pendrive’a”,
    • jeśli chcesz Legacy+MBR → wybieraj wersję bez dopisku UEFI.
  • Po instalacji system się nie uruchamia, ale pendrive startuje poprawnie
    Bardzo częsta przyczyna: system zainstalowany w innym trybie niż ten, w którym startuje firmware.

    • sprawdź w ustawieniach, czy komputer startuje w UEFI, a Ty nie wymusiłeś Legacy (lub odwrotnie),
    • upewnij się, że na liście bootowania jest Windows Boot Manager / wpis od Twojej dystrybucji Linuxa, a nie tylko „nazwa dysku”.

Jak nie spędzić weekendu na reinstalacjach

Zamiast trzech instalacji pod rząd, lepiej ułożyć prosty scenariusz działania:

  1. Ustal docelowy tryb (UEFI+GPT lub Legacy+MBR) w zależności od systemu i wieku sprzętu.
  2. Przygotuj pendrive zgodnie z tym wyborem (Rufus/Yumi i podobne narzędzia pytają, jaki tryb chcesz).
  3. Ustaw firmware pod ten sam tryb (włącz/wyłącz CSM, wybierz UEFI Only lub Legacy Only, zgodnie z planem).
  4. Wyzeruj istniejący układ partycji na dysku systemowym, jeśli nie trzymasz tam ważnych danych – mieszanki MBR+GPT z poprzednich eksperymentów często są źródłem chaosu.

Ten prosty plan zwykle skraca całą operację do jednej, świadomej instalacji zamiast serii nieudanych prób.

Wskazówka 5 – Secure Boot i bootloadery: bezpieczeństwo kontra elastyczność

Secure Boot w praktyce: kiedy pomaga, a kiedy tylko przeszkadza

Secure Boot ma pilnować, żeby podczas startu komputera uruchamiał się tylko kod podpisany zaufanym kluczem. W praktyce oznacza to, że:

  • Windows 10/11 z fabryki zazwyczaj działa z Secure Boot bez problemów.
  • Część dystrybucji Linuxa (te „większe”) ma już podpisane bootloadery i zadziała na włączonym Secure Boot.
  • Narzędzia ratunkowe, starsze Linuxy, własne buildy często w ogóle się nie uruchomią, dopóki Secure Boot nie zostanie wyłączony.

Jeśli komputer jest domowy i nie trzymasz na nim krytycznych danych służbowych, bardzo często tańsze czasowo jest wyłączenie Secure Boot na czas eksperymentów z różnymi systemami i narzędziami ratunkowymi. Zostawienie go sensowniejsze jest tam, gdzie liczy się kontrola nad tym, co w ogóle może wystartować (np. maszyna do pracy, którą nie każdy ma prawo „grzebać” pendrive’em).

Jak ogarnąć bootloadery, żeby nie walczyły ze sobą

Przy UEFI każdy system lubi instalować swój własny bootloader na partycji EFI. Typowe scenariusze:

  • Sam Windows – instaluje Windows Boot Managera, który po prostu startuje system bez dodatkowego menu.
  • Linux obok Windowsa – instalator Linuxa dorzuca GRUB‑a, który potrafi dodać wpis „Windows” do swojego menu.

Najmniej problemów jest wtedy, gdy:

  • na jednym komputerze jeden bootloader pełni rolę „głównego” (np. GRUB przy dual‑boocie z Linuxem),
  • nie instalujesz kilku Linuxów, z których każdy nadpisuje wpisy poprzednika w partycji EFI „po swojemu”,
  • regularnie czyścisz stare, nieużywane wpisy z menedżera rozruchu w firmware, jeśli systemów jest dużo.

Przykład z życia: jeśli instalujesz Linuxa po Windowsie i chcesz, żeby GRUB zarządzał menu wyboru systemu, nie ma sensu desperacko przywracać potem Windows Boot Managera jako jedynego wpisu. Oszczędzasz sobie czasu, akceptując GRUB‑a jako „głównego” i dopracowując jego konfigurację (np. skracając czas odliczania, ustawiając domyślny system).

Krótka checklista decyzji przed grzebaniem w rozruchu

  • 1) Ustal, czy chcesz działać w UEFI+GPT, czy Legacy+MBR – nie mieszaj trybów bez potrzeby.
  • 2) Sprawdź, który system ma być „główny” (ten, który decyduje o menu wyboru). Pozostałe traktuj jako gości w jego bootloaderze.
  • 3) Zdecyduj, czy Secure Boot ma być teraz Twoim sprzymierzeńcem, czy przeszkodą:
    • przy jednej, fabrycznej instalacji Windowsa – można go zostawić,
    • przy kombinacjach z wieloma systemami i narzędziami ratunkowymi – często szybciej go wyłączyć.
  • 4) Zanim zaczniesz „naprawiać” rozruch, ustal, kto dokładnie nie startuje: firmware (brak dysku), bootloader (błąd w stylu „grub rescue”, „bootmgr is missing”), czy sam system (BSOD, kernel panic).

Trzymanie się tej krótkiej listy sprawia, że decyzje wokół BIOS‑u/UEFI przestają być loterią, a stają się logicznym ciągiem: wybierasz tryb, planujesz rozruch, dopiero potem instalujesz system i dodatki. Dzięki temu zrozumienie „co się dzieje między przyciskiem zasilania a pulpitem” zaczyna realnie oszczędzać czas i nerwy przy każdej kolejnej modyfikacji komputera.

Wskazówka 6 – Klonowanie, zmiana dysku i migracja między BIOS/UEFI bez dramatu

Kiedy proste klonowanie „1:1” ma sens

Najmniej problemów jest wtedy, gdy niczego „filozoficznie” nie zmieniasz:

  • Ten sam tryb startu: stary i nowy dysk działają w tym samym komputerze, w tym samym trybie (UEFI → UEFI lub Legacy → Legacy).
  • Ten sam układ partycji: klonujesz MBR → MBR albo GPT → GPT, bez konwersji po drodze.
  • Rozsądna różnica pojemności: nowy dysk jest równy lub większy, więc kloner nie musi się „gimnastykować” z upychaniem partycji.

Wtedy wystarcza dowolne, proste narzędzie do klonowania (często producenci dysków dają swoje). Kopiujesz cały dysk, przepinasz, ustawiasz nowy jako pierwszy na liście bootowania – i zwykle wszystko rusza bez dotykania BIOS/UEFI.

Kiedy klonowanie zaczyna się gryźć z UEFI/Legacy

Problemy zaczynają się wraz z mieszaniną scenariuszy:

  • Klon z MBR na nowy komputer z UEFI – sprzęt jest gotowy na UEFI+GPT, ale dostaje stary schemat Legacy+MBR.
  • Klon z dysku z UEFI na maszynę wymuszoną na Legacy – firmware nie umie poprawnie wystartować z partycji EFI.
  • Zmiana rozmiarów partycji po klonie – czasem bootloader lub partycja EFI „przesuwa się” i firmware traci do niej odwołanie.

Przykład z praktyki: klonujesz starego HDD z Windows 7 (MBR, Legacy) na nowego SSD w nowym komputerze. Firmware z fabryki jedzie w trybie UEFI Only i nie widzi starego stylu rozruchu. Zamiast godzin szukania „magicznego” narzędzia do naprawy, taniej czasowo jest:

  1. w UEFI włączyć tryb Legacy/CSM,
  2. przestawić start na nowy SSD,
  3. przy pierwszym starcie sprawdzić, czy Windows złapie sterowniki do nowego sprzętu.

Dopiero później możesz myśleć o migracji na czyste UEFI, o ile w ogóle jest sens (dla samej „nowoczesności” często nie ma).

Prosty schemat decyzji przy migracji na nowy dysk

Zamiast kombinować każdorazowo od zera, możesz przyjąć taki szybki wzór:

  • Chcesz tylko przyspieszyć komputer (HDD → SSD), sprzęt ten sam
    → klonowanie 1:1 w tym samym trybie; zero zabawy z MBR/GPT.
  • Wymieniasz komputer na nowszy i chcesz przeprowadzić stary system „jak jest”
    → najpierw spróbuj klonu + włączenie Legacy/CSM; jeśli system jest bardzo stary, instalacja od zera może wyjść szybciej.
  • Nowy komputer, nowy system, nowy dysk
    → odpuść kombinacje z klonowaniem z MBR; zrób czystą instalację w trybie UEFI+GPT i ewentualnie sklonuj tylko dane, nie cały system.

Wskazówka 7 – Jak szybko rozpoznać, „z czym masz do czynienia”: BIOS czy UEFI, MBR czy GPT

Błyskawiczny przegląd z poziomu systemu

Zanim wejdziesz do firmware, da się sporo ustalić z poziomu działającego systemu. Pozwala to uniknąć restartów tylko po to, żeby „zobaczyć, co tam jest”.

  • Windows:
    • wciśnij Win+R → msinfo32,
    • znajdź pole Tryb BIOS:
      • UEFI – system startuje w UEFI (dysk najpewniej jest w GPT),
      • Dziedziczny / Legacy – system rusza jak stary BIOS (dysk zazwyczaj w MBR).
    • w narzędziu Zarządzanie dyskami kliknij dysk prawym przyciskiem → Właściwości → zakładka Woluminy; pole Styl partycji pokaże MBR lub GPT.
  • Linux:
    • sprawdź, czy istnieje katalog /sys/firmware/efi:
      • jeśli jest – system wystartował w UEFI,
      • jeśli brak – prawdopodobnie działa w trybie Legacy.
    • polecenie sudo fdisk -l pokaże przy dysku informację, czy to GPT, czy dos (MBR).

Ta szybka diagnostyka zwykle wystarcza, by zdecydować: migrujesz „po staremu”, czy już sensowniej przejść w pełne UEFI+GPT.

Sygnały z samego firmware

Kiedy masz dostęp do ekranu startowego, od razu widać, z którą epoką masz do czynienia:

  • Stary BIOS – tekstowe, proste menu, brak myszy, ograniczona rozdzielczość, bardzo skromne ustawienia.
  • UEFI – interfejs graficzny, obsługa myszy, więcej zakładek, czasem nawet ekran informacji o dyskach, temperaturach, profilach OC.

Dodatkowo lista urządzeń rozruchowych w UEFI ma zwykle wpisy w stylu:

  • Windows Boot Manager (dysk NVMe…) – charakterystyczne dla UEFI,
  • UEFI: nazwa_pendrive’a – rozruch w trybie UEFI,
  • nazwa_dysku bez dopisków – najczęściej tryb Legacy.

Wskazówka 8 – Kiedy „modernizować” do UEFI, a kiedy nie zawracać sobie tym głowy

Scenariusze, w których UEFI realnie coś daje

UEFI nie jest magicznym przyspieszaczem, ale w kilku przypadkach ewidentnie wygrywa:

  • Dyski większe niż typowe limity MBR – przy dużych dyskach schemat GPT rozwiązuje problemy z „brakiem miejsca widzianym przez system”.
  • Nowe systemy z długim wsparciem – Windows 11 zakłada środowisko UEFI; przy UEFI+GPT mniej kombinacji przy aktualizacjach i naprawie.
  • Maszyna robocza lub służbowa – Secure Boot i lepsza kontrola nad tym, co może się uruchomić, dają trochę wyższy poziom bezpieczeństwa „za darmo”.

Jeśli dopiero stawiasz system na nowym sprzęcie, wybór UEFI+GPT to często najprostszą decyzja „na lata” – mniej łatania, więcej zgodności z tym, jak producenci projektują dziś firmware.

Sytuacje, w których pogoń za UEFI to tylko strata czasu

Są jednak przypadki, gdzie próby „przepisania” wszystkiego na UEFI to tylko wydatek energii bez realnej korzyści:

  • Stary, działający komputer z ograniczonym wsparciem – jeśli sprzęt i tak nie pociągnie nowych systemów, konwersja na GPT/UEFI nie ma praktycznego sensu.
  • Stary, ale stabilny system w trybie Legacy – jeśli masz dopięte kopie zapasowe i wszystko działa, migracja tylko po to, by mieć napis „UEFI” w narzędziu diagnostycznym nie poprawi komfortu pracy.
  • Specyficzne oprogramowanie, które dobrze czuje się na MBR/Legacy i nie jest już rozwijane – tu ważniejsza jest przewidywalność niż nowoczesna architektura.

Jeśli konwersja oznacza dzień roboty, reinstalacje, walkę z licencjami i sterownikami, a jedyną nagrodą jest „czystszy” układ partycji, bilans czasowy bywa kiepski.

Prosta checklista decyzyjna