Dlaczego po zmianie dysku system wolniej się uruchamia historia pytania czytelnika

Historia pytania czytelnika: „zmieniłem dysk na lepszy, a komputer wstaje dłużej”

To jedno z tych zgłoszeń, które brzmi jak paradoks: ktoś wymienia stary dysk na nowy SSD albo NVMe, przenosi system (klonuje lub instaluje od zera), po czym… komputer zaczyna uruchamiać się wolniej. Czasem różnica jest subtelna, a czasem irytująca: dłuższy czarny ekran, dłuższe „kręcenie kółka” z logo systemu, a bywa, że pulpit pojawia się szybko, ale przez pierwszą minutę wszystko „muli”.

W praktyce najczęściej problemem nie jest „zły dysk”, tylko to, że zmiana nośnika porusza kilka warstw naraz: UEFI/BIOS przebudowuje listę urządzeń startowych, kontroler SATA/NVMe może przełączyć tryb pracy, system ładuje inny zestaw sterowników, a po klonowaniu potrafią zostać nieoczywiste ślady (dodatkowe wpisy rozruchowe, stary układ partycji, konflikt identyfikatorów, niepasujące usługi).

Klucz, który naprawdę skraca diagnostykę, jest prosty: złap moment, w którym start się wydłużył. Wolne „przed logo” i wolne „po logo” to zazwyczaj dwie różne historie. Jeśli komputer długo stoi na czarnym ekranie, to często winne jest UEFI/POST, kolejność bootowania albo inicjalizacja urządzeń. Jeśli długo mieli na logo Windows/Linux, wchodzą w grę sterowniki, bootloader, szyfrowanie. Jeśli zwalnia dopiero po zalogowaniu, zwykle przegrywasz z autostartem, usługami i pierwszymi zadaniami w tle (indeksowanie, synchronizacja chmury, skan AV).

Mit, który wraca jak bumerang: „SSD zawsze przyspiesza start”. Rzeczywistość jest bardziej uparta: SSD przyspiesza dostęp do danych, ale nie naprawia nieoptymalnej konfiguracji UEFI, nie przyspiesza błędnego skanowania urządzeń po USB, nie usuwa konfliktów po klonie i nie zmienia faktu, że system może czekać na usługę sieciową, sterownik kontrolera albo odszyfrowanie woluminu.

Drugi mit: „jak kręci się logo, to dysk wadliwy”. Częściej to sterownik kontrolera magazynu, źle wybrany tryb bootowania (UEFI/Legacy), dodatkowe wpisy w rozruchu lub procesy systemowe po migracji. Dysk też może zawinić, ale zwykle da się to złapać konkretnymi objawami (błędy SMART, zrywanie linku, throttling termiczny NVMe, problemy z portem/kablem).

Zanim zaczniesz: 7 pytań, które skracają diagnozę o połowę

Najwięcej czasu traci się na strzelanie: „to pewnie Windows”, „to pewnie BIOS”, „to pewnie nowy SSD”. Siedem pytań poniżej działa jak filtr. Odpowiedz sobie krótko i dopiero wtedy idź w ustawienia.

Mini-checklista startowa

1. Kiedy dokładnie jest wolniej? Przed logo systemu (czarny ekran/POST), na logo, czy po zalogowaniu?
2. Jaki dysk zamieniłeś na jaki? HDD → SATA SSD, SATA SSD → NVMe, a może NVMe → inny NVMe?
3. Jak jest podłączony nowy nośnik? SATA 2,5″, M.2 SATA, M.2 NVMe, a może przez adapter/przejściówkę?
4. System był klonowany czy instalowany od zera? Jeśli klon: czy przeniosłeś też partycję EFI/Recovery?
5. Zmieniłeś coś w UEFI/BIOS? CSM/Legacy, Secure Boot, Fast Boot, kolejność bootowania, tryb kontrolera?
6. Czy działa szyfrowanie lub „ochrona” dysku? BitLocker (Windows), LUKS (Linux), „pełny skan” AV, narzędzia antyransomware?
7. Problem jest stały czy losowy? Tylko po aktualizacjach, tylko z podpiętym USB, tylko po dłuższym wyłączeniu, a po restarcie jest OK?

