Dmesg Linux – jak analizować logi startowe i błędy sprzętu

Polecenie dmesg w Linuxie pokazuje bufor komunikatów jądra (kernel ring buffer), czyli m.in. logi startowe systemu i błędy sprzętowe. To jedno z podstawowych narzędzi do diagnozowania problemów przy starcie, z dyskami, RAM‑em, kartą sieciową, grafiką czy innymi urządzeniami.

Poniżej znajdziesz gotowy, rozbudowany poradnik po polsku – do publikacji na stronie o internecie i technologiach – jak używać dmesg, jak czytać logi startowe, jak wyłapywać błędy sprzętu i jak je dalej diagnozować.

1. Czym jest dmesg i kernel ring buffer

Najważniejsze fakty o dmesg i buforze jądra:

• kernel ring buffer – cykliczny bufor, w którym Linux zapisuje komunikaty jądra od wczesnych etapów startu systemu;
• logi startu systemu – informacje o wykrywaniu sprzętu i ładowaniu sterowników;
• błędy sprzętowe – m.in. dysków, RAM, USB, PCI, sieci;
• ostrzeżenia modułów – komunikaty modułów kernela i potencjalne problemy;
• komunikaty sterowników – np. karty sieciowej, grafiki, kontrolerów dysków.

To, co widzisz na „czarnym ekranie” przy starcie (np. po włączeniu trybu verbose), pochodzi właśnie z tych komunikatów – dmesg pozwala je przeczytać na spokojnie już po uruchomieniu systemu.

Podobne

Jak zrobić schemat organizacyjny w PowerPoint, Wordzie i Excelu

2026-06-02

Jak wyłączyć mikrofon i kamerę w Zoomie przed dołączeniem

2026-06-03

Spotify na Ubuntu – jak zainstalować aplikację na Linuksie

2026-06-03

2. Gdzie fizycznie są logi dmesg

W większości współczesnych dystrybucji bufor jądra trzymany jest w pamięci i odczytywany przez dmesg bezpośrednio, bez pośrednich plików.

Najczęstsze lokalizacje kopii logów kernela to:

Podobne

Jak sprawdzić numer seryjny urządzenia z Androidem

2026-06-02

Szablony Google Sheets i Prezentacji Google – jak tworzyć własne

2026-06-02

Akceleracja sprzętowa Chrome – kiedy pomaga, a kiedy szkodzi

2026-06-02

• /var/log/dmesg – plik z logami startu systemu;
• /var/log/kern.log – komunikaty jądra zapisywane na bieżąco.

Logi można czytać następującymi poleceniami:

cat /var/log/dmesg
less /var/log/dmesg
cat /var/log/kern.log
less /var/log/kern.log

W systemach opartych o systemd te same informacje często znajdziesz w journalctl (dzienniku systemd), ale dmesg daje czysty widok na sam kernel.

3. Podstawowe użycie dmesg

Najprostsze wywołanie wygląda tak:

Podobne

Slack na Linuksie – instalacja, logowanie i funkcje

2026-06-02

Jak zablokować komórki w Arkuszach Google i chronić dane

2026-06-03

Nintendo Switch nie widzi kontrolera – jak naprawić Joy‑Con

2026-06-02

dmesg

To polecenie wyświetli całą zawartość buforu jądra od startu systemu.

Przy większych systemach logów bywa bardzo dużo – wtedy użyj pagera:

dmesg | less
dmesg | more

Możesz też zobaczyć tylko ostatnie wpisy (np. po podłączeniu nowego urządzenia USB):

dmesg | tail -n 50

4. Najważniejsze opcje dmesg przy analizie logów

Nowoczesne dmesg (util-linux) ma sporo przydatnych opcji ułatwiających analizę.

4.1. Timestamps – czytelne daty i czas

Domyślnie dmesg pokazuje czas od startu systemu w sekundach, np. [ 0.123456] .... Do analizy problemów wygodniej mieć normalne daty:

dmesg --ctime # lub: dmesg -T

Przykład wyjścia z czytelnymi datami:

[Mon Jun 1 12:34:56 2026] ata1: link is slow to respond, please be patient

4.2. Filtrowanie po priorytecie (tylko błędy i ostrzeżenia)

