PORADNIK ! [Poszukiwanie bledow]

[1709]

Proponuję do niektórych działów dodać przyklejony poradnik  z tytułem
" PRZECZYTAJ TO !  "
lub
" PORADNIK ! "
Tematy mają być otwarte, aby każdy mógł zgłosić uwagi, poprawki, aktualizacje,  i inne zastrzeżenia.


1. System się nie uruchamia.

- Wyswietla sie logo i potem czarny ekran.
https://www.dell.com/support/article/pl/pl/plbsd1/sln306327/manual-nomodeset-kernel-boot-line-option-for-linux-booting?lang=en
Poradnik pokazuje dwa rozwiazania ustawienia opcji nomodeset
Pierwszy jest ustawieniem tymczasowym <-- polecanym w celu sprawdzenia czy zadziała
Drugie rozwiazanie jest ustawieniem stalym. <-- polecane gdy juz wiemy ze bez tej opcji nie uruchomimy systemu.

- Jeśli pasek ładowania zasłania komunikaty z uruchomienia systemu to

Uruchamiamy komputer i po pojawieniu się listy wciskamy e przechodząc do edycji “procedury startowej”,
Odszukujemy fragment quiet splash
Usuwamy slowo quiet splash
Bootujemy system

- Tryb awaryjny / Recovery mode
Opcja w menu Grub, ktora pozwala
 na uruchomienie systemu w trybie tekstowym. ( w niektórych systemach jest on ukryty )
Opcja ta przydaje sie gdy musimy zobaczyc logi w trybie tekstowym i naprawic nasz system.
https://www.youtube.com/watch?v=8xFAVvrfEdg


2. Logi.

- Init ... /var/log/
https://www.thegeekstuff.com/2011/08/linux-var-log-files/

Przyklady

Kod: [Zaznacz]

dmesg | grep -i 'error\|warning\|fail|\segfault'

Kod: [Zaznacz]

grep "(WW)\|(EE)" /var/log/Xorg.0.log

Kod: [Zaznacz]