Co te odpowiedzi mówią od razu

Jeśli spowolnienie jest przed logo, zwykle nie ma sensu grzebać w autostarcie Windows ani w usługach Linuksa — tam system jeszcze nie wystartował. Jeśli jest na logo, podejrzewasz warstwę rozruchu, sterowniki magazynu, szyfrowanie, ewentualnie problemy z linkiem/trybem dysku. Jeśli jest po zalogowaniu, dysk może być niewinny, a winna będzie lista programów i usług uruchamianych wraz z użytkownikiem.

Dwie krótkie, realistyczne sytuacje „po wymianie dysku”

Przypadek 1 (laptop, klon): wymiana HDD na SATA SSD, klonowanie „1:1”, a po wszystkim komputer wisi długo na czarnym ekranie przed logo. Często okazuje się, że UEFI próbuje startować z innego wpisu (starego boot managera), skanuje USB albo ma bałagan w kolejności bootowania.

Przypadek 2 (PC, NVMe): nowy NVMe działa, ale trafił do slotu M.2, który współdzieli linie albo ma ograniczoną konfigurację. System się podnosi, jednak etap ładowania i logowania jest odczuwalnie dłuższy. Tu winny bywa zły slot M.2, sterownik kontrolera albo firmware/temperatura NVMe, a nie sam Windows.

Wskazówka 1 — Ustal, w którym momencie start „stoi”: POST/UEFI vs bootloader vs system vs autostart

Najbardziej użyteczna obserwacja w całej historii brzmi: co dokładnie widzisz na ekranie, kiedy jest wolno. To nie jest drobiazg — to mapa. Ten sam „wolny start po wymianie dysku” może mieć cztery różne przyczyny, zależnie od etapu.

Szybki test „na ucho i oko” (bez narzędzi)

Podziel start na cztery odcinki:

• Odcinek A: od włączenia do pojawienia się logo producenta/UEFI — jeśli tu jest długo, szukasz w UEFI/BIOS, inicjalizacji sprzętu, kolejności bootowania, urządzeń USB.
• Odcinek B: od logo UEFI do logo systemu (Windows/Linux) — jeśli tu trwa wieczność, często UEFI szuka nośnika, próbuje różnych wpisów lub jest konflikt bootowania UEFI/Legacy.
• Odcinek C: logo systemu i „kręcenie” — to moment ładowania sterowników, usług krytycznych, czasem odszyfrowania woluminu.
• Odcinek D: pulpit po zalogowaniu — tutaj króluje autostart, indeksowanie, synchronizacje, skan antywirusa, aktualizacje, telemetria, usługi producenta laptopa.

Jeśli jesteś w stanie wskazać jeden odcinek jako winowajcę, połowę roboty masz z głowy.

Minimalna diagnostyka w Windows: bez „optymalizatorów”

W Windows da się złapać przyczynę bez instalowania cudownych przyspieszaczy:

• Menedżer zadań → Uruchamianie: sortuj po „Wpływie na uruchamianie”. Jeśli po zmianie dysku system jest „żywy”, ale po pulpicie długo nie reaguje, to pierwszy trop.
• Podgląd zdarzeń: dziennik „Microsoft-Windows-Diagnostics-Performance/Operational” (czasem trzeba go wyszukać w drzewie). Szukaj zdarzeń związanych z długim startem i elementów, które opóźniały boot lub logon.
• Porównanie: zimny start vs restart: jeśli po restarcie jest szybko, a po pełnym wyłączeniu wolno, część winy może leżeć w Fast Startup/hibernacji, inicjalizacji urządzeń lub aktualizacjach firmware.

Ważne: długi czas startu nie zawsze oznacza problem z dyskiem. Jeśli w logach widać opóźnienia usług sieciowych, sterownika audio, modułów producenta laptopa, to dysk może tylko „uczciwie” ujawniać bałagan w oprogramowaniu.

Minimalna diagnostyka w Linux: trzy komendy, które naprawdę coś mówią

W dystrybucjach z systemd najszybciej idzie tak:

