Fórumok
Arch Linux alatt néha lefagynak a login managerek, akár zároláskor, akár leállítás alatt előfordul. Elsőre LightDM-mel próbálkoztam, azzal gyakori volt ez a hiba. Most LXDM-et használok, ezen ritkább, de elő-előfordul.
Milyen logban nézelődjek, vagy van valami ötletetek ennek a megoldására?
Hozzászólások
Memteszt? Videokártya csere, táp csere, alaplap csere :(
Valszeg valami random hw hiba.
Először azért nézzük meg a logfájlokat (X11 log, rendszer journal)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
Esetleg első körben nézd meg, hogy nem-e az X döglődik valójában a dm helyett. Nekem régebben csinálta, hogy néha elhasalt a dm az intel vga driver hibája miatt (esetleg vesa vagy fbdev használatával tudod tesztelni is).
Zavard össze a világot: mosolyogj hétfőn.
A /var/log/Xorg.*.log és .old fájlokban nem találtam semmi vonatkozót (ha újra előjönne a hiba, bemásolom ide a topikba az akutálisat). vesa, fbdev tesztelése hogy zajlik, mit állítsak, hol?
Nem hinném, hogy hardverhiba, mert csak a DM csinálja, és az is csak zároláskor, meg leállításkor, bejelentkezéssel sose volt baj. Hőfokok rendben, előtte szintén Arch Linux volt a gépen, de KDE5-tel, és azzal nem volt gond, meg ha hardverhiba lenne, akkora random fagyna, nem csak a DM. Intel Mesa drivert használok (HD3000-es Intel GPU), és máshol nincs baj vele, de attól lehet, hogy a DM-ek nem szeretnek rajta valamit. Mégis úgy hiszem, hogy csak valami szoftveres gubanc. Néznék még logokat, de fogalmam sincs mit érdemes nézni ilyenkor.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
Én sddm-et használok és soha nem volt vele semmi gondom. Bár igaz, hogy ritkán látom az autologin miatt, de néha switch-user miatt és logout miatt kell.
Milyen DE-be lép be?
Mit jelent az,hogy lefagy? Másik VT-re át tudsz lépni?
Openbox lép be. A lefagy azt jelenti, hogy semmit nem csinál, nem reagál semmilyen gombra, VT-t sem tudok nyitni.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
Ha van lehetőséged kipróbálni, egy ilyen fagyás után próbálj sshval csatlakozni a gépre hogy lásd tényleg elhasalt e teljesen vagy csak a DM/Xorg halt le.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
Első körben a DM-ek logjait nézd meg. Ha lehet, amikor a fagyás van, próbáld meg elérni a gépet ssh-n. Ha csak az X fagy csonttá, akkor valszeg elérhető lesz még. Így esetleg olyan logokat is láthatsz, ami elveszne resettel. Kernel üzenetekben nincs semmi esetleg?
Egész eddig nem csinálta, azért nem írtam a topikba. Végül ma hajnalban jött elő megint. SSH-n még nem tudtam megnézni, de mégis vannak fejlemények.
Most leálláskor, mikor írja ki a kernel és a systemd, hogy miket állít le, egy üres sort mutattott, a végén egy darab "r" karakter. Majd úgy maradt egy percig. Meglepő módon ezután újabb sorban elkezdett visszaszámolni Shutting down LXDM Display Manager (15 sec / 1m 31), végül sikerrel kilőtte. A journalctl nem mutat semmilyen hibát, abba az van bejegyezve a kérdéses időpontnál, hogy az LXDM sikerrel leállt. A /var/log/Xorg.1.log.old-ban sincs semmilyen hiba jelezve. Az /var/log/lxdm.log csak az alábbi hibákat tartalmazza:
xf86: remove device 0 /sys/devices/pci0000:00/0000:00:02.0/drm/card0
failed to find screen to remove
/usr/share/lxdm/themes/Manjaro/gtkrc:10: Unable to locate image file in pixmap_path: "background-image"
/usr/share/lxdm/themes/Manjaro/gtkrc:13: Background image options specified without filename
(lxdm-greeter-gtk:373): Gtk-WARNING **: Unknown property: GtkButton.type
Viszont biztosan nem ez az oka, mert mikor stock téma volt az LXDM-et, meg a LightDM-en, semmilyen háttérkép meg semmi nem volt beállítva, akkor is csinálta ezeket a leakadásokat. Persze rá fogok nézni még egyszer a témára. Az most már biztos, hogy nem hardveres hiba, persze eddig is gyanítottam, csak még soha nem vártam ennyit, hogy végül magától kilője az LXDM-et.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
Szerintem megoldva, bár nem merem elkiabálni. Leírom a menetét, hátha más is belefut ilyenbe.
Először az LXDM-ben beállítottam, hogy az Openbox sessiont ne simán indítsa, hanem a session=dbus-launch openbox-session sort adtam hozzá, így a D-Bus wrapperként fut az Openbox körül. Ez nem oldotta meg a topikbeli problémát, de megoldotta azt, hogy néhány alkalmazás D-Bus hibára hivatkozva nem futott.
Aztán rendbetettem az lxdm.log-ban jelzett témahibákat a gtkrc és greeter-gtk3.ui átszerkesztésével, kiszedtem belőlük az logban kifogásolt sorokat, így már a log nem tartalmazza ezeket. A hibát nem oldotta meg, nem ez volt a baj.
Majd tovább tesztelve ha előjött a hiba, akkor elkezdte a kernelkimenetbe a [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:26:pipe A] flip_done timed out sorokat dobálni. Erre a net azt javasolta első körben, hogy a kernelparaméterek közé a video=SVIDEO-1:d paramétert kell felvenni. Nem ez volt a megoldás, épp úgy írogatta ezeket a sorokat.
A megoldás végül az lett, hogy el kellett távolítani az xf86-video-intel csomagot, amely az Xorg-os Intel drivert tartalmazta, enélkül a modesetting Intel drivert használja a rendszer, és azóta a hiba megszűnt. Legalábbis nem tudom előhozni agresszív ki-belejentkezések sorozatával sem, nem jön elő, le is kopogom. Így beszopasson egy mocsok driver. Az Arch Wiki írja is, hogy egyesek szerint 4+ gen. Intel CPU-kba integrált GPU-knál nem érdemes feltenni a hagyományos xf86-os drivert, mert hibákat okoz, de ezt eddig azért hagytam figyelmen kívül, mert 2. gen-es a procim.
Mindenki azt írja, hogy érdemes eltávolítani az Xorg-os Intel drivert, mert elavult, nem tartják rendesen karban. Hátrányát nem érzem a modesetting drivernek. A xbacklight nem ment, de feltettem helyette az acpilight csomagot, így épp úgy xbacklight nevű binárissal vezérelhető a háttérvilágítás ereje, csak nem az Xorg-on, hanem ACPI-n keresztül, igaz udev-es jogosultságadás is kellett hozzá, egyébként csak sudo-val működik (ami meg lehetetlenné tenné, hogy Xbindkeys-zel használjam). Plusz a Redshift nem volt hajlandó elindulni, de a konfigjában átállítottam randr:screen=0-ra a működési módot, és képernyőt, és így már jó. Nem hittem volna, hogy ilyen összetett a probléma, ilyen nehéz lesz megoldani, és utána újabb hibák jönnek elő, amit szintén meg kell majd oldani hozzá.
Szerk.: de, van hátránya a modesetting drivernek. Egyrészt a képminőség rosszabb vele 2D-s megjelenítésnél (és mpv alatt OpenGL-esnél is, de amúgy a 3D-s minőség rendben van). Másrészt mint írtam cserélni kellett az xbacklight megoldást, és a Redshift is szórakozott egy kört. Viszont mégse bántam meg, hogy lecseréltem, úgyis elavult drivert a Xorg-os Intel. A legtöbb modern DE már Waylanddel működik, és azalatt úgyse működik a Xorg-os driver, csak a modesettinges. Valószínű dobom az Openboxot, mert nincs Wayland-forkja, és áttérek Sway-re. Amúgy is tervben volt véve, hogy átállok i3wm-re, de a Sway az i3wm waylandes forkja.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum