Założenia zestawu: komputer pod Windows i Linux jednocześnie
Komputer pod Windows i Linux oznacza w praktyce sprzęt, który bez kombinacji uruchomi oba systemy, ma sterowniki dostępne po instalacji i nie blokuje instalatorów przez źle ustawione UEFI, Secure Boot czy tryb kontrolera dysku. Konfiguracja powinna pozwalać zarówno na klasyczny dual boot z jednego dysku, jak i swobodne testowanie dystrybucji z pendrive.
Windows zwykle obsługuje większość nowego sprzętu „z pudełka”, a brakujące sterowniki dociąga z Windows Update. Linux bywa bardziej wymagający pod względem doboru GPU i kart WiFi, za to w wielu przypadkach oferuje sterowniki w samym jądrze i dodatkowych pakietach firmware. Projektując zestaw, trzeba unikać elementów, które pod Linuksem są wciąż problematyczne (niektóre WiFi, touchpady, bardzo nowe GPU bez wsparcia w danym kernelu).
Dla gracza priorytetem będzie stabilny sterownik GPU w Windows, zgodny z DirectX i popularnymi grami, ale jeśli ten sam sprzęt ma sensownie działać pod Linuksem (np. Steam, Proton), dobór producenta karty graficznej ma krytyczne znaczenie. Dla programisty lub administratora liczą się bardziej rzeczy typu IOMMU, wirtualizacja, solidna obsługa sieci i dysków, a mniejszą rolę gra maksymalna liczba FPS.
Decyzja „oba systemy” wpływa bezpośrednio na:
wybór płyty głównej i chipsetu (UEFI, aktualizacje, tryb SATA, LAN, WiFi),
GPU (Nvidia vs AMD/Intel i ich sterowniki pod Linuxem),
strukturę dysków (osobne nośniki na systemy vs jedna jednostka z kilkoma partycjami),
konfigurację Secure Boot i TPM (szczególnie przy Windows 11).
Priorytety przy takim zestawie można ująć krótko: stabilność ponad marginalne zyski wydajności, kompatybilność sprzętowa ponad „egzotyczne” nowinki, oraz łatwość instalacji sterowników i aktualizacji. Jeśli wybór podzespołów będzie rozsądny, instalacja obu systemów sprowadzi się do kilku standardowych kroków zamiast godzin szukania sterowników WiFi lub walki z niedziałającym Secure Boot.
Źródło: Pexels | Autor: Mikhail Nilov
Dobór podzespołów z myślą o Linuxie i Windowsie
CPU, chipset i płyta główna
Procesor i chipset zwykle nie stanowią problemu z punktu widzenia Linuksa, o ile korzysta się z aktualnych dystrybucji. Zarówno nowoczesne platformy AMD, jak i Intela są obsługiwane przez jądro od stosunkowo wczesnych wersji. Różnice pojawiają się przy bardzo świeżych generacjach CPU, gdzie do pełnej obsługi energetyki czy zintegrowanego GPU potrzeba nowszego kernela niż ten, który oferuje np. długoterminowe wydania dystrybucji serwerowych.
Chipset i płyta główna wpływają natomiast bezpośrednio na:
tryb rozruchu (UEFI, obecność i działanie CSM),
tryb kontrolera SATA/NVMe (AHCI, RAID/Intel RST),
dostępność wbudowanego modułu WiFi/Bluetooth i LAN,
kompatybilność z pamięcią RAM i GPU,
funkcje wirtualizacji (VT-x/AMD-V, VT-d/IOMMU).
Znaczenie ma również jakość firmware (UEFI/BIOS) i częstotliwość aktualizacji. Producent, który regularnie publikował nowe wersje (naprawa problemów z bootowaniem, mikrokod CPU, AGESA/ME firmware), jest bezpieczniejszym wyborem niż tania płyta, która dostała jedną wersję UEFI i „koniec tematu”. Przy dual boot aktualne UEFI często rozwiązuje m.in. drobne błędy z wykrywaniem dysków NVMe czy problematyczne zachowanie Secure Boot.
Warto zwrócić uwagę, czy płyta oferuje wprost w UEFI opcje:
TPM/fTPM – wymagane przez Windows 11; przy Linuksie zwykle nie przeszkadza, można pozostawić włączone,
SATA Mode / Storage Configuration – możliwość przełączenia w AHCI,
CSM / Legacy Boot – możliwość całkowitego wyłączenia starego trybu i pracy wyłącznie w UEFI.
Dla osób korzystających z maszyn wirtualnych ważne są opcje VT-x/AMD-V oraz VT-d/IOMMU (przydatne np. do passthrough GPU pod Linuksem). Te funkcje są zwykle domyślnie aktywne, ale w niektórych UEFI trzeba je włączyć ręcznie.
GPU – Nvidia, AMD, Intel
Wybór karty graficznej to jedna z kluczowych decyzji przy komputerze, który ma działać i pod Windowsem, i pod Linuksem. Windows dobrze dogaduje się zarówno z Nvidią, AMD, jak i zintegrowanymi układami Intela. Linux także, ale z istotnymi różnicami w wygodzie konfiguracji i zachowaniu przy Secure Boot.
Nvidia pod Windows to klasyka – instalacja oficjalnego pakietu ze strony producenta lub sterownika z Windows Update i gotowe. Pod Linuksem sytuacja jest bardziej złożona. Dostępne są:
sterowniki proprietarne (własnościowe) Nvidii – zapewniają wysoką wydajność i dobre wsparcie dla gier, ale wymagają integracji z kernel-modułami (czasem DKMS) i potrafią kolidować z Secure Boot,
sterownik Nouveau – otwartoźródłowy, zintegrowany z Linuksem, jednak zazwyczaj zauważalnie słabszy wydajnościowo, szczególnie w nowszych modelach GPU.
Jeśli planowany jest poważniejszy gaming lub wykorzystanie GPU do obliczeń, najlepiej założyć użycie oficjalnych sterowników Nvidii i od razu przewidzieć konieczność:
wyłączenia Secure Boot lub
własnoręcznego podpisania modułów jądra pod Secure Boot.
AMD i Intel są generalnie „łatwiejsze” pod Linuksem. Sterowniki do większości kart są w kernelu i w Mesa, dzięki czemu po starcie systemu grafika działa w pełnym 3D bez dodatkowych zamkniętych pakietów. Wymagane jest tylko to, aby dystrybucja miała odpowiednio nowy kernel i Mesa dla najświeższych generacji GPU. W praktyce:
dla nowych kart AMD (np. RDNA2, RDNA3) przydają się dystrybucje z szybkim cyklem aktualizacji (np. rolling release),
dla zintegrowanych GPU Intela większość dystrybucji radzi sobie bez problemu już od kilku lat.
Jeśli komputer ma być „bezproblemowy” z Linuksem, a priorytetem nie jest absolutne maksimum FPS w niszowych tytułach, układ AMD lub Intel jako główna grafika często bywa rozsądniejszym wyborem niż Nvidia.
Pamięć RAM, dyski, zasilacz i obudowa
Linux nie wymaga specjalnych modułów pamięci RAM – każdy zestaw wspierany przez płytę główną będzie działał. Liczy się ilość i taktowanie dostosowane do CPU, a także margines pod dual boot. Jeśli:
gry i Windows będą pochłaniać sporo RAM,
pod Linuksem planowane są maszyny wirtualne (np. Windows w VM, Docker, Kubernetes),
równocześnie działają przeglądarka, IDE, narzędzia developerskie,
to 16 GB staje się absolutnym minimum, a 32 GB pozwala pracować i grać bez dyktatu oszczędzania każdej aplikacji w tle.
Dyski wpływają na wygodę dual boot wprost. Warianty są dwa:
jeden dysk NVMe/SATA – na nim partycje Windows i Linux,
dwa lub więcej dysków – każdy system na osobnym nośniku.
Drugi scenariusz często upraszcza życie: instalator Windowsa „nie widzi” partycji Linuksa i nie próbuje ich ruszać, a Linux dostaje osobny dysk, który można dowolnie partycjonować (np. LVM, LUKS). Z punktu widzenia wydajności wiele zależy od tego, czy stosuje się szybkie NVMe (idealne dla systemów i gier) czy tańsze SATA (dobre na dane i archiwa).
Warto uwzględnić wpływ szyfrowania: BitLocker po stronie Windows i LUKS po stronie Linuksa nie zawsze dobrze współistnieją na jednym dysku, jeśli użytkownik nie ma jasnego planu. Najbezpieczniej wydzielić osobne przestrzenie, nie próbować „mieszać” szyfrowania na jednej partycji i nie stosować BitLocker na dysku, który Linux ma widzieć jako przestrzeń pod swoje partycje.
Zasilacz i obudowa pozornie nie mają związku z dual boot, ale niestabilne zasilanie potrafi generować „dziwne” problemy: losowe restarty, zawieszanie się systemu przy obciążeniu GPU, błędy na dyskach. Systemy typu Linux często są mniej wyrozumiałe dla uszkodzonych danych i szybciej wykażą problemy (np. błędy w journalu, fsck przy starcie). Dobry, markowy zasilacz z odpowiednim zapasem mocy i dobrze wentylowana obudowa to prosty sposób, by uniknąć niewytłumaczalnych „zwiech” podczas instalacji i późniejszej pracy.
Moduły WiFi/Bluetooth i karty sieciowe – planowanie pod Linux
Chipsety przyjazne Linuksowi
Przy łączu internetowym w kablu Ethernet zwykle wystarczy podpięcie przewodu i po sprawie. Natomiast WiFi w komputerze stacjonarnym bywa newralgicznym punktem przy pierwszym uruchomieniu Linuksa. Najważniejszy nie jest producent na pudełku (Asus, TP-Link, Gigabyte), ale konkretny chipset w środku.
Najczęściej spotykane chipsety to:
Intel – bardzo dobrze wspierane w Linuksie, sterowniki w kernelu, firmware w pakietach typu linux-firmware czy firmware-iwlwifi; zazwyczaj działają od razu po instalacji lub po zainstalowaniu pakietu firmware,
MediaTek (dawniej Ralink) – wsparcie z reguły niezłe, ale trzeba sprawdzić konkretny model,
Realtek – część modeli ma sterowniki w kernelu, ale część wymaga dodatkowych modułów (czasem zewnętrzne projekty, DKMS),
Broadcom – historycznie źródło wielu problemów, często wymagają dodatkowych własnościowych firmware’ów, niektóre modele są obsługiwane tylko przez archaiczne albo zamknięte sterowniki.
Pod względem „działa od razu” najlepszym wyborem jest zwykle WiFi Intela lub sprawdzone moduły MediaTek. Do wielu dystrybucji dołączone są paczki „firmware-linux”, które dostarczają niezbędne pliki binarne do działania karty. Jeśli dystrybucja stawia na „czystość” (np. domyślnie bez niewolnego firmware), trzeba ręcznie doinstalować pakiet z repozytorium albo przygotować instalacyjny pendrive z dodatkowym firmware.
Przy WiFi/Bluetooth „combo” wlutowanym w płytę główną lub w module M.2 sprawa jest podobna. Ten sam moduł obsługuje WiFi i BT, ale w Linuksie za każde z nich odpowiada inny sterownik i inny firmware. Zdarzają się sytuacje, że WiFi działa poprawnie, a Bluetooth ma problemy z parowaniem lub stabilnością, jeśli brakuje konkretnej wersji firmware.
PCIe vs M.2 vs USB
Karty WiFi do PC można spotkać w trzech formach: PCIe, M.2 (na płytach z gniazdem dla modułu) oraz dongle USB. Każde rozwiązanie ma swoje zalety i wady przy dual boot Windows/Linux.
Karty PCIe:
często z większymi antenami i lepszym zasięgiem,
moduł łatwo wymienić, jeśli okaże się problematyczny pod Linuksem – wystarczy odłączyć PC, wyjąć kartę i włożyć inną,
czasem zawierają w środku zwykły moduł M.2 przykręcony do płytki PCIe – co umożliwia także wymianę samego modułu.
Moduły M.2 w płytach głównych:
zaletą jest brak dodatkowej karty – czyste wnętrze obudowy,
gorszą stroną bywa trudniejsza identyfikacja modelu (nie zawsze jest łatwy dostęp),
wymiana zwykle wymaga rozkręcenia części komputera,
często stosowane są właśnie chipsety Intela – co jest dobre dla Linuksa.
Dongle USB:
najszybsze do wymiany – jeśli nie działa pod Linuksem, można dokupić inny model i podpiąć w sekundę,
czasem korzystają z tańszych, mniej wspieranych chipsetów,
mogą mieć gorszy zasięg i podatność na zakłócenia (szczególnie najmniejsze „pestki”).
Przed zakupem konkretnej karty WiFi/Bluetooth rozsądnie jest sprawdzić chipset w specyfikacji oraz opinie użytkowników Linuksa. Pomocne źródła to:
wiki dystrybucji (np. Arch Wiki ma bogate listy wspieranych urządzeń),
fora i listy mailingowe danej dystrybucji,
raporty z istniejącej maszyny (komendy lspci i lsusb dla działających urządzeń).
Jeśli w obecnym laptopie lub PC z Linuksem karta działa idealnie, można zidentyfikować chipset przez lspci -nn lub lsusb i szukać nowego sprzętu z tym samym układem.
Sieć przewodowa
Kontroler LAN jest zwykle mniej kłopotliwy niż WiFi. Najczęstsze układy to:
Intel – bardzo dobra obsługa w Linuksie, sterowniki w kernelu,
Realtek – szeroko stosowany, działający poprawnie, choć sporadycznie zdarzają się modele wymagające zewnętrznych modułów lub pracy nad wydajnością,
Specyfika LAN w płytach głównych i kartach rozszerzeń
Przy budowie nowego PC pod dual boot zwykle korzysta się z kontrolera LAN wbudowanego w płytę główną. W droższych modelach spotyka się jednak dodatkowe karty 10 GbE lub kontrolery oparte na mniej typowych układach. Z punktu widzenia Linuksa istotne jest, jaki dokładnie chipset obsługuje port RJ-45, a nie klasy marketingowe typu „Gaming LAN”.
Poza Intelem i Realtekiem można spotkać m.in.:
Broadcom/BCM – wsparcie w kernelu bywa, ale część starszych i serwerowych układów wymaga dodatkowych modułów lub firmware,
Marvell/Aquantia (często 2.5/5/10 GbE) – na ogół dobrze wspierane we współczesnych kernelach, ale na bardzo konserwatywnych dystrybucjach serwerowych może wymagać nowszego jądra,
Karty 10 GbE klasy serwerowej (Mellanox, Solarflare) – świetne w zastosowaniach profesjonalnych, pod warunkiem użycia dystrybucji z aktualnym kernelem i pełnym zestawem modułów.
Jeśli płyta główna wykorzystuje mniej typowy układ 2.5 GbE, dobrze jest sprawdzić go po identyfikatorze PCI (np. w specyfikacji lub na stronie producenta). W razie problemów stosunkowo łatwo dodać prostą kartę PCIe z układem Intela – pod Linuksem takie rozwiązanie zwykle działa bez żadnych dodatkowych zabiegów, również z włączonym Secure Boot.
Narzędzia diagnostyczne przy problemach z siecią na starcie
Przy pierwszym uruchomieniu Linuksa brak sieci często jest skutkiem braku firmware lub modułu jądra, rzadziej – awarii sprzętowej. Przydaje się kilka komend, które pozwalają zidentyfikować kartę i sprawdzić, czy kernel w ogóle ją widzi:
lspci -nn | grep -i network – identyfikacja kart WiFi i LAN na magistrali PCIe,
lsusb – dla dongli USB (WiFi, BT),
ip link lub ip a – lista interfejsów sieciowych, ich stan (UP/DOWN),
dmesg | grep -i firmware lub dmesg | grep -i wifi – komunikaty o brakującym firmware lub problemach z inicjalizacją.
Jeśli karta jest widoczna w lspci, ale nie ma interfejsu w ip link, zwykle oznacza to brak odpowiedniego modułu jądra lub konieczność jego załadowania (modprobe nazwa_modułu). Gdy zaś pojawiają się komunikaty „firmware: failed to load…”, rozwiązaniem jest instalacja odpowiedniego pakietu z firmware dla danej dystrybucji (np. linux-firmware, firmware-iwlwifi, firmware-realtek).
W środowisku dual boot przydaje się też szybkie porównanie konfiguracji między systemami. W Windowsie menedżer urządzeń i właściwości karty sieciowej umożliwiają sprawdzenie dokładnego modelu chipsetu (ID sprzętu), co później można skonfrontować z dokumentacją Linuksa czy wiki dystrybucji.
Źródło: Pexels | Autor: Ron Lach
Przygotowanie BIOS/UEFI do instalacji Windows i Linux
UEFI vs Legacy (CSM)
Współczesne zestawy praktycznie zawsze korzystają z firmware UEFI. Tryb Legacy (CSM) bywa jeszcze dostępny, ale powoduje więcej problemów niż korzyści, szczególnie gdy w grę wchodzą dwa systemy i Secure Boot. Najbezpieczniejszy wariant to:
włączenie trybu UEFI i wyłączenie CSM (Compatibility Support Module),
instalacja obu systemów w trybie UEFI, bez mieszania stylów partycjonowania (GPT, nie MBR),
jeden wspólny partycjonowany dysk GPT lub osobne dyski – ale zawsze w trybie UEFI.
Mieszanka typu: Windows w UEFI na GPT, Linux w trybie Legacy na MBR, kończy się trudnym do utrzymania zbiorem bootloaderów i koniecznością ręcznego wybierania dysków w menu boot. Jeśli płyta główna startuje w UEFI i dysk jest sformatowany jako GPT, Windows 10/11 oraz większość nowoczesnych dystrybucji Linuksa dogadują się bez specjalnych sztuczek.
Tryb SATA, NVMe i kontrolery RAID
Przy dyskach NVMe ustawienia w UEFI zwykle są proste – dysk jest widoczny jako urządzenie NVMe i tyle. Schody pojawiają się przy kontrolerach SATA, szczególnie gdy płyta oferuje tryb RAID dla Windows (Intel RST, AMD RAID):
dla dual boot zwykle lepiej pozostawić AHCI zamiast „RAID” lub „Intel RST”,
Windows w trybie RST może wymagać dodatkowych sterowników podczas instalacji, a Linux często widzi taki układ jako „fake RAID”, wymagający specjalnej konfiguracji (mdadm, dm-raid),
przestawienie kontrolera z RAID na AHCI po instalacji Windowsa bywa źródłem BSOD, jeśli wcześniej nie włączono obsługi AHCI w rejestrze.
Jeżeli plan jest prosty: jeden lub dwa dyski NVMe/SATA, Linux i Windows zarządzające nimi niezależnie, to AHCI jako tryb pracy kontrolera jest rozwiązaniem najmniej kłopotliwym. Sprzętowe lub pół-sprzętowe RAID-y mają sens głównie w wyspecjalizowanych konfiguracjach serwerowych.
Kolejność bootowania i zarządzanie bootloaderami
Na płytach z UEFI każdy system instaluje swój wpis w pamięci NVRAM: Windows Boot Manager, GRUB, systemd-boot i inne. Dobrą praktyką przy świeżej instalacji jest:
najpierw zainstalować Windows, który i tak nadpisze bootloader,
później zainstalować Linuxa, wybierając instalację bootloadera (GRUB, systemd-boot) w trybie UEFI,
w UEFI ustawić jako pierwszy wpis bootujący bootloader Linuksa, który zaoferuje także start Windowsa.
Jeśli zamiast jednego dysku są dwa, można doprecyzować: Windows i jego „Windows Boot Manager” na jednym NVMe, Linux i GRUB na drugim. Wówczas UEFI widzi dwa niezależne menedżery startowe, a użytkownik może albo ustawić preferowany, albo wywoływać menu „Boot Menu” (zwykle klawisze F8/F11/F12) i ręcznie wybierać dysk. Taki podział stanowi dodatkowe zabezpieczenie przed nadpisaniem bootloadera przez którąś z aktualizacji.
Wyłączanie funkcji utrudniających start Linuksa
Część płyt głównych oferuje dodatki przydatne z perspektywy Windowsa, które dla Linuksa są neutralne lub wręcz przeszkadzają. Chodzi m.in. o:
Fast Boot w UEFI – pomija część testów POST i nie zawsze poprawnie inicjalizuje wszystkie urządzenia; dla diagnostyki sieci, USB, NVMe lepiej go wyłączyć na czas instalacji,
ERP / tryby oszczędzania energii odcinające zasilanie od portów USB w stanie S5 – mogą powodować problemy z klawiaturą lub myszą w trakcie startu,
różne „tryby kompatybilności” dla USB, które na starszych płytach blokują pełną prędkość lub powodują konflikty z bootowaniem z pendrive.
Przy pierwszej instalacji Linuksa najlepiej mieć BIOS/UEFI ustawiony możliwie „standardowo”: UEFI-only, AHCI, wyłączony Fast Boot, domyślne ustawienia USB. Dodatkowe optymalizacje można włączać etapami po upewnieniu się, że oba systemy startują stabilnie.
Secure Boot w praktyce: jak działa i czego wymaga Linux
Co faktycznie robi Secure Boot
Secure Boot jest mechanizmem w UEFI, który:
weryfikuje podpisy cyfrowe komponentów uruchamianych podczas startu (bootloader, shim, kernel),
blokuje uruchomienie binariów bez zaufanego podpisu,
korzysta z bazy kluczy zapisanych w UEFI: PK (Platform Key), KEK (Key Exchange Key) i db/dbx (lista zaufanych i zablokowanych podpisów).
W praktyce, na domowych płytach, zestaw kluczy jest fabryczny: zaufane są podpisy Microsoftu i kilku dużych producentów OEM. Windows korzysta z tego bez dodatkowej konfiguracji. Linux, aby działał z włączonym Secure Boot, musi wpisać się w ten łańcuch zaufania – bezpośrednio lub pośrednio przez podpis Microsoftu.
Jak większość dystrybucji Linuksa współpracuje z Secure Boot
Najpopularniejszy model to tzw. shim:
UEFI uruchamia shim – mały bootloader podpisany kluczem zaakceptowanym przez Microsoft (a więc i przez firmware z fabrycznymi kluczami),
shim weryfikuje podpis GRUB-a lub innego bootloadera zgodnie z własną polityką zaufania,
bootloader uruchamia kernel Linuksa, który również może być podpisany lub weryfikowany.
Dystrybucje takie jak Ubuntu, Fedora, openSUSE czy RHEL dostarczają gotowy pakiet shim+GRUB+kernel z podpisami akceptowalnymi przy Secure Boot w trybie „fabrycznym”. Użytkownik zazwyczaj musi tylko:
pozostawić Secure Boot włączony,
upewnić się, że w UEFI załadowane są standardowe klucze fabryczne (MS/third-party),
nie włączać trybu „Custom Keys” bez potrzeby.
Przy tej konfiguracji system instaluje się i startuje podobnie jak Windows – UEFI ufa shimowi, shim ufa podpisanym przez dystrybucję plikom, użytkownik nie musi tworzyć własnej infrastruktury kluczy.
Secure Boot a zamknięte moduły jądra i sterowniki
Prawdziwe komplikacje zaczynają się, gdy Linux korzysta z modułów jądra, które:
nie są dostarczane przez dystrybucję w postaci gotowej, podpisanej paczki,
są kompilowane lokalnie (np. przez DKMS) – typowy przykład to sterowniki Nvidii lub niektóre sterowniki WiFi.
Secure Boot w trybie domyślnym nie pozwala na załadowanie niepodpisanego modułu jądra. To dotyczy zarówno zewnętrznego sterownika Nvidii, jak i własnoręcznie skompilowanego modułu do nietypowej karty sieciowej. W efekcie użytkownik obserwuje sytuację: system startuje, ale:
brak akceleracji 3D (bo moduł Nvidii nie mógł zostać załadowany),
brak WiFi (bo moduł do Realteka z DKMS został odrzucony),
brak funkcji wirtualizacji / narzędzi typu VirtualBox, jeśli ich moduły nie są podpisane.
Są trzy wyjścia:
Wyłączyć Secure Boot – najprostsze, ale oznacza rezygnację z ochrony przed wstrzyknięciem niepodpisanego kodu na etapie startu.
Korzystać wyłącznie z modułów podpisanych przez dystrybucję – możliwe, jeśli sterowniki Nvidii/WiFi/BT są dostarczane jako oficjalne, podpisane pakiety (nie każda dystrybucja to zapewnia).
Samodzielnie podpisać lokalnie kompilowane moduły – wymaga wygenerowania kluczy, wgrania klucza publicznego do UEFI (MOK) i podpisania modułów przed załadowaniem.
Podpisywanie własnych modułów (MOK, DKMS i narzędzia distro)
Model wykorzystywany w większości dystrybucji opiera się o MOK (Machine Owner Key):
klucz publiczny jest rejestrowany w systemie jako MOK (polecenie mokutil --import),
przy następnym starcie UEFI pojawia się specjalne menu, w którym użytkownik potwierdza dodanie klucza MOK do bazy zaufanych,
priv-key służy do podpisywania modułów jądra generowanych lokalnie.
Dystrybucje ułatwiają ten proces – przykładowo:
Ubuntu i pochodne automatycznie wywołują kreator MOK przy instalacji sterowników Nvidii z oficjalnych repozytoriów,
Fedora i RHEL wykorzystują narzędzia kmodsign wraz z integracją RPM/DKMS do podpisywania modułów podczas budowy.
Jeśli moduły powstają przez DKMS, ich kompilacja odbywa się przy każdej aktualizacji kernela. W takim scenariuszu skrypt DKMS musi po zakończeniu kompilacji wywołać proces podpisywania. W przeciwnym razie po aktualizacji jądra system uruchomi się, lecz wymagane moduły pozostaną niezaładowane, bo ich podpisy nie będą zgodne z zaufanymi kluczami.
Secure Boot a dystrybucje „bez niewolnego firmware”
Niektóre dystrybucje (szczególnie te stawiające na wolne oprogramowanie) domyślnie:
nie dołączają zamkniętych firmware’ów dla kart WiFi/Bluetooth,
nie pakują własnościowych sterowników GPU (Nvidia),
nie oferują podpisanych pakietów z binarnymi modułami.
W połączeniu z włączonym Secure Boot prowadzi to do sytuacji, w której:
WiFi nie działa po instalacji, bo firmware trzeba dodać ręcznie z zewnętrznego repozytorium,
Nvidia wymaga lokalnego DKMS i podpisywania modułów,
instalator w trybie „live” może nie mieć dostępu do sieci, jeśli korzysta wyłącznie z zamkniętego WiFi.
Jeśli komputer ma jednocześnie pełne wsparcie Windows + Linux i z góry wiadomo, że będą używane własnościowe sterowniki, zwykle lepszym wyborem jest dystrybucja, która:
Dobór dystrybucji przy włączonym Secure Boot i mieszanym sprzęcie
Jeśli komputer ma działać równolegle pod Windows i Linuxem, a Secure Boot pozostaje aktywny, wybór dystrybucji przestaje być wyłącznie kwestią gustu. Dobrze jest jasno określić:
czy potrzebne będą własnościowe sterowniki GPU (Nvidia, czasem AMD),
czy moduł WiFi/BT wymaga zamkniętego firmware,
czy sprzęt ma pracować w trybie „bez kombinowania” (desktop do pracy), czy dopuszczalne jest tworzenie własnej bazy kluczy i ręczne podpisywanie modułów.
Przy sprzęcie typowym dla desktopa (Nvidia, Intel WiFi, Realtek 2.5G LAN) i chęci utrzymania Secure Boot z minimalną ingerencją, najłatwiej żyje się z dystrybucjami, które:
instalują shim i podpisany kernel domyślnie,
mają w repozytorium oficjalne paczki ze sterownikami Nvidii lub firmware WiFi,
integrują proces MOK / podpisywania z instalatorem sterowników.
Dobrym wskaźnikiem są obrazy instalacyjne opisane jako „with non-free drivers” albo oddzielne ISO z dopiskiem „firmware”. Taki obraz zwykle zawiera już zestaw binariów dla popularnych kart WiFi/BT, co zmniejsza ryzyko, że instalator straci łączność w połowie procesu.
Kiedy wyłączyć Secure Boot mimo pracy z Windows
Są konfiguracje, w których utrzymywanie Secure Boot na siłę tylko komplikuje życie. Typowe przypadki to:
używanie dystrybucji „pure FOSS”, która nie integruje shim i podpisanego kernela,
konieczność ciągłej kompilacji własnych modułów (nietypowa karta TV, egzotyczny adapter WiFi, własne moduły korporacyjne),
zastosowania laboratoryjne / hobbystyczne, gdzie testuje się niestandardowe kernele.
W takich scenariuszach łatwiej po prostu przełączyć w UEFI Secure Boot: Disabled i traktować ochronę na etapie uruchamiania jako kwestię higieny systemów (szyfrowanie dysków, kontrola fizycznego dostępu) niż podpisów binariów. Windows 10/11 uruchomi się bez problemu z wyłączonym Secure Boot, o ile jest zainstalowany w trybie UEFI i nie ma dodatkowych polityk korporacyjnych wymagających jego włączenia.
Rozsądnym kompromisem bywa podejście: początkowo Secure Boot wyłączony, aby spokojnie zainstalować i skonfigurować Linuksa, a po ustabilizowaniu konfiguracji – ponowna aktywacja, połączona z przygotowaniem kluczy MOK i podpisaniem niezbędnych modułów.
Praktyczne problemy z WiFi przy Secure Boot i świeżej instalacji
Najbardziej widocznym skutkiem konfliktu Secure Boot + firmware jest brak WiFi tuż po pierwszym starcie Linuksa. Typowy scenariusz wygląda tak:
Instalator systemu korzysta z obrazu bez non-free firmware, więc moduł WiFi nie dostaje potrzebnego binarnego pliku.
Po instalacji system startuje z włączonym Secure Boot, kernel ładuje sterownik, ale ten zgłasza brak firmware.
Użytkownik nie ma dostępu do sieci, więc nie może w prosty sposób doinstalować brakujących paczek.
Można temu zapobiec kilkoma prostymi nawykami:
przygotować instalator na pendrive z obrazem zawierającym firmware (jeśli dystrybucja udostępnia osobne ISO),
podłączyć klasyczny adapter USB–Ethernet na czas instalacji – przeważnie działa bez dodatkowych sterowników,
trzymać na drugim pendrive paczki z firmware (np. katalog z .deb lub repozytorium offline) – przydaje się w środowiskach z ograniczonym internetem.
Jeśli komputer służy również pod Windows, prostym obejściem bywa tymczasowe udostępnienie sieci przez telefon (tethering USB) – zarówno Windows, jak i większość nowoczesnych dystrybucji Linuksa obsłuży takie połączenie bez dodatkowych sterowników, co pozwala pobrać brakujące firmware.
Współdzielenie sterowników WiFi/Bluetooth między Windows a Linuxem
Windows i Linux używają osobnych sterowników i firmware, nawet jeśli chodzi o ten sam moduł WiFi/BT na płycie głównej. Nie ma możliwości „pożyczenia” sterownika Windowsowego do Linuksa (narzędzia typu ndiswrapper to relikt przeszłości i nie powinny być brane pod uwagę przy nowym sprzęcie).
Przy planowaniu zestawu sensownie jest sprawdzić dwa niezależne źródła:
listę kompatybilności producenta dystrybucji lub wiki społeczności (np. „Linux wireless” + model chipsetu),
stronę producenta płyty głównej / laptopa – pod kątem informacji o dokładnym chipsecie (np. Intel AX200 vs AX210, różne rewizje Realteka).
Wyglądają podobnie na liście specyfikacji, ale pod Linuksem mogą korzystać z zupełnie innych sterowników i firmware. Dla przykładu, moduły Intel AX działają zazwyczaj bezproblemowo z nowymi kernelami, podczas gdy pewne warianty Realteka wymagają dodatkowych paczek z repozytoriów społecznościowych.
Dual boot z perspektywy aktualizacji firmware (BIOS/UEFI)
Producenci płyt i laptopów zakładają, że proces aktualizacji UEFI będzie wykonywany z poziomu Windowsa – oficjalne narzędzia są często dostępne wyłącznie jako .exe. W konfiguracji Windows + Linux można przyjąć kilka praktyk:
pozostawić małą partycję Windows choćby wyłącznie do aktualizacji firmware/storagów, jeśli reszta pracy odbywa się pod Linuksem,
korzystać z narzędzi do aktualizacji z poziomu UEFI (EZ Flash, M-Flash, Q-Flash), które przyjmują plik z pendrive FAT32 – eliminuje to zależność od Windowsa,
sprawdzić, czy sprzęt jest obsługiwany przez fwupd pod Linuksem – część laptopów i płyt wspiera aktualizacje UEFI / kontrolerów z poziomu GNOME/KDE.
Po aktualizacji firmware warto ponownie zajrzeć do ustawień Secure Boot i kolejności bootowania. Niektóre aktualizacje przywracają ustawienia „fabryczne”, co może włączyć Secure Boot na nowo, skasować wpisy bootloaderów (GRUB) albo zmienić domyślny boot order na Windows Boot Manager.
Różne schematy partycjonowania dla Windows i Linuxa
Przy jednym fizycznym dysku i dwóch systemach krytyczne jest poprawne rozplanowanie partycji, zwłaszcza w kontekście UEFI i Secure Boot. Sytuacja jest prostsza, gdy:
jako pierwszy powstaje Windows, który tworzy ESP (EFI System Partition) oraz własne partycje systemowe,
Linux podczas instalacji wykorzystuje istniejące ESP i dokłada własne wpisy bootloadera,
zostawia się nieco wolnego, nieprzydzielonego miejsca w czasie instalacji Windows – Linux potrafi je łatwo zagospodarować.
Spotyka się dwie główne strategie:
Współdzielona ESP – jedna partycja EFI, z której korzystają zarówno Windows Boot Manager, jak i GRUB/systemd-boot. Łatwiejsza w konfiguracji, ale trzeba uważać przy ręcznym czyszczeniu / porządkowaniu tej partycji.
Oddzielne ESP na dwóch dyskach – gdy Windows i Linux siedzą na osobnych nośnikach NVMe/SATA. Zwiększa to izolację, ale wymaga świadomego wyboru dysku startowego w UEFI lub ustawienia preferowanego bootloadera.
Jeśli przewidziane jest szyfrowanie (BitLocker po stronie Windows, LUKS po stronie Linuksa), ESP i partycje rozruchowe muszą pozostać nieszyfrowane, aby UEFI i bootloadery mogły wystartować kernel. W takim układzie Secure Boot jest jednym z elementów łańcucha zaufania – chroni przed podmianą kernela czy initramfs-u na poziomie ESP.
BitLocker, TPM i Secure Boot a Linux
Na nowszych platformach Windows często włącza BitLocker przy instalacji, jeśli wykryje moduł TPM 2.0 i aktywny Secure Boot. Przy konfiguracji dual boot ma to kilka konsekwencji:
partycja Windows jest szyfrowana i niewidoczna dla Linuksa bez odpowiedniego klucza odzyskiwania,
zmiana kolejności bootowania, kombinowanie z bootloaderem albo własne klucze Secure Boot mogą spowodować żądanie klucza odzyskiwania BitLockera,
niewłaściwe próby „naprawy” ESP mogą zostać potraktowane jako naruszenie integralności platformy.
Bezpieczna kolejność działań przy dual boot z BitLockerem wygląda tak:
zainstalować Windows, pozwalając mu skonfigurować TPM/Secure Boot/BitLocker,
zapisać i zarchiwizować klucz odzyskiwania BitLockera (np. na koncie Microsoft lub w menedżerze haseł),
zainstalować Linuksa, nie usuwając i nie formatując istniejącej ESP,
po instalacji sprawdzić, czy start przez GRUB nie wywołuje pytań o klucz BitLockera; jeśli tak – zaktualizować konfigurację zabezpieczeń w Windows (np. ponownie włączyć ochronę po zmianach).
Jeśli Linux ma mieć dostęp do danych z partycji Windows, wygodniej bywa wyłączyć BitLocker na partycji danych, pozostawiając szyfrowanie tylko na partycji systemowej C:. Alternatywą jest szyfrowanie po stronie Linuksa (LUKS) i trzymanie danych współdzielonych na nieszyfrowanej partycji NTFS lub exFAT.
Diagnostyka problemów przy starcie: kiedy winny jest Secure Boot
Przy mieszanym środowisku łatwo obwiniać Secure Boot za każdy nieudany start. Kilka objawów rzeczywiście wskazuje właśnie na niego:
system zatrzymuje się zaraz po UEFI z lakonicznym komunikatem o niepodpisanym obrazie lub od razu wraca do menu UEFI,
w logach kernela (dmesg) widać wpisy w stylu „Module signature verification failed”,
moduł sterownika (np. Nvidii) nie ładuje się, mimo że poprawnie się kompiluje i działał przy wyłączonym Secure Boot.
Podstawowy zestaw kroków diagnostycznych:
Sprawdzić w UEFI, czy Secure Boot jest w trybie „Standard / Windows UEFI mode”, czy może „Custom” z własnymi kluczami. W trybie „Custom” firmware może odrzucać nawet fabryczne podpisy.
Zweryfikować, czy dystrybucja uruchamia się przez shim (we wpisach UEFI / Boot Manager widać nazwę shimx64.efi lub podobną), a nie bezpośrednio przez niesygnowany GRUB.
Przejrzeć listę zarejestrowanych kluczy MOK: mokutil --list-enrolled. Jeśli klucz do podpisywania modułów nie jest tam widoczny, UEFI nie zaufa tym modułom.
Na próbę tymczasowo wyłączyć Secure Boot i sprawdzić, czy problem znika. Jeśli tak – trzeba wrócić do konfiguracji kluczy i podpisów.
W praktyce większość trudności wynika nie tyle z samego mechanizmu Secure Boot, co z braku spójności: część komponentów jest podpisana fabrycznym kluczem (shim, kernel), a część (moduły DKMS) – w ogóle lub innym, niezaimportowanym kluczem.
Planowanie sprzętu pod długie wsparcie Linuksa
Jeśli komputer ma służyć przez kilka lat bez konieczności wymiany komponentów, selekcja sprzętu powinna wybiegać poza bieżącą kompatybilność. Kluczowe parametry to:
obecność sterowników w głównym drzewie kernela (mainline) zamiast wyłącznie w zewnętrznych projektach,
wsparcie w długoterminowych gałęziach (LTS) – zarówno kernela, jak i dystrybucji,
unikanie całkowicie świeżych, zamkniętych rozwiązań (np. zupełnie nowych kart WiFi bez oficjalnego wsparcia w upstreamie).
W praktyce oznacza to preferowanie:
integrowanych grafik Intel lub AMD, jeśli nie jest potrzebna mocna Nvidia,
modułów WiFi Intel AX lub dobrze udokumentowanych rozwiązań Qualcomm/Atheros,
kontrolerów SATA/NVMe uznanych producentów, gdzie sterowniki od dawna są częścią kernela.
Przy takim podejściu Secure Boot i równoległa instalacja Windowsa stają się kwestią konfiguracji, a nie walki z niedopracowanymi sterownikami. Systemy aktualizują się niezależnie, a potencjalne problemy sprowadzają się do pojedynczych modułów wymagających ręcznego podpisu, a nie do całej platformy sprzętowej.
Najczęściej zadawane pytania (FAQ)
Jaki sprzęt najlepiej wybrać pod dual boot Windows + Linux?
Najbezpieczniejszy zestaw to: aktualna platforma AMD lub Intel, płyta główna z dopracowanym UEFI, karta graficzna AMD lub Intel (prostsze sterowniki pod Linuksem) oraz moduł WiFi oparty na chipsetach dobrze wspieranych w jądrze (np. Intel). Do tego co najmniej 16 GB RAM, a w praktyce 32 GB, jeśli planowane są gry, maszyny wirtualne lub cięższa praca developerska.
Jeśli sprzęt ma być „bezproblemowy”, unikaj bardzo nowych, świeżo wypuszczonych GPU i egzotycznych kart WiFi, do których brakuje jeszcze sterowników w kernelu lub firmware w dystrybucji. Stabilność i wsparcie w Linuksie są ważniejsze niż marginalnie wyższa wydajność w benchmarkach.
Czy do dual boota muszę mieć dwa osobne dyski, czy wystarczy jeden?
Nie musisz, ale dwa dyski upraszczają życie. Jeden dysk NVMe/SATA z podziałem na partycje dla Windows i Linuksa jest w pełni działającą opcją, jednak instalator Windowsa lubi nadpisywać bootloader i może skomplikować konfigurację rozruchu, jeśli coś pójdzie nie tak.
Przy dwóch dyskach sytuacja jest prostsza: każdy system ma własny nośnik, Windows nie miesza się w partycje Linuksa, a Linux może swobodnie używać np. LVM i LUKS. Łatwiej też zarządzać szyfrowaniem – unikasz konfliktu BitLockera z przestrzenią przeznaczoną na Linuksa.
Secure Boot a Linux – włączyć czy wyłączyć na nowym PC?
Jeśli używasz Nvidii z proprietarnym sterownikiem, najczęściej wygodniej jest Secure Boot wyłączyć, żeby uniknąć problemów z ładowaniem niepodpisanego modułu GPU. Alternatywą jest ręczne podpisywanie modułów jądra, ale to dodatkowa konfiguracja i serwis przy każdej zmianie kernela.
Przy GPU AMD/Intel i typowych dystrybucjach (Ubuntu, Fedora, openSUSE) Secure Boot zwykle działa bez ingerencji użytkownika, bo większość potrzebnych modułów jest już odpowiednio podpisana. W praktyce wiele osób zostawia Secure Boot włączony, o ile nie natrafiają na konkretny problem ze startem systemu lub sterownika.
Która karta graficzna jest najmniej problematyczna pod Windows + Linux?
Pod względem bezobsługowości w Linuksie przodują GPU AMD i zintegrowane układy Intela – sterowniki są w kernelu i Mesa, więc 3D działa „z pudełka”, bez instalacji zamkniętych pakietów. Warunek: w miarę nowy kernel i Mesa, co spełniają dystrybucje z szybszym cyklem aktualizacji.
Nvidia świetnie sprawdza się w Windows (gry, aplikacje), ale pod Linuksem wymaga zwykle instalacji własnościowego sterownika i uwzględnienia Secure Boot. Jeśli priorytetem jest komfort na Linuksie, a nie maksymalne FPS w każdym tytule, AMD/Intel to rozsądniejszy wybór. Jeśli stawiasz na Nvidię, miej z tyłu głowy konieczność konfiguracji sterowników po instalacji systemu.
Jak ustawić UEFI/BIOS pod instalację Windowsa i Linuksa na jednym PC?
Typowa, bezproblemowa konfiguracja to: tryb UEFI (bez CSM/Legacy), kontroler dysków ustawiony na AHCI (zamiast RAID/Intel RST), włączone TPM/fTPM dla zgodności z Windows 11, wirtualizacja VT-x/AMD-V oraz VT-d/IOMMU, jeśli planujesz maszyny wirtualne lub passthrough GPU. Taki zestaw ustawień dobrze współpracuje z większością współczesnych dystrybucji.
Jeśli płyta ma tylko tryb RAID/Intel RST, instalator Linuksa może nie widzieć dysku – w takim przypadku trzeba przełączyć kontroler na AHCI przed instalacją systemów (lub przebudować konfigurację Windowsa, gdy zmieniasz to po fakcie). UEFI warto też regularnie aktualizować, bo nowsze wersje często poprawiają problemy z NVMe, bootowaniem i mikrokodem CPU.
Jakie WiFi i Bluetooth wybrać, żeby Linux działał od razu po instalacji?
Najbezpieczniejszy wybór to moduły oparte na chipsetach Intela – są szeroko wspierane w jądrze Linuksa, często działają od pierwszego startu systemu, a przynajmniej wymagają jedynie doinstalowania standardowych pakietów firmware z repozytorium. Sprawdza się to zarówno w laptopach, jak i w kartach PCIe/M.2 do desktopów.
Więcej problemów sprawiają egzotyczne karty WiFi, szczególnie bardzo nowe modele, do których producent nie udostępnił jeszcze porządnych sterowników pod Linuksa lub wymaga ręcznego pobierania zamkniętego firmware. Jeśli składasz PC samodzielnie, lepiej dobrać płytę albo kartę WiFi, której chipset jest wyraźnie wymieniony jako wspierany w dokumentacji wybranej dystrybucji lub w wiki społeczności (np. ArchWiki).
Kluczowe Wnioski
Przy zestawie pod Windows i Linux priorytetem jest stabilność i kompatybilność sprzętowa, a nie maksymalna wydajność – im mniej egzotycznych podzespołów, tym mniej problemów z instalacją, sterownikami i Secure Boot.
Płyta główna i chipset decydują o tym, czy dual boot będzie bezproblemowy: istotne są dopracowane UEFI z aktualizacjami, obsługa trybu UEFI bez CSM, przełączanie kontrolera dysku w AHCI oraz poprawna konfiguracja TPM pod Windows 11.
Linux jest bardziej wrażliwy na dobór GPU i WiFi niż Windows; część kart graficznych i modułów sieciowych działa od razu z jądra, ale inne (szczególnie niektóre WiFi i najnowsze GPU) mogą wymagać nowszego kernela lub dodatkowych pakietów firmware.
Przy karcie Nvidii pod Linuksem wygodny gaming zwykle oznacza użycie sterowników proprietarnych, co często wymaga wyłączenia Secure Boot albo samodzielnego podpisania modułów jądra – bez tego system może w ogóle nie załadować sterownika.
GPU AMD i zintegrowane układy Intela są z reguły „łatwiejsze” dla Linuksa, bo korzystają z otwartych sterowników w kernelu i Mesa; kluczowe jest tylko to, by dystrybucja miała na tyle nowy kernel, by obsłużyć bieżącą generację kart.
Dla użytkowników wirtualizacji i bardziej zaawansowanych scenariuszy (np. passthrough GPU) konieczne jest wsparcie VT-x/AMD-V oraz VT-d/IOMMU w płycie głównej, najlepiej z jasnymi opcjami w UEFI, które można świadomie włączyć i skonfigurować.