• systemd-analyze — pokazuje łączny czas boot i rozbicie na firmware/loader/kernel/userspace (świetne do rozróżnienia „przed systemem” i „w systemie”).
• systemd-analyze blame — lista usług, które trwały najdłużej (uwaga: nie zawsze blokowały start, ale daje tropy).
• journalctl -b — logi z bieżącego rozruchu; szukaj timeoutów, retry, czekania na urządzenia.

Jeśli firmware/loader zajmuje dużo, wracasz do UEFI/BIOS. Jeśli userspace jest ciężki, szukasz usług i zależności. Gdy w logach pojawiają się time-outy dysku, dopiero wtedy zaczyna się sensowna rozmowa o kablu, porcie, kontrolerze, firmware lub błędach nośnika.

Wskazówka 2 — Jeśli długo przed logo: UEFI/BIOS szuka dysku nie tam, gdzie trzeba

Wolny etap „przed logo systemu” jest zaskakująco częsty po wymianie dysku. UEFI potrafi przestawić priorytety, dodać nowe wpisy, próbować startu z sieci, skanować porty USB albo wykrywać urządzenia masowe, których… już nie ma. To daje klasyczny objaw: komputer niby działa, ale pierwsze kilkanaście–kilkadziesiąt sekund to czarny ekran lub ekran „detecting…”.

Kolejność bootowania, zbędne wpisy, pendrive’y i dyski USB

Po zmianie dysku wejdź do UEFI/BIOS i sprawdź:

• Boot Order: na pierwszym miejscu powinien być właściwy wpis typu „Windows Boot Manager” (lub nazwa bootloadera Linuksa), a nie „UEFI: USB”, „Network”, „P0:…” lub stary dysk.
• Zbędne wpisy UEFI: po klonowaniu czasem zostają dwa podobne wpisy, a UEFI próbuje pierwszego, nie udaje się, dopiero potem łapie drugi. Efekt: opóźnienie, którego nie widać w systemie.
• Urządzenia zewnętrzne: odłącz na próbę pendrive, dysk USB, czytnik kart, czasem nawet dongle od klawiatury/myszy. Jeśli start nagle przyspiesza, masz winowajcę: UEFI „maca” po USB i traci czas.
• PXE/Network Boot: jeśli jest włączone bootowanie z sieci, UEFI potrafi czekać na odpowiedź, której w domu nie dostanie.

Praktyczny test A/B: ustaw poprawny wpis rozruchu na pierwszym miejscu, wyłącz Network Boot, na próbę odłącz USB i zobacz, czy zmiana jest natychmiastowa. Jeśli tak — nie dotykasz w ogóle Windows/Linux, bo problem był przed systemem.

CSM/Legacy vs UEFI, Secure Boot, Fast Boot i inicjalizacja urządzeń

Po wymianie dysku (zwłaszcza gdy wcześniej był stary układ partycji) zdarza się, że komputer startuje w trybie mieszanym. Kilka rzeczy, które realnie wpływają na czas:

• CSM/Legacy: gdy jest włączone, UEFI może wykonywać dodatkową inicjalizację kompatybilnościową. W wielu konfiguracjach UEFI + poprawna partycja EFI daje stabilniejszy i szybszy start. Jeśli system jest zainstalowany jako UEFI, rozważ wyłączenie CSM.
• Secure Boot: zwykle nie spowalnia dramatycznie, ale bywa, że po migracji lub zmianie bootloadera pojawiają się dodatkowe weryfikacje albo „fallback” na inne wpisy. Jeśli testujesz, rób to świadomie i pamiętaj o konsekwencjach bezpieczeństwa.
• Fast Boot: czasem przyspiesza, czasem przeszkadza — szczególnie po zmianach sprzętowych. Jeśli po wymianie dysku start zrobił się dziwnie długi, zrób test: Fast Boot włączony vs wyłączony.
• Inicjalizacja USB/Storage: część UEFI ma opcje „pełnej inicjalizacji” urządzeń USB lub dodatkowych kontrolerów. Przy problemach „przed logo” wyłączenie zbędnych opcji potrafi skrócić czas.

