root76
Anmeldungsdatum: 17. Februar 2021
Beiträge: Zähle...
|
Hallo Forum,
Ich hoffe jemand kann mir bei folgendem Problem helfen: Mein Notebook hängt sich in Abständen von einigen Tagen bis hin zu 2 Wochen einfach auf. Der Bildschirm friert ein, die Maus lässt sich nicht mehr bewegen, jegliche Tastatureingaben haben keinen Einfluss...
Ich habe extra mal schnell ein Watchdogskript geschrieben dass den Rechner neu startet wenn man nicht alle 30 Minuten eine Eingabe macht. Aber auch dieses Skript hängt wenn der Rechner in dem Zustand ist. Ich habe erst vor 3 Monaten von Ubuntu 16.04 auf 18.04 und dann auf 20.04 upgegraded. Zusätzlich habe ich die interne 1 TB HDD auf 2 TB aufgerüstet. Zuvor trat das Problem nie auf. Kennt jemand das Phenomen? Wie kann man das Problem einkreisen und/oder lösen?
Ich wüsste leider nicht wo ich da ansetzen soll...
Danke im voraus. 👍 Ein paar Angaben: | sr@vlf:~$ uname -a
Linux vlf 5.4.0-121-generic #137-Ubuntu SMP Wed Jun 15 13:33:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
|
Letzter Eintrag in /var/log/syslog vor dem crash (muss ja nicht zwingend ursächlich sein): | Jun 29 07:43:16 vlf systemd[1]: Finished Daily apt upgrade and clean activities.
Jun 29 07:46:04 vlf gnome-shell[3387]: ###!!! [Child][PStreamFilterChild] Error: RunMessage(msgname=PStreamFilter::Msg_Closed) Channel closing: too late to send/recv, messages will be lost
Jun 29 07:46:10 vlf rtkit-daemon[1213]: Supervising 4 threads of 2 processes of 1 users.
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@>
|
und 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43 | sr@vlf:~$ lscpu
Architektur: x86_64
CPU Operationsmodus: 32-bit, 64-bit
Byte-Reihenfolge: Little Endian
Adressgrößen: 36 bits physical, 48 bits virtual
CPU(s): 4
Liste der Online-CPU(s): 0-3
Thread(s) pro Kern: 1
Kern(e) pro Socket: 4
Sockel: 1
NUMA-Knoten: 1
Anbieterkennung: GenuineIntel
Prozessorfamilie: 6
Modell: 76
Modellname: Intel(R) Pentium(R) CPU N3710 @ 1.60GHz
Stepping: 4
CPU MHz: 1302.647
Maximale Taktfrequenz der CPU: 2560,0000
Minimale Taktfrequenz der CPU: 480,0000
BogoMIPS: 3200.00
Virtualisierung: VT-x
L1d Cache: 96 KiB
L1i Cache: 128 KiB
L2 Cache: 2 MiB
NUMA-Knoten0 CPU(s): 0-3
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT disabled
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Markierungen: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_
tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexp
riority ept vpid tsc_adjust smep erms dtherm ida arat md_clear
sr@vlf:~$ free m
gesamt belegt frei gemeinsam Zwischen verfügbar
Speicher: 7989036 2122008 3903772 412448 1963256 5149240
Auslager: 8228860 0 8228860
|
|
hakel2022
Anmeldungsdatum: 21. Februar 2022
Beiträge: 1402
|
N3710
Neuinstallation mit Xubuntu 22.04
|
root76
(Themenstarter)
Anmeldungsdatum: 17. Februar 2021
Beiträge: 35
|
hakel2022 schrieb: N3710
Neuinstallation mit Xubuntu 22.04
Die Antwort ist mir ein bischen zu kurz.
Wieso schon wieder was neues installieren? Ich bin die dauernden updates und upgrades eigentlich leid und dachte nach dem Umstieg auf 20.04 erstmal wieder meine Ruhe zu haben. Das Ganze muss doch eine Ursache haben. Und die will ich beheben. Und dann soll das Ding endlich mal wieder wenigstens 4 Jahre Ruhe geben.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 7756
|
root76 schrieb: hakel2022 schrieb: Neuinstallation mit Xubuntu 22.04
Die Antwort ist mir ein bischen zu kurz.
Sie ist richtig, allein schon dieses Unsinns wegen: root76 schrieb: Ich habe erst vor 3 Monaten von Ubuntu 16.04 auf 18.04 und dann auf 20.04 upgegraded.
Da hast Du mit Ubuntu Xenial ein bereits 1 Jahr komplett unsupportetes System genutzt. Diese äußerst sicherheitskritische Lage nimmst Du tatsächlich als Ausgangspunkt, um auf ein dahingammelndes Bionic zu distupgraden und dann noch mal ein Distupgrade auf ein bereits alterndes Focal zu fahren. Dazu kommt, daß Distupgrades von einer "LTS" zur nächsten jeweils kein Schritt, sondern ein Sprung sind. root76 schrieb: Und dann soll das Ding endlich mal wieder wenigstens 4 Jahre Ruhe geben.
Vielleicht beschäftigst Du Dich einfach mal mit Grundlagen. Für Ubuntu-"LTS"-Versionen wird 5 Jahre Support versprochen auf main und restricted, nicht auf universe und schon gar nicht auf multiverse. Das ist also bestenfalls für Server zu gebrauchen, aber auch nur dann, wenn man strikt nur aus main und restricted installiert hat. Wer das als Desktop-Version die angeblichen 5 Jahre einsetzt, handelt unwissend oder ignorant und sehr fahrlässig. hakel2022 hat Dir zudem Xubuntu 22.04 für Deine schwache CPU Atom N3710 mit HD Graphics 405 empfohlen. Für sämtliche offiziellen Ubuntu-Flavours wie Xubuntu gibt es in den "LTS"-Versionen zusätzlich zu main und restricted aus universe für 3 Jahre Support, was die jeweilige Desktop-Umgebung betrifft, also das und auch nur das, was das Metapaket in diesem Fall xubuntu-desktop zieht. Jetzt sauber XJammy zu installieren - kein weiteres Distupgrade eines ohnehin schon instabilen Systems - und dann aller 2 Jahre im August mit erstem Pointrelease die nächste "LTS"-Version, sollte jedem möglich sein. Xubuntu 22.04, sinnvollerweise Daily Build (sparst Du ~900 MiB an Updates zur Final letzten April)
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 7478
|
von.wert schrieb:
Jetzt sauber XJammy zu installieren - kein weiteres Distupgrade eines ohnehin schon instabilen Systems - und dann aller 2 Jahre im August mit erstem Pointrelease die nächste "LTS"-Version, sollte jedem möglich sein.
Nur als Erweiterung zum Tipp von von.wert: Arbeitest du mit einer separater Home- Partition? Wenn nein, dann siehe auch Homeverzeichnis (Abschnitt „Die-Home-Partition“) Üblicherweise wählt man für /home eine eigene Partition.
und falls du dich entschließt eine anzulegen, dann hilft dieses Wiki Home umziehen
|
hakel2022
Anmeldungsdatum: 21. Februar 2022
Beiträge: 1402
|
Das Ganze muss doch eine Ursache haben. Und die will ich beheben
Liegt an der "N" Serie. "Beheben" kannst du das Problem -vermutlich- nicht, max. "Verbessern".
1 TB HDD auf 2 TB
Das halte ich schon für einen schweren "Strategiefehler". ☹
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 2627
|
Probiere doch einfach mal ein Jammy Jellyfish Live-System aus, vom USB-Stick oder was auch immer, ob sich so ein Jammy Jellyfish Live-System auf dieser Hardware aufhängt.
|
root76
(Themenstarter)
Anmeldungsdatum: 17. Februar 2021
Beiträge: 35
|
Hm, mein Anliegen war eigentlich deutlich formuliert und ich habe auch kein Interesse an einer Sicherheitsdiskussion.
Das ist ja schon nervig, muss man mal sagen. Mein olles Windows 7 Netbook läuft seit 2010 reibungslos, 12 Jahre! Niemals musste man da Stunden investieren und in Foren diskutieren um das Teil am laufen zu halten. Ich glaube deswegen bleiben so viele bei Windows. Sie haben so derart keinen Bock auf diesen Schlamassel... Aber weiter... OK, also ein Hardwaredefizit eurer Meinung nach. Den Rechner habe ich seit Anfang 2018. Er lief mit 16.04 reibungslos! Genau DAS ist der Grund warum ich ihn eben nicht upgegraded habe, weil ich genau diese Probleme erwartet habe. Zum Glück habe ich vorher noch ein backup gezogen. Aber das kanns ja auch nicht sein... @Berlin_1946: Nein, keine separate Home-partition. @Hakel2022: Verbessern also. Ja und wie? @von.wert: Von einer LTS-Version und nach einem dist-upgrade auf die nächste LTS erwarte ich ein reibungslos funktionierendes, kein "instabiles" System. Wenn eine LTS für 5 Jahre supportet wird dann erwarte ich dass das System 16.04 mindestens bis April 2021 sicher gehalten wird! Das upgrade habe ich dann ein paar Monate vor mir hergeschoben. Das ist meine Entscheidung und Abwägung.
Wenn du behauptest ich hätte durch das dist-upgrade ein instabiles System, dann würde ja jedes System durch dist-upgrades "instabil" werden.
Stell dir alternativ einfach vor ich hätte "ordnungsgemäß" im April 2018 auf 18.04 und im April 2020 auf 20.04 upgegraded. Dann wäre ich doch jetzt an der genau gleichen Stelle. Oder etwa nicht? Ach nee, ich hätte mich dann schon seit April 2020 mit dem aktuellen Problem rumgeschlagen...
Und 20.04 sollte doch wohl auch sicherheitstechnisch ok sein... Zurück zum Problem: Hakel2022 meint man könnte das verbessern. Wie, bitte? Nein, kein komplett neues System installieren. Dazu fehlen mir die Nerven.
|
root76
(Themenstarter)
Anmeldungsdatum: 17. Februar 2021
Beiträge: 35
|
trollsportverein schrieb: Probiere doch einfach mal ein Jammy Jellyfish Live-System aus, vom USB-Stick oder was auch immer, ob sich so ein Jammy Jellyfish Live-System auf dieser Hardware aufhängt.
Danke für die Idee. Das Problem ist nur, dass es teilweise 2 Wochen dauern kann bis es sich aufhängt. Ich müsste dieses System ja auch mit möglichst all den Funktionen ausstatten die ich auf dem aktuellen System nutze, um die Situation nachzubilden. Ansonsten könnte es ja auch statt am System an den Anwendungen leigen, die ich nutze. Klar, ein komplett neues System wird sicher funktionieren aber das ist nicht die Art der Lösung die ich suche.
|
ChickenLipsRfun2eat
Supporter
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12070
|
Hallo! root76 schrieb: Hm, mein Anliegen war eigentlich deutlich formuliert und ich habe auch kein Interesse an einer Sicherheitsdiskussion.
Das wundert dich? Wir haben schon genug Kinderpornos im Netz, da muss keiner Systeme zum Verteilen und Verschleiern mehr anbieten. Würdest du damit offline arbeiten, wäre das alles gar kein Problem. Egal welches OS du da verwendest, es gibt Bots die das Netz nach bekannten Schwachstellen durchforsten und bei alten, nicht mehr gepflegten Systemen automatisch Erfolg haben.
Mein olles Windows 7 Netbook läuft seit 2010 reibungslos…
Da gilt das selbe. Kann mir auch kaum vorstellen, das du da nichts von EOL gelesen hast…
…Von einer LTS-Version und nach einem dist-upgrade erwarte ich ein reibungslos funktionierendes System…Wenn eine LTS für 5 Jahre supportet wird dann erwarte ich dass das System 16.04 mindestens bis April 2021 sicher gehalten wird…
Bekommst du während der jeweiligen Supportzeiträume für main und restricted, wie dir von.Wert schon gesagt hat. Steht auch überall dabei, wie z.B. in LTS. Woher kommt also deine Erwartungshaltung? Das war noch nie anders? Zur Analyse: Du kannst dir alle Fehler mit journalctl anzeigen lassen → journalctl -b -p err um alle Fehler seit dem letzten Reboot anzuzeigen. Diese kannst du dann nach und nach abarbeiten. Du hast mit dem Upgrade von Unity auf die Ubuntu-Version von GNOME3 gewechselt, welches anders funktioniert und auch deutlich mehr Ressourcen braucht. Deswegen wurde dir Xubuntu empfohlen. Ich würde sogar Lubuntu wählen, das ist noch ein wenig rudimentärer und somit ressourcenschonender. Hast du vor dem Upgrade alle proprietären Pakete deinstalliert? Vermutlich nicht → könnte auch eine Problemstelle sein. Da kann auch keiner was dran ändern, weil proprietär. apt purge und aktuelles ziehen. Ein System neu aufsetzen dauert 20 Minuten, gut bei einem sehr langsamen Rechner vielleicht 10 Minuten länger. Danach spielst du die noch relevanten Daten des Homeverzeichnis aus deinem Backup zurück. Fertig. Da sich die Oberfläche sowieso geändert hat musst du die in jedem Fall neu konfigurieren. btw: Es gibt auch Systeme mit längeren Supporträumen, allerdings dürfte deine Maschine für die wirklich zu schwach sein. Die machen schon auf aktuellen Rechnern wenig Spaß.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 7756
|
root76 schrieb:
Mein olles Windows 7 Netbook läuft seit 2010 reibungslos, 12 Jahre!
Du zeigst an jeder Stelle deutlich, daß Du es nicht verstehst und auch nicht verstehen willst. Keines weiteren Supports wert.
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 2627
|
Fährst Du das System richtig runter, also so wie es ein:
systemctl poweroff
machen würde?
Oder wird das System 2 Wochen am Stück ohne richtiges herunterfahren zum Absturz provoziert? Die in die CPU integrierte Intel HD Graphics 405 (Braswell) scheint auch nicht so ganz unproblematisch zu sein. Möglicherweise hilft ein begrenzen der Schlafzustände auf dieser sehr schwachen Hardware. In die /etc/default/grub könnte folgendes hinein editiert werden:
intel_idle.max_cstate=1 i915.enable_dc=0
In der Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT beginnt. Anschließend:
sudo update-initramfs -c -k all && sudo update-grub
Und dann rebooten. intel_idle.max_cstate=1 verhindet dass die CPU zu tief einschläft. i915.enable_dc=0 verhindert dass die Grafikeinheit zu tief einschläft. Edit: oh, sogar auf Wikipedia sind die Probleme dieser Hardware nachzulesen unter Errata:
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 7478
|
root76 schrieb:
Mein olles Windows 7 Netbook läuft seit 2010 reibungslos, 12 Jahre!
Schon mal das aus dem Anhang erhalten und gelesen?
- Bilder
|
root76
(Themenstarter)
Anmeldungsdatum: 17. Februar 2021
Beiträge: 35
|
ChickenLipsRfun2eat schrieb: Hallo! root76 schrieb: Hm, mein Anliegen war eigentlich deutlich formuliert und ich habe auch kein Interesse an einer Sicherheitsdiskussion.
Das wundert dich? Wir haben schon genug Kinderpornos im Netz, da muss keiner Systeme zum Verteilen und Verschleiern mehr anbieten. Würdest du damit offline arbeiten, wäre das alles gar kein Problem. Egal welches OS du da verwendest, es gibt Bots die das Netz nach bekannten Schwachstellen durchforsten und bei alten, nicht mehr gepflegten Systemen automatisch Erfolg haben.
Sorry, ich kann mich da nur wiederholen: Es geht in diesem thread nicht um das Thema Systemsicherheit sondern um Systemstabilität, um ein ganz konkretes, in der Ausgangsbeschreibung formuliertes Anliegen. ChickenLipsRfun2eat schrieb: Zur Analyse: Du kannst dir alle Fehler mit journalctl anzeigen lassen → journalctl -b -p err um alle Fehler seit dem letzten Reboot anzuzeigen. Diese kannst du dann nach und nach abarbeiten. Du hast mit dem Upgrade von Unity auf die Ubuntu-Version von GNOME3 gewechselt, welches anders funktioniert und auch deutlich mehr Ressourcen braucht. Deswegen wurde dir Xubuntu empfohlen. Ich würde sogar Lubuntu wählen, das ist noch ein wenig rudimentärer und somit ressourcenschonender.
Danke. Das ist mal eine würdige, nachvollziehbare sachliche Antwort. Die hätte ich gern als erste Reaktion gelesen.
Ich werf' doch nicht mein komplettes System über den Haufen, nur weil jemand als erste Reaktion schreibt "Neuinstallation mit Xubuntu 22.04". Am Ende macht man das, und danach schreibt jemand anders dass es auch viel einfacher gegangen wäre.
Ein Tipp ohne eine Erklärung/Begründung ist ziemlich wertlos. Der Nutzer will etwas dazu lernen und nicht einfach eine Anweisung erhalten.
so... Das mit journalctl wird wohl nicht funktionieren, da dort ja nicht steht was zum Zeitpunkt des Systemcrashes passierte, denn das war ja vor dem Neustart.
Trotzdem nützlich..
Hast du vor dem Upgrade alle proprietären Pakete deinstalliert? Vermutlich nicht → könnte auch eine Problemstelle sein. Da kann auch keiner was dran ändern, weil proprietär. apt purge und aktuelles ziehen. Ein System neu aufsetzen dauert 20 Minuten, gut bei einem sehr langsamen Rechner vielleicht 10 Minuten länger. Danach spielst du die noch relevanten Daten des Homeverzeichnis aus deinem Backup zurück. Fertig. Da sich die Oberfläche sowieso geändert hat musst du die in jedem Fall neu konfigurieren. btw: Es gibt auch Systeme mit längeren Supporträumen, allerdings dürfte deine Maschine für die wirklich zu schwach sein. Die machen schon auf aktuellen Rechnern wenig Spaß.
Wenn man sich mit allem routinemäßig auskennt mag das 20 Minuten dauern, nicht aber wenn man das noch nie gemacht hat. Nein, ich habe vorher keine Pakete deinstalliert, weil ich nicht wusste dass das notwendig ist. Woher hätte ich es auch vorher wissen sollen... Artikel lesen, und man-pages natürlich. Das wären dann weitere 20 Minuten nehme ich an...
|
root76
(Themenstarter)
Anmeldungsdatum: 17. Februar 2021
Beiträge: 35
|
trollsportverein schrieb: Fährst Du das System richtig runter, also so wie es ein:
systemctl poweroff
machen würde?
Da ich meist um die 10 Webseiten geöffnet habe und nicht immer alles neu laden will versetze ich das Notebook immer in standby. Vielleicht im Schnitt alle 3 Wochen neustarte ich mal, wenn mir der Aufhänger nicht zuvor kommt. Dann meist mit einem einfachen "reboot" im Terminal.
Oder wird das System 2 Wochen am Stück ohne richtiges herunterfahren zum Absturz provoziert?
Wieso sollte es dadurch zum Absturz provoziert werden? Ist das etwa auch nicht erlaubt, einen Rechner einfach laufen zu lassen?
Die in die CPU integrierte Intel HD Graphics 405 (Braswell) scheint auch nicht so ganz unproblematisch zu sein. Möglicherweise hilft ein begrenzen der Schlafzustände auf dieser sehr schwachen Hardware. In die /etc/default/grub könnte folgendes hinein editiert werden:
intel_idle.max_cstate=1 i915.enable_dc=0
In der Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT beginnt. Anschließend:
sudo update-initramfs -c -k all && sudo update-grub
Und dann rebooten. intel_idle.max_cstate=1 verhindet dass die CPU zu tief einschläft. i915.enable_dc=0 verhindert dass die Grafikeinheit zu tief einschläft. Edit: oh, sogar auf Wikipedia sind die Probleme dieser Hardware nachzulesen unter Errata:
OK, aber das Problem tritt mitten im funktionierenden System auf, also heute morgen z.B. lade ich eine Webseite, lese diese, will wo drauf klicken und bemerke plötzlich dass die Maus nicht mehr reagiert, garnix reagiert, auch nicht mein watchdog-Skript. Zum Zeitpunkt vor dem Aufhänger hat also weder die CPU noch die GPU geschlafen.
Wäre es ein GPU-Problem, dann müsste ja das watchdog-Skript noch funktionieren und den Rechner nach einer Zeit neustarten...
|