Ostatnimi czasy napotykam na dziwny problem z Archem. Otóż używam sobie systemu w normalny sposób i nic specjalnie nie obciąża komputera. Na to, co warto, stało się raz, kiedy użyłem Firefoksa. Moment system się zawiesza.
Wieszanie polega na tym, że przestaje reagować mysz i klawiatura. Lokalnie nic nie można zrobić, ponieważ nie działają także skróty w stylu CTRL+ALT+F1.
Chciałbym się jakoś dowiedzieć co powoduje ten problem. Używam otwartych sterowników intela, jeśli coś mam jeszcze podać jakieś informacje na temat systemu , to proszę napisać.
Specyfikacja:
OS: Arch Linux x86_64
DE: KDE 5.16.1
Kernel: 5.1.14-arch1-1-ARCH
CPU: Intel Pentium N3530
GPU: Intel Atom Processor Z36xxx/Z37xxx
Moduł jądra: i915
CTRL+ALT+F1 przełącza na tryb graficzny właśnie ;). Przełącz się na konsolę TTY2 (ctrl+alt+f2) i w top albo htop zobacz co wisi. Prewencyjne wywalenie katalogów Firefoksa z /home też nie zaszkodzi, może mu się coś pokiełbasiło w configu.
Nie wydaje mi się, by wyczyszczenie cache programów (zawartych w ~/.cache) mogło coś popsuć. Nie usuwaj tylko samego katalogu ~/.cache i najlepiej usuń zawarte w nim pliki bez zalogowania w trybie graficznym.
Możliwe, że aktualizowałeś np. Plasmę lub coś wyświetlającego grafikę 3D i zawarte są jakieś stare pliki, co powodują problemy. Możliwe jest też, że np. cache innych programów, jak Firefox coś komplikuje.
Jest bardzo źle, ale nadal można uratować komputer “lżejszą” formą restartu niż ten wymuszony. http://blog.kember.net/articles/reisub-the-gentle-linux-restart/
Należy, trzymając Alt i SysRQ, wciskać klawisze: R, E, I, S, U, B - w linku powyżej jest opisane, co dana kombinacja wykona, ale efekt powinien być taki, że system zostanie “kulturalnie” zrestartowany i wykona takie zadania jak np. synchronizacja systemów plików aby uniknąć tego, co np. się dzieje gdy się siłowo wypnie pendrive gdy jeszcze “nie wszystko zdążyło się zapisać, chociaż wygląda jakby się zapisało”.
A co do źródła problemu, to ciężko stwierdzić. To jest w końcu Arch Linux - dzisiaj system się wiesza po odpaleniu przeglądarki, jutro to naprawią, ale tego nie odczujesz, bo X server się nie załaduje, pojutrze naprawią X’a, ale pliki w ~/.config będą kolidować z nowymi wersjami czegoś w środowisku graficznym i będzie cię wylogowywało zaraz po zalogowaniu, itp. - takie uroki modelu rolling-release.
Osobiście w celu minimalizacji ryzyka poleciłbym pozostanie na wersji starej, która działała porządnie, a każdą aktualizację traktować jako nowy system z nowymi możliwościami, ale i wadami - tak jak np. aktualizacja Windows 10, która spowoduje zapętlone bluescreeny przy bootowaniu.
@incognito74 Utwórz nowego użytkownika w systemie, zaloguj sesję KDE Plasma na niego i zobacz, czy występuje ten sam problem. Staram się wykluczyć problem natury konfiguracyjnej KDE ($HOME/.config .local …)
@anon83895580
Nie można też przesadnie generalizować.
Zmiennych jest dużo - mam ArchLinux na dwóch komputerach i na żadnym popsuć się nie chce. Najgorsza rzecz przy Rolling Release to odłożenie aktualizacji na później, aby się skumulowały w jedną ogromną aktualizację, która tak naprawdę może posypać system. Pomniejsze problemy raczej bym nazwał niedoróbkami, jak ostatnio np. chce przesłać przez KDEConnect plik, a tu Failed. Zrobiłem downgrade aplikacji do poprzedniego stanu i jej configu - dalej Failed. Pytam na IRC - u innych ok, w końcu przeczyściłem dane aplikacji KDEConnect na kliencie w smartfonie i cudownie “ozdrowiało”.
Niestety ma znaczenie też sprzęt. Gdzie choćby ostatni przykład - aktualizacja ALSA - na niektórych SoundBlasterach przestał działać dźwięk, na innych działał jak gdyby nic.
Poprzednie distro - Manjaro przyzwyczaił mnie do robienia migawek systemu przed każdym większym update, gdzie zmienia się wersja najważniejszych bibliotek.
W Archu praktycznie wszystko składa się samemu z klocków - nie można założyć, że wszystko jest poprawnie skonfigurowane, a nawet jeżeli jest to po którejś aktualizacji będzie deprecated i cuś się posypie. Taki urok systemu, który pozwala na wiele użytkownikowi i zostawia dużą dowolność w grzebaniu w plikach konfiguracyjnych i ustawiania ich “na sztywno”.
Coś w tym jest. Można go często aktualizować i faktycznie wtedy powinien być mniejszy “szok termiczny” bo aż takich wielkich zmian nie powinno być, ale ja bym nie zaufał projektowi, który nie ma problemu żeby OOTB zniszczyć kompatybilność skryptów Pythona, zastępując wydanie nr 2 wydaniem nr 3. Dodatkowo nie podoba mi się fakt prowadzenia samej dystrybucji przez grupkę zapaleńców, bo kto będzie odpowiadał jeśli coś złego się stanie? Ano nikt.
To nie jest tak, że Archa nie da się używać, ale trzeba go bardzo dobrze poznać, znać jego zalety i wady i umieć stawić czoła potencjalnym wypadkom. Ja bym sobie na to nie mógł pozwolić, dlatego jeśli już bym miał go używać, to właśnie w tych wersjach np. starszych, niewspieranych, ale takich, że mogę już wiedzieć, co w niej jest.
Nie mój use case, dlatego go nie używam. Powiem więcej, znam raptem kilka osób, które go używają i sobie z nim radzą - używają go świadomie - i są normalnymi ludźmi, z którymi da się porozmawiać. Niestety, ta dystrybucja ze względu na np. naturę instalacji i zarządzania, jest wręcz osaczona oszołomami, którzy stracili kontakt ze światem i myślą, że są pępkiem świata, dlatego że udało im się podążać za instrukcjami instalacyjnymi na wiki. Nic dziwnego, że mam takie negatywne zdanie skoro w kwestii ogółu (większości) widać tyle patologii, a tylko w kwestii szczegółu (mniejszości, głównie chodzi o tych dobrych użytkowników) jest dobrze.
To tak jak np. z urzędnikami, policjantami, klerem, itp. - indywidualnych ludzi mogę lubić, bądź nie - zależy od tego, jacy są. Ale samymi instytucjami gardzę jak tylko się da.
Czy ktokolwiek, kiedykolwiek daje Ci gwarancję na oprogramowanie, poza przypadkami, gdy zamawiasz jego napisanie (np. Oprogramowanie medyczne dla odnogi SuSE Linux)?
Co do aktualizacji, to z wydania na wydanie może się zmienić zawartość/składania plików konfiguracyjnych. I tutaj jest problem, bo np. w wersji 2 zawarto skrypt migracyjny z wersji 1, a w wersji 8 usunięto program migrujący z wersji 1. Tak więc - trzeba robić aktualizacje możliwie często, choćby z tego powodu.
Dzięki.
Czyli wygląda na to że winne są sterowniki intela. Natomiast po aktualizacji sterowników intela, czyli nic się nie zmieniło. Podobno kernel linux rozwiązuje częściowo problem.
Najbardziej prawdopodobnym winowajcą byłoby coś związanego z Xorg.
Nie mam zamiaru grzebać głęboko w systemie, nie ciągnie mnie zabawa z systemem, grzebanie tu i tam…
Bo jak muszą czekać 5 minut patrząc na pulpit aż dysk się łaskawie zatrzyma i przestanie reagować mysz i klawiatura., to mnie trafia.
Mam swojego laptopa Asus U32U AMD E-450 i 12 GB RAM już parę lat, do tej pory działał bez zarzutu system Arch Linux KDE
Pozwalasz sobie na pozamerytoryczne uwagi to masz.
Co za dziecinada to co napisałeś.
Rozumiem, że w razie np. napadu rabunkowego czy gwałtu na członku rodziny nie wezwiesz Policji bo nią gardzisz?
Jak Twój operator internetowy będzie sobie z Tobą pogrywał to nie zwrócisz się o interwencję do organu państwowego (urzędnika) bo gardzisz państwem?
Z opieki medycznej zabezpieczanej przez godne pogardy państwo też nie skorzystasz w razie np. zawału bo gardzisz?
Tak, wiem, uzasadnionych uwag co do jakości usług świadczonych przez państwo jest miliard.
Co proponujesz konstruktywnego w miejsce w tych instytucji? Dasz radę?
Tylko poważne i dojrzałe propozycje proszę.
Zaraz Ci każą jądro kompilować…
Miałem to samo na KDE Neon, system zastygał, ale tylko na FF 67 przy jakiś materiałach video
KDE 5.16
Wywaliłem FF, cały katalog mozilli z /home, przeleciałem bleachbitem w trybie root też. Ponowna instalacja, wszystko ładnie się z powrotem zsynchronizowało i problem jak ręką odjął.
Metoda jak z windowsa, ale zadziałało, nie szukałem przyczyn, nie mam czasu na pierdoły.