Mit vs rzeczywistość: „Fast Boot zawsze pomaga”. W praktyce, jeśli UEFI ma kłopot z enumeracją urządzeń po zmianie dysku albo próbuje kilku ścieżek startu, Fast Boot potrafi zachowywać się kapryśnie i zamiast skracać — wydłuża.

Wskazówka 3 — Sprawdź, czy dysk działa z właściwą prędkością i w dobrym porcie/slocie

Zaskakująco wiele „wolnych uruchomień po wymianie dysku” sprowadza się do tego, że nowy nośnik działa, ale nie w takich warunkach, jak zakładasz: wpięty do wolniejszego portu, ograniczony przez kontroler, pracuje w innym trybie albo NVMe siedzi w slocie o innych liniach PCIe. System niby jest na SSD, ale start i ładowanie usług czujesz jakby „coś go trzymało”.

SATA: kabel, port, negocjacja SATA 2/3, tryb AHCI

Dla SATA lista kontrolna jest krótka, ale konkretna:

• Port SATA: na płytach głównych bywają porty z chipsetu (zwykle najlepsze) oraz porty z dodatkowego kontrolera (czasem wolniejsze, czasem z innymi sterownikami). Jeśli po wymianie dysku przepiąłeś kabel „byle gdzie”, start mógł ucierpieć.
• Kabel SATA: uszkodzony lub kiepski kabel może powodować retry, renegocjację prędkości, błędy CRC. To nie zawsze wywali system, ale potrafi dokładać opóźnienia.
• Negocjacja prędkości: zdarza się, że dysk dogaduje się jako wolniejsze SATA (albo zrywa link i wraca niżej). Tu pomogą narzędzia producenta SSD lub odczyt atrybutów/zdarzeń kontrolera.