Kernel nadaje komunikatom poziomy ważności (priorytety). Tylko błędy i poważniejsze zobaczysz tak:

dmesg --level=err

Błędy i ostrzeżenia (oraz krytyczne) wyświetlisz poleceniem:

dmesg --level=warn,err,crit,alert,emerg

To bardzo ułatwia znalezienie realnych problemów w morzu komunikatów informacyjnych.

4.3. Filtrowanie po treści (grep)

Najprostsza i bardzo skuteczna metoda wyszukania słów kluczowych:

dmesg | grep -i error
dmesg | grep -i fail
dmesg | grep -i warning

Dla konkretnego typu urządzenia, np. pamięci, użyj:

dmesg | grep -i memory

Albo filtruj po nazwie sterownika/urządzenia:

dmesg | grep -i usb
dmesg | grep -i ata
dmesg | grep -i nvme
dmesg | grep -i eth

5. Jak czytać logi startowe krok po kroku

Przykładowy workflow analizy problemów ze startem systemu wygląda następująco:

1. Uruchom system, nawet jeśli ładuje się długo lub z błędami.
2. Zaloguj się i wyświetl log z czytelnymi datami:

sudo dmesg --ctime | less

3. Przejrzyj log od początku, zwracając uwagę na kolejność inicjalizacji:

• początek – detekcja CPU, RAM, magistral PCI/USB, kontrolerów dysków,
• środek – ładowanie sterowników i inicjalizacja urządzeń,
• końcówka – start usług sieciowych i procesu init.

4. Szukaj charakterystycznych wpisów i wzorców błędów:

• wpisów z “error”, “failed”, “timeout”, “I/O error”, “reset”,
• ostrzeżeń WARNING, BUG, tainted,
• powtarzających się komunikatów.

Aby przyspieszyć wyszukiwanie potencjalnych problemów, użyj jednego wyrażenia regularnego:

sudo dmesg --ctime | grep -iE "error|fail|warn|critical|timeout"

6. Typowe błędy sprzętowe w dmesg i jak je rozpoznać

Poniżej praktyczna ściągawka, czego szukać w dmesg, gdy masz podejrzenie problemów sprzętowych.

6.1. Dyski HDD/SSD/NVMe

Sygnały kłopotów z dyskiem to m.in.:

• I/O error (Input/Output error),
• read failed lub write failed,
• ataX: link is slow to respond,
• resetting link,
• nvme X: I/O timeout,
• częste błędy w sterowniku SATA/NVMe.

Wyszukaj właściwe ślady poleceniem:

dmesg --ctime | grep -iE "ata|sda|sdb|nvme|I/O error|timeout"

Jeśli widzisz powtarzające się błędy I/O czy timeouty – to czerwone światło dla dysku, kabla SATA, kontrolera lub zasilania.

Co dalej zrobić:

• sprawdź smartctl (SMART dysku),
• spójrz w /var/log/kern.log pod kątem korelacji błędów,
• wykonaj pilną kopię ważnych danych.

6.2. Pamięć RAM

Błędy RAM-u mogą dawać bardzo różne efekty: losowe zawieszki, kernel panics, błędy aplikacji.

W dmesg szukaj takich wpisów:

• EDAC (Error Detection and Correction),
• memory error,
• page allocation failure,
• Out of memory (częściej brak RAM niż fizyczny błąd),
• komunikatów z mce (Machine Check Exception).

Przydatny filtr do weryfikacji podejrzeń:

dmesg --ctime | grep -iE "memory|edac|mce|page allocation"

W razie podejrzeń uruchom test pamięci (memtest) i obserwuj, czy błędy się powtarzają.

6.3. Karta sieciowa (Ethernet / Wi‑Fi)

Typowe symptomy problemów sieciowych obejmują:

• rozłączanie i ponowne łączenie linku: link is down, link is up,
• błędy sterowników (np. e1000e, r8169, iwlwifi) zakończone error lub failed,
• problemy z negocjacją prędkości lub duplexu.

Użyj tego filtra, by zawęzić wyniki:

dmesg --ctime | grep -iE "eth|enp|wlan|wifi|link is down|link is up|error"

Jeśli po każdym resecie interfejsu pojawiają się błędy, przyczyną może być sterownik lub fizyczne uszkodzenie.

