Nowe posty

Autor Wątek: PORADNIK ! [Poszukiwanie bledow]  (Przeczytany 259 razy)

Offline 1709

  • Users
  • Guru
  • *****
  • Wiadomości: 2269
  • 1709
    • Zobacz profil
PORADNIK ! [Poszukiwanie bledow]
« dnia: 2019-11-07, 12:09:56 »
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
Cytuj
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
dmesg | grep -i 'error\|warning\|fail|\segfault'
grep "(WW)\|(EE)" /var/log/Xorg.0.log
grep -ri 'error\|warning\|fail|\segfault' /var/log/*
Przykład z dokumentacji postfix:
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
journalctl --help
man journalctl

Moim zdaniem najprzydatniejsze
- Lista logow ze wszystkich uruchomien systemu
journalctl --list-boots
- Log z poprzedniego uruchomienia systemu zapisany do pliku "dziennik.log dzieki czemu mozemy przegladac wygodniej w edytorze lub komus wyslac.
journalctl -b -1 > dziennik.log
- W podobny sposob  jak wyzej przejzec plik tekstowy pod katem bledow lub odrazu w terminalu
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 :D )

- 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 :)
« Ostatnia zmiana: 2019-11-15, 13:34:39 wysłana przez 1709 »
Pochwal się swoją kartą graficzną w tym wątku-->
http://forum.linux.pl/index.php/topic,19841.msg121122.html#msg121122

Offline marcin'82

  • Users
  • Prawie jak Guru
  • ****
  • Wiadomości: 294
    • Zobacz profil
Odp: PORADNIK ! [Poszukiwanie bledow]
« Odpowiedź #1 dnia: 2019-11-09, 17:54:50 »
Niektóre rzeczy można skrócić:
https://elinux.org/Debugging_by_printing#Log_Levels
dmesg -xl 3
dmesg -xl 3,4
dmesg -xl 0,1,2,3,4

Cytuj
( Co do opcji zero "-b 0", nie jestem pewien czy zadziala, czy wystarczy samo  "-b", nie mam systemd pod reka by sprawdzic :D )
Zadziała - tutaj wyższe poziomy logowania są włączane do wyniku, więc to poniżej zawiera od 0-3:
journalctl -q -b -p 3
Jak chcesz tylko błędy to tak:
journalctl -q -b p 3..3
marcin82