„`html

• Tryb kontrolera (AHCI/RAID/IDE): po przepięciu dysku albo aktualizacji BIOS zdarza się, że tryb kontrolera zmienia się na RAID/Intel RST lub (w starszych płytach) na IDE. Czasem system działa „normalnie”, ale sterownik robi swoje obejścia i pojawiają się mikroprzycięcia lub dłuższe etapy ładowania.

Mit: „jak to SSD, to nie ma znaczenia, gdzie go podepnę”. Rzeczywistość: port z dodatkowego kontrolera albo tryb kontrolera potrafią dołożyć opóźnień, bo sterowniki i inicjalizacja urządzeń działają inaczej niż na głównych liniach z chipsetu. W praktyce diagnoza bywa prosta: przepinasz dysk na inny port SATA (najlepiej ten „pierwszy” z chipsetu), podmieniasz kabel i od razu widzisz, czy czas startu wraca do normy.

Jeśli podejrzewasz retry/błędy transmisji, patrz na sygnały pośrednie: w Podglądzie zdarzeń Windows (System) przewijają się ostrzeżenia od storahci/stornvme, „reset to device”, „The IO operation was retried” itp. W Linuksie analogicznie: w dmesg widać timeouty i reset linku SATA. Dysk może być w pełni sprawny, a problem siedzi w kablu albo w porcie, który łapie zakłócenia.

NVMe/M.2: linie PCIe, slot „od chipsetu” vs „od CPU” i tryby oszczędzania energii

Przy NVMe najczęstsza pułapka to nie „wolny dysk”, tylko slot o innych parametrach. Na wielu płytach jeden M.2 idzie liniami z CPU (zwykle najmniej kompromisów), a drugi przez chipset, czasem dzieląc pasmo z SATA albo wyłączając konkretne porty. Efekt uboczny potrafi być zaskakujący: dysk teoretycznie szybki, ale start systemu dłuższy, bo firmware i sterownik dłużej enumerują magistralę albo kontroler przechodzi przez dodatkowe etapy inicjalizacji.

Mit: „NVMe zawsze wstaje błyskawicznie”. Rzeczywistość: niektóre konfiguracje M.2 potrafią opóźniać POST/UEFI, szczególnie gdy płyta ma ustawione dłuższe treningi PCIe, a do tego dochodzi kompatybilność z konkretnym kontrolerem NVMe. Jeśli czas „przed logo” wydłużył się po przełożeniu dysku do innego slotu — to nie Windows „mulii”, tylko firmware. Często pomaga aktualizacja BIOS/UEFI oraz upewnienie się, że slot działa w oczekiwanym trybie (np. PCIe x4, a nie x2) i że nie wchodzi w konflikt z wyłączanymi portami.

Drugi, bardziej „systemowy” haczyk to oszczędzanie energii. Agresywne stany zasilania NVMe (ASPM/L1.2) czasem powodują opóźnienia przy wybudzaniu urządzenia podczas startu usług. Nie chodzi o to, by od razu wyłączać wszystkie oszczędzacze, tylko o test: jeśli po zmianie ustawień zasilania (plan zasilania w Windows / parametry ASPM w BIOS) start się stabilizuje, wiadomo, gdzie drążyć.

Gdy znasz odcinek, na którym start się wydłuża, decyzje robią się proste: w UEFI porządkujesz kolejność boot i inicjalizację, w systemie czyścisz autostart i usługi, a w sprzęcie pilnujesz portu/slotu i trybu kontrolera — bez „magicznych” narzędzi, za to z jednym konkretnym testem po każdej zmianie.

Wskazówka 4 — Po klonowaniu system startuje wolniej: sprawdź ścieżkę rozruchu i „porządek” partycji

Po migracji 1:1 (klon) system potrafi wstać, ale robi to w bardziej okrężny sposób: raz ładuje się z właściwego wpisu UEFI, a raz próbuje po drodze starych śladów. Objaw bywa mylący, bo dysk jest szybki, a jednak logo Windows kręci się dłużej niż przed wymianą.

Boot Manager wskazuje nie tam, gdzie trzeba

Najprostszy przypadek: w UEFI masz poprawnie ustawione „Windows Boot Manager”, ale Windows ma kilka wpisów rozruchu i łapie nieoptymalny. Szybki test w Windows:

• msconfig → Rozruch: jeśli widzisz dwa podobne wpisy systemu, usuń ten nieużywany (ostrożnie — usuwa się tylko ten, którego nie używasz do startu).
• bcdedit: w wierszu poleceń jako administrator sprawdź, czy device i osdevice wskazują na właściwą partycję. Po klonowaniu zdarzają się „duchy” po starym dysku.

Przykład z życia serwisowego: laptop po klonie startuje dłużej, bo UEFI ma dwa wpisy „Windows Boot Manager”, pierwszy wskazuje na nieistniejącą już partycję EFI, dopiero drugi działa. System „przed logo” wygląda normalnie, ale samo przejście do ładowania Windows dostaje stałą zwłokę.

Mit: „Skoro klon się uruchamia, to boot jest ustawiony idealnie”. Rzeczywistość: może być „wystarczająco dobrze”, ale nadal robić objazdy, które dodają kilkanaście sekund.

Partycja EFI/Recovery: podwójne kopie i błędne wskazania

Po klonowaniu na większy dysk często lądują zdublowane partycje EFI albo Recovery w dziwnym miejscu. To zwykle nie psuje pracy systemu, ale potrafi:

• wydłużać start, bo firmware próbuje startu z „pierwszej lepszej” EFI,
• komplikować aktualizacje (Windows Update czasem lubi mieć jasny układ partycji),
• robić bałagan w narzędziach naprawczych.

Jeśli widzisz w „Zarządzaniu dyskami” kilka małych partycji EFI (FAT32) lub Recovery i nie masz pewności, która jest aktywna — nie strzelaj w ciemno z usuwaniem. Lepiej najpierw potwierdzić, z której EFI faktycznie startuje UEFI (wpisy rozruchu) i dopiero wtedy porządkować.

Wskazówka 5 — Jeśli długo kręci się logo systemu: sterownik kontrolera i tryb I/O mogą być nieoptymalne

Etap „logo Windows / czarny ekran z kropkami” to często moment, w którym system zaczyna intensywnie rozmawiać z dyskiem przez sterownik kontrolera. Po zmianie nośnika (albo po aktualizacji BIOS) potrafi się zmienić sterownik, tryb pracy, a nawet to, czy system używa bufora zapisu tak jak powinien.

Windows: sprawdź, czy nie jedziesz na „standardowym” sterowniku, który robi obejścia

W Menedżerze urządzeń zerknij na:

• Kontrolery IDE ATA/ATAPI (dla SATA) lub Kontrolery magazynu (dla NVMe),
• czy urządzenie nie działa na czymś bardzo ogólnym, gdy producent płyty/laptopa ma dedykowany sterownik (np. Intel RST/AMD SATA/NVMe).

Nie ma zasady „dedykowany zawsze lepszy”. Czasem wprost odwrotnie — Microsoftowy sterownik bywa stabilniejszy. Sensowny ruch to test A/B: aktualizacja sterownika chipsetu/kontrolera z witryny producenta i obserwacja, czy znika opóźnienie przy logo.

Linuks: initramfs i sterowniki po migracji

W Linuksie po zmianie dysku albo kontrolera (np. SATA → NVMe) zdarza się, że initramfs ma stare moduły i czeka na urządzenie pod dawną nazwą. Objawy:

• dłuższa pauza tuż przed pojawieniem się ekranu logowania,
• timeouty w journalctl -b lub dmesg na urządzenia, których już nie ma.

Praktyczny sens: jeśli w logach widzisz czekanie na /dev/sda, a system jest już na /dev/nvme0n1, to nie „wolny SSD”, tylko start, który czeka aż zegar tyknie. Aktualizacja initramfs i uporządkowanie wpisów w /etc/fstab oraz parametrów bootowania potrafią skrócić rozruch radykalnie.

Mit: „Sterowniki dysku nie mają znaczenia, bo to tylko start”. Rzeczywistość: w czasie startu dzieje się masa małych operacji I/O, a każdy retry, timeout albo nieoptymalny sterownik mnoży opóźnienia.

Wskazówka 6 — Jeśli najgorzej jest po zalogowaniu: autostart, indeksowanie, chmura i AV mogą zajechać nawet szybki dysk

Klasyczny scenariusz: ekran logowania pojawia się szybko, hasło wchodzi, a potem pulpit „dochodzi do siebie” długo. Po wymianie dysku łatwo pomylić przyczynę — to nie rozruch, tylko dobijanie systemu usługami, które wystartowały równocześnie.

Windows: trzy miejsca, które najszybciej zawężają winnego

• Menedżer zadań → Uruchamianie: wyłącz na próbę ciężkie pozycje (komunikatory, launchery, narzędzia producenta), restart i porównanie czasu do „używalnego” pulpitu.
• Menedżer zadań → Wydajność → Dysk: jeśli po zalogowaniu dysk ma 100% aktywności przy niskim transferze, to zwykle nie „za wolny SSD”, tylko dużo drobnych operacji (AV, indeks, OneDrive, aktualizacje).
• Monitor zasobów: posortuj po „Łącznie (B/s)” i zobacz, kto mieli dysk. Jedna konkretna usługa daje konkretną decyzję.

Typowe winowajcy po migracji: ponowne indeksowanie, synchronizacja chmury po zmianie ścieżek, oraz antywirus, który po wykryciu „nowego dysku” robi pełny skan. To może trwać, ale powinno się uspokoić po 1–2 restartach. Jeśli trwa stale — wtedy dopiero ma sens grzebać głębiej.

Szyfrowanie i kompresja: działa, ale start „puchnie”

BitLocker/LUKS same w sobie nie muszą zabijać startu, ale w kilku sytuacjach potrafią dołożyć czasu:

• gdy po klonowaniu system ponownie „przelicza” stan ochrony i wykonuje operacje w tle,
• gdy sterowniki TPM/UEFI robią dodatkowe weryfikacje (zwłaszcza po zmianach w firmware),
• gdy w tle odpala się skan AV na zaszyfrowanych plikach + synchronizacja chmury.

Mit: „Szyfrowanie to zawsze jedyny winny wolnego startu”. Rzeczywistość: częściej winne jest spiętrzenie kilku ciężkich rzeczy naraz. Jeden restart po drugim potrafi wyglądać zupełnie inaczej, gdy aktualizacje skończą mielić.

Wskazówka 7 — Zmierz czas startu, zamiast oceniać „na oko”: jeden raport daje konkretne tropy

Jeśli problem jest „raz szybko, raz wolno”, przydaje się twardy punkt odniesienia. W Windows masz prosty wskaźnik, który rozdziela: czy wolno jest w kernelu, czy po zalogowaniu.

Windows: „Czas ostatniego uruchomienia systemu BIOS” i zdarzenia rozruchu

• Menedżer zadań → Uruchamianie: zobacz Czas ostatniego uruchomienia systemu BIOS. Jeśli jest wysoki — wracaj do ustawień UEFI/boot i inicjalizacji urządzeń.
• Podgląd zdarzeń → Dzienniki aplikacji i usług → Microsoft → Windows → Diagnostics-Performance → Operational: zdarzenia rozruchu (np. 100/101) wskazują, co realnie opóźnia start i które usługi „przeginają”.

Praktyczny sens: zamiast kręcić śrubkami we wszystkich miejscach naraz, widzisz, czy problem siedzi przed Windowsem, w trakcie ładowania, czy po zalogowaniu. To oszczędza godziny.

Linux: systemd-analyze i logi bez zgadywania

Jeśli używasz systemd:

• systemd-analyze pokaże łączny czas kernel + userspace,
• systemd-analyze blame i systemd-analyze critical-chain wskażą jednostki, które realnie blokują start.

Gdy na liście wysoko ląduje montowanie dysku, sieć, swap albo usługa czekająca na nieistniejące urządzenie — masz konkret: poprawić fstab, wyłączyć „wait online”, naprawić UUID, a nie wymieniać SSD „bo pewnie trefny”.

Jedna zasada trzyma to w ryzach: po każdej zmianie rób pojedynczy test A/B (restart i pomiar) i nie zmieniaj trzech rzeczy naraz. Wtedy naprawdę da się dojść, czy problem leży w firmware, w ścieżce rozruchu, czy w tym, co startuje już na pulpicie.

Wskazówka 8 — Upewnij się, że nowy nośnik nie siedzi w „wolnym” slocie albo na adapterze, który dławi

To jeden z częstszych numerów po przesiadce na M.2: dysk jest szybki, ale zamontowany tak, że działa w trybie awaryjnym albo na ograniczonej liczbie linii PCIe. System się uruchomi, tylko „mieli” dłużej na etapie logo i przy logowaniu.

Jak to rozpoznać bez zgadywania

• NVMe: w narzędziu producenta SSD lub w HWiNFO/CrystalDiskInfo sprawdź PCIe Link Speed i Link Width (np. x4 vs x2). Jeśli widzisz niżej niż oczekujesz — to nie magia, tylko ograniczenie slotu/ustawień.
• M.2 SATA vs M.2 NVMe: nie każdy slot M.2 obsługuje oba standardy. Jeśli dysk „pasuje fizycznie”, a działa wolno, upewnij się w specyfikacji płyty/laptopa, że slot jest właściwego typu.
• Adaptery USB / kieszenie / przejściówki: jeśli klonowałeś system z dysku podpiętego przez USB albo testujesz start z zewnętrznego nośnika, czasy rozruchu potrafią być kompletnie inne niż na SATA/NVMe.

Przykład praktyczny: laptop ma dwa sloty M.2, ale jeden jest podłączony „oszczędnie” (mniej linii lub przez chipset z dodatkowymi opóźnieniami). Użytkownik przenosi dysk do wolniejszego gniazda, bo „łatwiej się wkłada”, a potem dziwi się, że Windows wstaje dłużej mimo lepszego SSD.

Mit: „Skoro NVMe, to zawsze będzie błyskawicznie”. Rzeczywistość: NVMe w złym slocie albo na x2 potrafi zachowywać się tak, że w rozruchu nie czujesz przewagi, a czasem jest nawet gorzej przez dodatkowe opóźnienia inicjalizacji.

Wskazówka 9 — Sprawdź, czy TRIM działa i czy klon nie zostawił krzywych ustawień partycji

Po klonowaniu systemu na nowy dysk (zwłaszcza z narzędzi „1:1”) czasem zostaje bałagan, który nie zabija wydajności w benchmarku, ale potrafi dopiec w codziennym I/O — a start systemu to właśnie tysiące małych odczytów.

Windows: dwa szybkie testy, które realnie coś mówią

• TRIM: w CMD jako administrator uruchom fsutil behavior query DisableDeleteNotify. Wynik 0 zwykle oznacza, że TRIM jest aktywny (dla SSD/NVMe).
• Optymalizacja dysków: wpisz w Start Defragmentuj i optymalizuj dyski i sprawdź, czy dysk jest rozpoznany jako SSD oraz czy harmonogram optymalizacji działa sensownie.

Praktyczny sens: jeśli TRIM jest wyłączony albo system traktuje SSD „dziwnie”, dysk szybciej łapie zadyszkę przy wielu drobnych operacjach — a to widać szczególnie podczas rozruchu i logowania.

Ostrożnie z „optymalizatorami”

Po migracji łatwo trafić na poradę „wyłącz to, to i tamto, bo SSD”. W realnym świecie część takich tweaków jest z epoki Windows 7 i potrafi bardziej zaszkodzić niż pomóc (np. wyłączanie usług bez zrozumienia zależności). Lepiej najpierw ustalić etap, na którym start zwalnia, i dopiero wtedy zmieniać jedną rzecz.

Mit: „Defragmentacja zawsze psuje SSD”. Rzeczywistość: Windows na SSD robi głównie optymalizację (TRIM), a nie klasyczną defragmentację jak na HDD. Problemem bywa raczej wyłączony TRIM albo narzędzie, które miesza w ustawieniach magazynu.

Wskazówka 10 — Gdy wolno jest tylko czasem: szukaj powtarzalnych wyzwalaczy (USB, sieć, aktualizacje)

Start „raz szybki, raz tragedia” zwykle nie oznacza, że dysk jest losowo wadliwy. Częściej system albo firmware czeka na coś, co czasem jest dostępne, a czasem nie.

Typowe wyzwalacze i proste próby kontrolne

• Podpięte USB: odłącz na próbę wszystko poza klawiaturą/myszką i sprawdź, czy czas „przed logo” wraca do normy. Firmware potrafi tracić czas na inicjalizację nośników, czytników kart, dongli, a nawet stacji dokujących.
• Sieć / mapowane dyski: jeśli po zalogowaniu pulpit wisi, a w tle są zasoby sieciowe, sprawdź, czy system nie czeka na niedostępny udział. W Windows tropem bywa Podgląd zdarzeń + opóźnione uruchamianie usług sieciowych.
• Aktualizacje: po zmianie dysku Windows potrafi odpalić serię aktualizacji sterowników i przebudowy komponentów. Jeden rozruch może być „ciężki”, kolejny już normalny. Jeśli ciężkie starty trwają tydzień — to inna historia.

Przykład z praktyki: komputer uruchamia się wolno tylko wtedy, gdy zostawisz wpięty pendrive „ratunkowy”. UEFI próbuje go potraktować jako pierwszy nośnik, robi timeout i dopiero potem przechodzi na dysk systemowy. Z poziomu użytkownika wygląda to jak „Windows po wymianie dysku zwolnił”, a to po prostu kolejność bootowania i zachowanie firmware.

Wskazówka 11 — Zaktualizuj firmware SSD i BIOS/UEFI, ale rób to z głową

Po wymianie dysku dochodzi jeszcze jedna warstwa: kompatybilność firmware dysku z kontrolerem i UEFI. Czasem trafia się wersja, która działa, ale ma dziwne opóźnienia podczas inicjalizacji lub zarządzania energią.

Co ma sens w praktyce

• Firmware SSD: sprawdź narzędzie producenta (Samsung Magician, Crucial Storage Executive, WD Dashboard itd.). Jeśli jest aktualizacja, przeczytaj opis zmian — bywa, że dotyczy stabilności/latencji.
• BIOS/UEFI: aktualizuj głównie wtedy, gdy producent wspomina o poprawkach NVMe/storage/boot, albo gdy widzisz nietypow