grep -ri 'error\|warning\|fail|\segfault' /var/log/*

Przykład z dokumentacji postfix:

Kod: [Zaznacz]

egrep '(reject|warning|error|fatal|panic):' /var/log/nazwa_pliku

Nalezy brac pod uwage ze grep wyswietli tylko jedna linie,
dlatego czasami warto odnalesc blad w logu lub wyswietlic sobie wiekszy fragment bledu
aby sprawdzic czy ponizej nie ma dalszej czesci komunikatu.

- Systemd ... journalctl
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

Wiecej w

Kod: [Zaznacz]

journalctl --help

Kod: [Zaznacz]

man journalctl

Moim zdaniem najprzydatniejsze
- Lista logow ze wszystkich uruchomien systemu

Kod: [Zaznacz]

journalctl --list-boots

- Log z poprzedniego uruchomienia systemu zapisany do pliku "dziennik.log dzieki czemu mozemy przegladac wygodniej w edytorze lub komus wyslac.

Kod: [Zaznacz]

journalctl -b -1 > dziennik.log

- W podobny sposob  jak wyzej przejzec plik tekstowy pod katem bledow lub odrazu w terminalu

Kod: [Zaznacz]

journalctl -b 0 | grep -i 'error\|warning\|fail|\segfault'

( Co do opcji zero "-b 0", nie jestem pewien czy zadziala, czy wystarczy samo  "-b", nie mam systemd pod reka by sprawdzic )

- Jesli problem dotyczy srodowiska graficznego mozesz zapoznac sie takze z
https://forum.linux.pl/index.php/topic,25285.0.html

- Jesli problem dotyczy sterownikow graficznych mozesz zapoznac sie takze z
https://forum.linux.pl/index.php/topic,25062.0.html


3. Szukanie rozwiązania w internecie.
Dlaczego warto szukać i sprawdzać ?
- Czasami jest to szybsze niż otrzymanie pomocy.
- Czasami istnieje tylko obejscie problemu i nikt nam nie naprawi oprogramowania.

Np. gdy nasz sprzęt jest juz nie wspierany lub słabo wspierany przez danych developerów.
Takimi obejściami problemu są np.
* opcja nomodeset dla starszych i niektórych nowszych kart graficznych których dystrybucja Linuxa nie wspiera.
* opcja libata.noacpi=1 gdy Linuxowe ACPI nie chce wspierac juz naszego starego Biosu, a my nie możemy Biosu zaktualizować.
https://blog.le-vert.net/?p=24

Przy szukaniu
- Używaj slow kluczy, czyli takich najistotniejszych
- Możesz użyć slow na początku takich jak
* klucza linux które będzie sugerowało ze szukasz tylko treści dotyczących Linuxa.
* klucza SOLVED ktore bedzie sugerowalo ze szukasz tematow rozwiazanych

Taka ciekawostka:
Kiedys na forach byl taki zwyczaj ze uzytkownik gdy na forum poprosil o pomoc i rozwiazal problem,
to mial obowiazek na koncu napisac " SOLVED ". Dzieki temu latwiej jest znalesc rozwiazania w internecie.

- Unikaj podawania liczb, np. liczb sugerujących numer linii w logu.
- Staraj się aby twój system wyświetlał błędy po angielsku i również staraj się szukać po angielsku
  Ponieważ wpisując zapytanie po angielsku będziesz miał więcej wyników wyszukiwania.


4. Zgłaszanie błędów

Nie ma jednego miejsca na zglaszanie problemow.
- Jesli nie wiemy gdzie, to najlepiej spytac na forum wlasnej dystrybucji linuxa.

Ostrzezenie:
  Nie zawsze forum na ktorym zglaszamy problem jest tym wlasciwym.
  Glownym zalozeniem for jest otrzymanie pomocy, ale nie zawsze uzytkownicy na nich pisza gdzie potem nalezy zglosic problem / błąd.
  Np. Siedze na polsko jezycznym forum i tu moge teoretycznie dostac pomoc w rozwiazaniu problemu.
  Ale jesli problem dotyczy pakietu i developerzy dystrybucji siedza na anglojezycznym forum,
  to tam na anglojezycznym forum powinienem ponownie zglosic problem ( czesto w odpowiednim dziale )
  aby developerzy naprawili pakiet.

- Jesli okazalo sie ze po zgloszeniu problemu na forum problem wystepuje tylko u nas
  i dotyczy on
np. sterownikow kernela to na stronie https://bugzilla.kernel.org/
1) Znajdz po fragmencie bledu czy byl blad juz zgloszony i czy zostal juz naprawiony
2) Jesli blad nie byl zgloszony to wtedy z czystym sumieniem mozesz im zglosic.

np. jesli problem dotyczy programu
- zglosilismy na forum, wszyscy maja ten sam problem.
- sprawdzamy czy jest nowsza wersja programu,  jesli jest to zglaszamy w swojej dystrybucji prosbe o aktualizacje
  w przeciwnym wypadku musimy czekac
- jesli mamy najnowsza wersje i problem wystepuje to szukamy developerow tej aplikacji

Szczegoly skad byl pobrany kod zrodlowy pakietu
* szukamy w informacji o naszym pakiecie
* mozna tez poszukac informacji w samym programie ... "Pomoc" / "O programie"

i taki tylko przyklad z oem
Znalezlismy ze developerzy swoj projekt oem udostepniaja na Github
Github ma taka zakladke " Issues " w ktorej mozna wyszukac
czy blad byl juz zglaszany i jesli nie byl to zglosic developerom w tej zakladce
https://github.com/mate-desktop/eom/issues

Porady:
1. Jesli masz problem z jezykiem angielskim wspomagaj sie translatorem online.
2. Na forach nie zawsze zmiescisz caly log
- mozesz probowac dac go w zalaczniku ( jesli jest za duzy to mozesz go spakowac )
- mozesz probowac wyslac np. na https://pastebin.com/
  i podac uzytkownikom linka aby mogli przejzec lub pobrac log.
3. Staraj sie omawiac problem szczegolowo jesli to mozliwe,
unikniesz dzieki temu zbednych pytan i masz wieksza szanse na szybsza odpowiedz.


Ostatnie aktualizacje tematu:
- 15.11.2019 / Dodalem 1 przyklad szukania bledu z dokumentacji postfix

[marcin'82]

Niektóre rzeczy można skrócić:
https://elinux.org/Debugging_by_printing#Log_Levels

Kod: [Zaznacz]

dmesg -xl 3

Kod: [Zaznacz]

dmesg -xl 3,4

Kod: [Zaznacz]

dmesg -xl 0,1,2,3,4

( Co do opcji zero "-b 0", nie jestem pewien czy zadziala, czy wystarczy samo  "-b", nie mam systemd pod reka by sprawdzic )

Zadziała - tutaj wyższe poziomy logowania są włączane do wyniku, więc to poniżej zawiera od 0-3:

Kod: [Zaznacz]

journalctl -q -b -p 3

Jak chcesz tylko błędy to tak:

Kod: [Zaznacz]

journalctl -q -b p 3..3

[1709]

Miałem okazję ostatnio przetestować komendy.
- Może podam wersję bardziej czytelną, choć może trudniejszą do zapamiętania  wersję tej samej komendy.

z dmesg --help

l, --level <lista>         ograniczenie wyjścia do określonych poziomów
...
Obsługiwane poziomy (priorytety) logowania:
   emerg - system jest bezużyteczny
   alert - akcję trzeba podjąć natychmiast
    crit - warunki krytyczne
     err - wystąpił błąd
    warn - wystąpiło ostrzeżenie
  notice - normalne, ale znaczące zdarzenie
    info - informacja
   debug - komunikaty diagnostyczne

Kod: [Zaznacz]

dmesg -T -l emerg,alert,crit,err

z man journalctl

       -p, --priority=
           Filter output by message priorities or priority ranges. Takes either a single numeric or textual log level (i.e. between
           0/"emerg" and 7/"debug"), or a range of numeric/text log levels in the form FROM..TO. The log levels are the usual
           syslog log levels as documented in syslog(3), i.e.  "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4),
           "notice" (5), "info" (6), "debug" (7). If a single log level is specified, all messages with this log level or a lower
           (hence more important) log level are shown. If a range is specified, all messages within the range are shown, including
           both the start and the end value of the range. This will add "PRIORITY=" matches for the specified priorities.

Kod: [Zaznacz]

journalctl -xb0 -p emerg..err

- "emerg..err" --> dwukropek jest zakresem, w tym przypadku od "emerg" do "err".

- Wyświetlenie wszystkich zakresów pokaże cały log, tylko że w kolorze.
- Polecam obie metody wyszukiwania błędów.  Zarówno przy pomocy opcji / "poziomów logowania",
jak i przy pomocy komendy "grep" ponieważ czasami komunikat może omyłkowo nie być zakwalifikowany jako błąd.
- Oczywiście samo wyświetlenie błędu często nie powie nam o przyczynie.
Dlatego jeśli błąd wystąpi to warto otworzyć cały log i odnaleźć linię z błędem.

- journalctl lub raczej systemd jest dość chaotycznym "menadżerem usług", dlatego zbierane logi również będą chaotycznie zbierane.
Dlatego czasami bardzo fajną / dobrą rzeczą jest znaleźć nazwę usługi lub cechę wspólną w logu
i interesujące nas linie potem wyodrębnić.

Przykład gdy próbowałem wyodrębnić linie o dysku  ( czasami przydaje się znajomość "wyrażeń regularnych )

Kod: [Zaznacz]

journalctl -b0 | grep -iE "ata2|sd. |smartd"

- Załóżmy że użytkownikowi zresetował się komputer i nie potrafi z logu odnaleźć co się stało.
Zarówno nałożenie się nowego logu jak i zakrzywienie / zakłamanie znacznika czasu, chaotyczne strumienie danych
utrudnia poszukiwania.
Bardzo ułatwia odnalezienie linii oznaczającej ponownie uruchomienie komputera.

Kod: [Zaznacz]

-- Reboot --

Ponieważ jeśli błędy krytyczne które spowodowały "reboot" wystąpiły, to powinny być widoczne przed tą linią.