6.4. USB (pendrive’y, karty, modemy)

Typowe komunikaty dla USB to m.in.:

• USB disconnect i USB connect,
• unable to enumerate USB device,
• reset high-speed USB device,
• błędy odczytu/zapisu na nośniku.

Po podłączeniu urządzenia sprawdź ostatnie wpisy:

dmesg --ctime | tail -n 30

Zwróć uwagę na identyfikator urządzenia (Vendor ID, Product ID) i ewentualne błędy.

6.5. Karta graficzna

W przypadku GPU (NVIDIA, AMD, Intel) zwróć uwagę na:

• błędy sterownika: nouveau, nvidia, amdgpu, i915,
• GPU hang, GPU fault, ring stalled,
• problemy z inicjalizacją przy starcie (np. czarny ekran).

Przydatny filtr do analizy grafiki:

dmesg --ctime | grep -iE "nouveau|nvidia|amdgpu|i915|gpu|drm"

7. Analiza problemów przy włączaniu / wyłączaniu systemu

7.1. System uruchamia się długo

Scenariusz: system „wisi” na logo/ekranie startowym, ale ostatecznie startuje. Zacznij od obejrzenia pełnego logu:

sudo dmesg --ctime | less

Następnie poszukaj symptomów opóźnień:

• długich przestojów między wpisami (kilka–kilkanaście sekund),
• powtarzających się timeout oraz fraz trying to / failed to.

Przykładowe przyczyny to:

• problem z urządzeniem sieciowym, które długo negocjuje link,
• dysk, który „budzi się” lub zgłasza błędy,
• kłopoty z urządzeniami USB (np. uszkodzony pendrive).

Możesz zawęzić wyniki do najczęstszych fraz:

sudo dmesg --ctime | grep -i timeout
sudo dmesg --ctime | grep -i failed

7.2. Problemy przy zamykaniu systemu – jak zalogować błędy

Jeśli system wiesza się przy wyłączaniu, ekran znika po power‑off. Możesz jednak wymusić logowanie do bufora kernela, dodając parametry do linii kernela w GRUB:

• systemd.log_level=debug,
• systemd.log_target=kmsg,
• log_buf_len=24M,
• printk.devkmsg=on.

Przykładowy fragment wpisu kernela z dodatkowymi parametrami wygląda tak:

... systemd.log_level=debug systemd.log_target=kmsg log_buf_len=24M printk.devkmsg=on ...

Następnie utwórz skrypt, który przy zamykaniu systemu zrzuci bufor dmesg do pliku:

sudo nano /lib/systemd/system-shutdown/debug.sh

Wklej poniższą zawartość skryptu:

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
sync
mount -o remount,ro /

Nadaj prawo do wykonywania skryptu:

sudo chmod +x /lib/systemd/system-shutdown/debug.sh

Po kolejnym restarcie w katalogu głównym (/) znajdziesz plik /shutdown-log.txt z błędami występującymi tuż przed zawieszeniem systemu przy wyłączaniu.

8. dmesg a inne logi systemowe

dmesg to tylko kernel. W praktyce analizę problemów warto łączyć z innymi narzędziami i logami systemowymi.

8.1. Klasyczne logi w /var/log

Najważniejsze pliki dzienników w systemach z syslogiem to:

• /var/log/syslog – podstawowy dziennik systemowy (Ubuntu, Debian);
• /var/log/auth.log – logi uwierzytelniania (logowania, sudo);
• /var/log/kern.log – komunikaty jądra;
• /var/log/dmesg – logi startowe kernela.

Przydatne komendy do szybkiej analizy:

tail -f /var/log/syslog
grep -i error /var/log/syslog
grep -i fail /var/log/auth.log

Jak łączyć źródła informacji, by szybko namierzyć problem:

• dmesg – informacje o sprzęcie i kernelu,
• /var/log/syslog – usługi, sieć i demony,
• /var/log/auth.log – logowania i próby brute force.

8.2. journalctl (systemd)

W systemach z systemd logi trafiają do dziennika systemd. journalctl agreguje logi kernela i usług, a journalctl -k wyświetla wyłącznie komunikaty kernela (zbliżone do dmesg). Poniżej kilka najważniejszych przykładów:

journalctl -k
journalctl -k -p err..alert
journalctl -f
journalctl -u nginx
journalctl --since "2 hours ago" -n 50

dmesg pozostaje bardzo przydatny, bo działa także bez systemd, daje czysty widok na kernel i bywa wygodniejszy do szybkiego podglądu błędów sprzętu.

9. dmesg w analizie bezpieczeństwa

W kontekście bezpieczeństwa dmesg pomaga szybko zidentyfikować anomalie na poziomie jądra i sterowników:

• ładowanie modułów kernela (np. potencjalnie szkodliwych),
• błędy sterowników mogące sugerować próby exploitów,
• nienaturalne zachowania sprzętu po kompromitacji (nietypowe moduły/sterowniki).

Po incydencie bezpieczeństwa rozpocznij od takiego filtra:

dmesg --ctime | grep -iE "error|fail|module|taint|panic"

Następnie porównaj wyniki z /var/log/syslog, /var/log/auth.log i innymi logami.

10. Praktyczne przykłady analizy z dmesg

10.1. Przestał działać pendrive / dysk USB

Wykonaj poniższe kroki diagnostyczne:

1. podłącz urządzenie do portu USB,
2. wyświetl ostatnie wpisy kernela:

dmesg --ctime | tail -n 40

3. sprawdź, czy urządzenie zostało wykryte (Vendor ID, Product ID), przypisano mu /dev/sdX i czy nie ma błędów typu I/O error lub unable to read partition table.

Jeśli pojawiają się błędy, problem może dotyczyć urządzenia, kabla, portu USB lub zasilania.

10.2. Po aktualizacji kernela system zawiesza się przy starcie

Postępuj według poniższych wskazówek:

1. uruchom system na poprzednim, działającym kernelu (opcja w GRUB),
2. zaloguj się i zapisz logi kernela z wadliwego uruchomienia, jeśli zachowały się w /var/log/dmesg lub w journalctl -k,
3. porównaj różnice, zwłaszcza:

• nowe błędy sterownika,
• brak inicjalizacji urządzenia, które wcześniej działało.

Porównanie dmesg przed i po aktualizacji często pozwala wskazać winny sterownik.

10.3. Serwer co jakiś czas „zamraża się” i po restarcie ma błędy na dysku

Po restarcie sprawdź błędy I/O i kontrolera:

dmesg --ctime | grep -iE "I/O error|resetting link|nvme|ata"

2. jeśli widać długie serie błędów I/O – to sygnał, że dysk lub kontroler jest w złym stanie,
3. dalsze kroki obejmują:

• sprawdzenie SMART,
• wymianę dysku lub kabla,
• niezwłoczną kopię zapasową.

11. Dobre praktyki pracy z dmesg

Stosuj te zasady, aby szybciej znajdować przyczyny problemów:

• używaj --ctime (lub -T) – łatwiej powiążesz logi z konkretnymi zdarzeniami;
• filtruj priorytety za pomocą --level – szybciej wyłapiesz błędy i ostrzeżenia;
• łącz dmesg z grep – szukaj po słowach kluczowych, nazwach urządzeń i sterowników;
• porównuj logi z różnych startów – zapisuj dmesg do plików z datą.

Przykład zapisu logu kernela do pliku z timestampem:

dmesg --ctime > dmesg-$(date +%F-%H%M).log

Po zmianach sprzętu lub konfiguracji zawsze przejrzyj dmesg, aby upewnić się, że kernel nie zgłasza problemów.

12. Krótkie „recepty” – gotowe do wykorzystania w treści poradnika

Poniżej znajdziesz szybkie przepisy z poleceniami do skopiowania:

1. Pokaż tylko błędy kernela:

dmesg --ctime --level=err

2. Znajdź błędy dysków i I/O:

dmesg --ctime | grep -iE "I/O error|ata|nvme|reset"

3. Sprawdź, co się stało po podłączeniu urządzenia USB:

dmesg --ctime | tail -n 30

4. Analiza problemów z RAM (podejrzenie błędów pamięci):

dmesg --ctime | grep -iE "memory|edac|mce|page allocation"

5. Zapisz aktualne logi kernela do pliku (np. dla supportu):

dmesg --ctime > dmesg-report.txt