Elementares Betriebssystem zufällig einfrieren

1237
Agterbosch

Ich arbeite schon lange mit Elementary OS Freya, die gleiche Installation wird seit mindestens zwei Jahren durchgeführt, und von Zeit zu Zeit wird es komplett einfrieren und reagiert nicht mehr nur auf den Desktop, sondern nur auf den Desktop Behebung des
Problems ist, den Ein- / Ausschalter zu halten. Ich hatte zunächst ein Problem mit Swap, das aber behoben wurde, und ich habe auch die proprietären Treiber von nvidia installiert, aber keines dieser Dinge scheint das Problem behoben zu haben.

Es passierte gerade wieder und dachte, ich würde einen Teil der Syslog-Datei posten, da ich keine Ahnung habe, was ich hier anschaue. Ich hatte gehofft, jemand anderes könnte auf ein Problem hier hinweisen.

Es scheint auch völlig zufällig zu geschehen 

 Aug 21 13:15:34 Asus colord: Automatic metadata add icc-dc945c3592fc6c2089fd79db35a300dc to xrandr-LVDS1 Aug 21 13:15:34 Asus colord: Profile added: icc-dc945c3592fc6c2089fd79db35a300dc Aug 21 13:15:34 Asus kernel: [ 42.656869] audit_printk_skb: 48 callbacks suppressed Aug 21 13:15:34 Asus kernel: [ 42.656874] audit: type=1400 audit(1503314134.828:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=2314 comm="apparmor_parser" Aug 21 13:15:34 Asus kernel: [ 42.656883] audit: type=1400 audit(1503314134.828:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=2314 comm="apparmor_parser" Aug 21 13:15:34 Asus colord: Profile added: M2020-Series-Gray.. Aug 21 13:15:34 Asus colord: Device added: cups-M2020-Series Aug 21 13:15:35 Asus dbus[457]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper) Aug 21 13:15:35 Asus udisksd[2385]: udisks daemon version 2.1.3 starting Aug 21 13:15:35 Asus dbus[457]: [system] Successfully activated service 'org.freedesktop.UDisks2' Aug 21 13:15:35 Asus udisksd[2385]: Acquired the name org.freedesktop.UDisks2 on the system message bus Aug 21 13:15:39 Asus kernel: [ 46.979071] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Aug 21 13:15:39 Asus kernel: [ 46.979166] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Aug 21 13:15:39 Asus kernel: [ 46.979239] nouveau 0000:01:00.0: DRM: suspending console... Aug 21 13:15:39 Asus kernel: [ 46.979243] nouveau 0000:01:00.0: DRM: suspending display... Aug 21 13:15:39 Asus kernel: [ 46.979254] nouveau 0000:01:00.0: DRM: evicting buffers... Aug 21 13:15:39 Asus kernel: [ 46.979256] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle... Aug 21 13:15:39 Asus kernel: [ 46.979297] nouveau 0000:01:00.0: DRM: suspending client object trees... Aug 21 13:15:39 Asus kernel: [ 46.979533] nouveau 0000:01:00.0: DRM: suspending kernel object tree... Aug 21 13:16:12 Asus wpa_supplicant[1005]: wlan0: CTRL-EVENT-SCAN-STARTED  Aug 21 13:16:13 Asus sm-mta[1873]: unable to qualify my own domain name (Asus) -- using short name Aug 21 13:16:13 Asus sm-mta[1873]: gethostbyaddr(192.168.0.103) failed: 1 Aug 21 13:16:13 Asus sm-mta[2633]: starting daemon (8.14.4): SMTP+queueing@00:10:00 Aug 21 13:16:15 Asus sm-msp-queue[1882]: unable to qualify my own domain name (Asus) -- using short name Aug 21 13:16:16 Asus kernel: [ 84.366042] init: plymouth-stop pre-start process (2771) terminated with status 1
0
Hat es die ganzen zwei Jahre gelegentlich gefroren? Irgendwelche Updates, insbesondere Kernel, bevor es begann? Hatte es nach 13:16:16 Uhr ungefähr 84 Sekunden nach dem Booten gefroren? Das könnte nur das Protokoll der aktuellen Session sein, die vorherige konnte sich an einer anderen Stelle befinden (in / var / log /?), Könnte eine Kernel-Panik haben oder etwas ähnliches wie <2839824> mit einigen `?` - Zeichen, das in einem dmesg definitiv hervorsticht / syslog. Oder es hätte auch "fest" ohne Nachrichten eingefroren Xen2050 vor 6 Jahren 0
Ja, ich hatte dieses Problem immer von Anfang an, jedoch keine anderen Probleme. Dies ist von / var / log / syslog btw .. Ich habe es aus dem Protokoll kopiert, nachdem der Laptop wieder hochgefahren war, daher kann ich nur vermuten, dass es um 13:15:39 erstarrte. Aber selbst wenn es festgefroren ist (scheint also), müsste nicht schon vorher etwas Schlimmes passiert sein? Es sei denn, es handelt sich um ein Hardwareproblem. Aber ich hatte dieses Problem nie unter Debian, das bereits vor dem ersten Element lief Agterbosch vor 6 Jahren 0
Ich bin mir ziemlich sicher, dass der [46.979256] -Teil die Sekunden ist, seit dmesg (oder dem Kernel?) Das Booten schreibt. Normalerweise laufe ich live. Wenn der seltene Absturz auftritt (jährlich), habe ich keine Protokolle, die überprüft werden sollten (waren in RAM, wurden gelöscht). Manchmal nur zu Panik, aber ein hartes Einfrieren zeigt das nicht einmal. Ältere Protokolle könnten noch irgendwo da sein ... Ich vermute nur, aber da Debian in Ordnung war, ist es jetzt vielleicht ein Kernelproblem? Könnte versuchen, mit einem anderen Kernel zu booten (neuer oder älterer, vielleicht "stabiler"?), Aber suchen Sie zuerst nach einem * vorherigen / alten Kernel *, nur für den Fall. Xen2050 vor 6 Jahren 0
Eigentlich stürzte ein alter Computer öfter ab, wenn ich compiz verwendete. Ich denke, das grundlegende Betriebssystem hat schöne Fenster und Grafiken. Versuchen Sie also, die Hardwarebeschleunigung zu deaktivieren, oder schalten Sie einige Grafikeffekte aus (Compositing). Ein einfacherer Fenstermanager ist auch eine Idee Xen2050 vor 6 Jahren 0
Ich weiß nicht, ich bin jetzt auf dem neuesten Kernel, aber ich hatte dieses Problem seit 2 Jahren auf jedem Kernel, der soweit veröffentlicht wurde. Was die Hardware anbelangt, verwende ich eine dritte Generation von i5 mit 6-GB-RAM. geforce gt540m cuda 1gb und eine ssd, die bisher nur halb voll ist. Es scheint auch nie unter Last zu sein, wenn es einfriert Agterbosch vor 6 Jahren 0
Sieht aus wie keine Meldungen über das Einfrieren ... Wenn der Kernel noch "am Leben" wäre, würde ich hoffen, er hätte etwas gedruckt, und Sie könnten immer noch die "Magic SysRq" -Tasten verwenden, um mit der Tastatur zu synchronisieren und neu zu starten (möglicherweise müssen) aktiviere sie). Da Sie den Kernel die ganze Zeit aktualisiert haben, ist dies wahrscheinlich kein einfach zu behebender Fehler. Ich bin mir nicht ganz sicher, was zu tun ist. Versuchen Sie, alle hardwarespezifischen Treiber zu deaktivieren (Video scheint besonders anfällig zu sein), oder versuchen Sie, andere zu finden, wenn es keine gibt, oder verwenden Sie eine Distribution, die nicht einfriert, und installieren Sie einige ElementaryOS-Pakete Arbeit ok Xen2050 vor 6 Jahren 0
Von welchen magischen Schlüsseln sprichst du? Ich habe bereits zu verschiedenen GPU-Treibern gewechselt, nachdem ich einige gelesen hatte, dass einige Probleme mit NVIDIA hatten, aber es hat mir nicht geholfen. Wie auch immer, das Fremde daran ist auch, dass es nicht friert, wenn die GPU unter Last ist, aber zufällig, wie gerade erstarrt es, während ich außer Leafpad nichts geöffnet hatte. Außerdem kann ich niemanden finden, der dieses Problem mit eOS hat. Das lässt mich denken, dass es entweder ssd, ram oder cpu ist, obwohl debian Laufen in Ordnung vor 2 Jahren könnte ein Zufall sein, ich könnte eine andere Distribution und einen Test-RAM und eine andere CPU ausprobieren Agterbosch vor 6 Jahren 0
Wikipedia hat einen guten Überblick https://en.wikipedia.org/wiki/Magic_SysRq_key. Könnte ein Hardware-Problem sein, auf jeden Fall ein Test-RAM, könnte auch nach Fusseln suchen, die Lüftungsschlitze blockieren, oder Ventilatoren, die aufgehört haben. Überwachen Sie die Temperatur (mit "Sensoren"), wenn Sie können. Wenn Sie einige andere Distors live testen (mit einem USB- oder DVD-Player), sollten Sie zumindest Ihre "Hauptlaufwerk" alleine lassen, oder viele Isos werden von grub gebootet, wenn Sie sie kopieren und den richtigen Eintrag hinzufügen. Xen2050 vor 6 Jahren 0
Danke Mann, ich wusste nie, dass das eine Sache ist. Nächstes Mal werde ich es versuchen. Wenn ich nur vorhersagen könnte, wann es passiert, da es nicht jeden Tag passiert und es völlig zufällig erscheint. Auch die Hitze scheint die meiste Zeit in Ordnung zu sein. Ich habe die gesamte Wärmeleitpaste vor etwa 6 Monaten erneut aufgetragen Agterbosch vor 6 Jahren 0
Fragen Sie unter https://elementaryos.stackexchange.com/ nach. phuclv vor 5 Jahren 0

2 Antworten auf die Frage

0
Felipe Butcher

Es macht nicht viel Sinn, aber das Entfernen wingpanel-indicator-powerder Probleme mit dem Auflegen wurde für mich behoben.

sudo apt-get remove wingpanel-indicator-power

Mein System war nicht vollständig gefroren, wie Sie berichtet haben, aber ich hatte ein schnelles Aufhängen, zum Beispiel beim Öffnen einer neuen Registerkarte in Chrom.

0
baelx

Es ist wirklich schwer, eine Antwort auf eine Frage wie diese zu beantworten, da sie so breit ist, aber Sie würden theoretisch dorthin gelangen, indem Sie durch die Schichten Ihres Systems (sehen Sie sich diese detaillierte Aufgliederung einer eOS-Distribution an ) bis zum Kernel sehen, was genau das Problem verursacht. Betrachten Sie dies als eine Antwort, die Ihnen hilft, zu einer genaueren Frage zu kommen. Dabei erfahren Sie wahrscheinlich viel darüber, wie Ihr System funktioniert.

Um zu beginnen, es beim nächsten Mal friert versuchen auf ein tty Schalt . Dies geschieht mit einem Tastendruck ( CTRL + ALT + F1 through F6. Wenn Ihre Funktionstasten normalerweise zur Lautstärkeregelung, Helligkeitsregelung usw. verwendet werden, müssen Sie möglicherweise den FnSchlüssel in diese Kombinationen einschließen . Wenn dies erfolgreich ist, würde ich einen Teil Ihrer GUI vermuten. Nach dem Umschalten geben Sie Ihre Benutzerdaten ein, und Sie können eine Vielzahl von Methoden ausprobieren, um die Ursache des Problems zu diagnostizieren.

  • Führen Sie den topBefehl aus, und suchen Sie nach einem Prozess (ganz oben in der Liste), der 100% CPU-Ressourcen oder eine große Menge anderer Ressourcen beansprucht.
  • Überprüfen Sie die verschiedenen Protokollschichten. Wenn Sie ein GUI-Problem vermuten, beginnen Sie mit den Xorg-Protokollen, die die niedrigste Ebene der "GUI" sind, dh Ihr Desktop. Prüfen Sie, ob der X-Server zum Beispiel Ereignisse protokolliert. Arch Wikis Anweisungen dazu sind ziemlich gut. Das heißt, versuchen Xorg.0.log und Xorg.1.log für Leitungen überprüft, die mit beginnen EEoder WWwelche Fehler oder Warnungen zeigen jeweils an.

Um zu Ihrer GUI zurückzukehren, drücken Sie Ctrl + Alt + F7(erneut, Fnmöglicherweise ist die Taste hier gültig).

Verwandte Probleme