Tut mir leid für Sie, dass Sie auf so viele Probleme und Fehler stoßen. Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen. Wie administrieren, verwalten und nutzen Sie ihre Installation?
Ich weiß, dass das es Ihnen an dieser Stelle primär nicht darum geht, die Problem jetzt/hier zu lösen, sondern darum, dass sie bestehen und Ihre Aufmerksamkeit verlangen. Aber ich würde das schon gerne näher betrachten wollen, um zu erkennen, woran es denn nun gelegen haben könnte. Bei mir hing es erfahrungsgemäß manchmal auch einfach nur an meinen nachlässigen Administrationsentscheidungen der Systeme. Computer und Software sind ziemlich stupide. Man muss Ihnen sehr genau sagen, was Sie wie zu tun haben, das Bedarf die Möglichkeit größerer Konfigurierbarkeit, Flexibilität und Kontrolle der Software. Andernfalls tut sie, was sie will, indem sie stillschweigend unerwünschte Annahmen trifft, was ja auch nicht gerade das gelbe vom Ei ist, wie man hier häufiger zu Themen wie Mozilla und Firefox lesen kann.
Von Kubuntu oder KDE habe ich so gut wie keine Ahnung, aber ich gehe mal auf ein paar vermutlich unspezifischere ProblemeSymptombeschreibungen ein: 1) Shutdown aus KDE: Wenn er ohne KDE funktioniert, liegt wahrscheinlich kein Hardwarefehler vor. Haben Sie an der Software-Installation etwas geändert, neue Netzwerkadapter/-treiber oder Netzwerkeinhängepunkte konfiguriert?
2) KDE Crash Handler bei Shutdown: Hängt wahrscheinlich mit Symptom 1 zusammen, was meine Analysethese zu 1 auch bestätigen würde. Eine Software-Komponente scheint zu hängen. Was wurde zwischenzeitlich am System verändert, bevor der Fehler auftrat? Was sagen die Fehlerprotokolle?
3) Einfrieren: Wenn das ganze System, sprich nicht nur der Desktop, eingefroren ist, liegt es entweder am Kernel oder an der Hardware. Was sagen die Kernel-Logs? Seit wann besteht das Problem? Was wurde davor am System geändert?
4) PulseAudio friert ein: Das Problem hatten Sie kürzlich schon erwähnt. Konnten Sie schon eine Lösung finden? Falls ja, woran lag es letztlich? Woran macht sich das bemerkbar, dass es PulseAudio sein muss? Könnte es nicht auch der Treiber sein, oder hat es zuvor schon funktioniert? Falls ja, was wurde geändert?
5) Neustart von PA / Mikro: Kann eventuell an der Methode liegen, die zum Neustart von PulseAudio genutzt wurde, oder an fehlerhaften Treibern. Was sagen die Logs?
6) Aktuelles Debian und WLAN: Ein aktualisiertes Debian bringt einen neuen Kernel und damit neue Treiber und Firmware mit. Kernelupgrades bringen oftmals schwere Regressionen mit sich, das gibt sogar der ein oder andere Hauptentwickler zu. Vor Allem wenn zwischen den Versionen so ein großer Abstand besteht, in welchem die Regression niemandem auffiel, weil keiner mit der passenden Hardware das Ding getestet hat. Wird das BananaPi von der eingesetzten Debian-Version unterstützt bzw. anders herum? Welcher Chipsatz? Welches Treibermodul? Sind es proprietäre Treiber?
7) X-Plane: Was heißt "lausig"? Und was heißt "gut"? Erfüllen Sie die Angaben des Spieleherstellers über die Voraussetzungen?
8.) Bug in Ubuntu: Die Beiträge zu dem Fehlerbericht sind ja relativ eindeutig. Der Bug bezieht sich auf UEFI-Systeme, die per GRUB 2.04 (speziell die Version aus Ubuntu 19.10) ISO-Abbilder per loopback booten wollen. Es gibt diverse Workarounds, BIOS oder GRUB 2.02 bzw. Ubuntu 18.04 nutzen. An GRUB 2.04 selbst liegt es offenbar auch nicht, da einer schreibt, dass die Version unter Arch Linux keine derartigen Probleme macht. D.h. Ubuntu/Canonical hat's verbockt. Allerdings ist es auch nicht gerade ratsam auf die Zwischenveröffentlichungen XY.10 zu setzen. Dort wird eine Menge probiert und gefrickelt. Die werden auch nur ein paar Monate unterstützt. Man sollte immer bei den LTS-Versionen bleiben, sprich hier 18.04, wo es ja zu funktionieren scheint. Auf einen Fix in 19.10 würde ich an Ihrer Stelle nicht warten.
9) Bei fail2ban kann ich Ihnen auch nicht helfen, aber das wirkte für mich schon immer irgendwie wie große Frickelei. Hatten Sie das Problem nicht auch schon einmal erwähnt? Lag das nicht an der Umstellung von iptables auf nftables, die auch in Debian vollzogen worden ist? Offenbar hat das Ding niemand rechtzeitig getestet. Die Umstellung und etwaige mögliche Probleme waren unter Debian jedenfalls angekündigt worden, bei Ubuntu bestimmt auch. Lesen Sie die Veröffentlichungshinweise? Man kann auf iptables umstellen, soweit ich weiß. Oder man bleibt bei den stabilen LTS-Versionen. Welche Version kam denn zum Einsatz? Was wurde getan, bevor der der Fehler auftrat?
10) Desktop auf aktuellestem Kubuntu friert ein: Der offensichtliche Fix ist, nicht die Zwischenveröffentlichungen XY.10 einzusetzen, und auf die LTS-Versionen zu setzen. Eine Aktualisierung sollten Sie nur mit dem Hintergedanken ausführen, dass diese riskant ist und etwaige Fehler keine größeren Konsequenzen hätten, da Sie per Sicherung oder Zweitsystem zu einem stabilen Zustand gelangen. Inplace-Upgrades werden von Ubuntu meines Wissens nach auch nur bedingt unterstützt. Hatten Sie all' diese Dinge bedacht?
11) QtCreator und Themes: Klingt erstmal nicht wie ein Problem, dass mit Linux oder der Distribution als solche zu tun hätte. Das liegt wohl eher an Qt oder QtCreator selbst, oder einfach nur am Theme.
12) Integration von Gtk3 in KDE: Das Problem hatten Sie kürzlich auch mal geschildert und ich hatte Ihnen ein Fix vorgeschlagen, den Sie nicht kommentiert hatten. Hat das funktioniert? Das Problem besteht schon seit Längerem, mindestens aber seit GNOME und KDE divergieren, was CSD/SSD (Client-Side-Decoration / Server-Side-Decoration) betrifft. Das Problem ist also auf die Fragmentierung und die Auswahl im Ökosystem zurückzuführen. Die Desktops schieben sich Gegenseitig die Schuld zu, soweit ich das erkennen konnte.
13) Dauer des Bootvorgangs: Was wurde denn am System geändert? Upgrade? (K)Ubuntu 19.10? Inplace? Wieso nicht auf LTS bleiben oder zurückrudern?
14) Portierbarkeit von Automatisierungsskripte: Das hatten Sie auch schon mal geschildert. Es stellen sich die selben Fragen, wie in Punkt 13. Und zusätzlich ist fraglich, ob Sie defensiv programmiert haben, d.h. möglichst wenige Annahmen beim Verfassen Ihrer Skripte getroffen haben. Wenn Sie Annahmen treffen, die bei einem Systemupgrade gebrochen werden, funktioniert es nicht mehr korrekt. Sie müssen, falls möglich, gegen dokumentierte Schnittstellen programmieren. Natürlich kann der Fehler auch bei Ubuntu liegen, falls die Änderungen nicht angekündigt worden sind und gegen frühere Doku verstößt. Ubuntu gibt generell keine starken Schnittstellengarantien über Versionsupgrades hinaus. Der offensichtlich Fix ist daher: Systemupgrades meiden, bei LTS-Versionen bleiben und defensiv und sauber gegen Schnittstellen programmieren.
Das ist, was mir direkt einfällt, ohne lange grübeln zu müssen.
Ja, eine durchaus lange Liste. Je nach dem, welche Versionen Sie einsetzen und wie Sie die Systeme administrieren, denke ich, dass hier ein grobes Muster erkennbar sein könnte, aus dem man schließen könnte, dass Sie selbst für einen signifikanten Teil Ihrer Problem im Wesentlichen ursächlich verantwortlich wären. Man beachte bitte den Konjunktiv. Ich möchte Ihnen keine Vorwürfe machen. Ich habe unnötigerweise auch schon etwaige Probleme produziert. Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
>> Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen. >> Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
In der tat ist das alles im Desktop-Bereich GNU/Linux-Typisch - je nach Distributionswahl mehr, oder weniger.
>> Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen. >> Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
Für Leute wie mich, die fast keine Ahnung haben, ist es besonders schwer.
3) Einfrieren: Wenn das ganze System, sprich nicht nur der Desktop, eingefroren ist, liegt es entweder am Kernel oder an der Hardware. Was sagen die Kernel-Logs? Seit wann besteht das Problem? Was wurde davor am System geändert?
Das liegt am Kernel der Serie 5.3 in Verbindung mit dem Grafiktreiber (bei mir Intel i915). Darüber hatte ich an anderer Stelle hier in Pro-Linux schon hingewiesen.
Ab der 5.4er Serie ist das Problem beseitigt. Momentan teste ich bereits die 5.5er Serie der Mainline-Kernels. Läuft wieder einwandfrei. Nur auf dem Notebook tut's etwas weh: Die Energiesparfunktionen inkl. Steuerung der Disply-Helligkeit auf dem Thinkpad funktionieren mit den Mainline-Kerneln nicht mehr, was sich natürlich extrem auf die Akkulaufzeit auswirkt!
Aber das Ruckeln ist auf jeden Fall weg!
Ursache waren extreme Auslagerungsorgien auch bei geringster Auslastung, was zu Beginn zu kurzen Freezes führte und dann in der vollkommenen Unbedienbarkeit des System endete (totale Auslastung). Mir jetzt noch unklar, wie das durchrutschen konnte und auf die Menschheit losgelassen werden konnte. Betraf nicht nur Ubuntu sondern auch Arch und vermutlich andere.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Feb 2020 um 00:36.
Von Josef Hahn xh am So, 9. Februar 2020 um 23:20 #
> Bei mir hing es erfahrungsgemäß manchmal auch einfach nur an meinen nachlässigen Administrationsentscheidungen der Systeme. Computer und Software sind ziemlich stupide. Man muss Ihnen sehr genau sagen, was Sie wie zu tun haben, das Bedarf die Möglichkeit größerer Konfigurierbarkeit, Flexibilität und Kontrolle der Software.
Da habe ich schon ein gewisses Grundverständnis von. Ich bin selbst professioneller Softwareentwickler (allerdings Windoof) und benutze versch. Linuxe seit ~2000, hatte auch schon Arch und Gentoo - und habe die nicht verlassen, weil ich mit denen besonders schlecht klargekommen wäre. Ich bin da also nicht völlig unbeleckt. Ich thematisiere hier nicht die Fälle, wo ich mir selbst ein Bein stelle. Das meiste sind Dinge, die entweder schonmal funktioniert haben (wir hatten die Firefox-Sache ja vor einigen Wochen besprochen - das war auch sowas). Ansonsten Dinge, die ich in zig Konfigurationen, auf zig Maschinen über viele Jahre noch nie funktionierend gesehen habe (Akonadi bspw.).
1) Harter Shutdown per Terminal geht. Auf dem Desktop ist der Ablauf aber komplizierter. Da können/müssen laufende Prozesse interagieren, damit sie "du hast hier noch ungespeicherte...willst du wirklich?"-Meldungen anzeigen können, und ich habe hier vermutlich irgendwas laufen, was diesen Ablauf stört. Früher war Virtualbox so ein Kandidat, wo man das beobachten konnte. Es hat mich gefragt, ich hab gesagt "mach zu", und es hat trotzdem den Shutdown einmal unterbrochen. Das nutze ich nicht mehr, aber das kann prinzipiell jedes Tool.
2) Es sind zufällige Dienste, und ich beobachte das ehrlich gesagt seit eh und je. Meine Vermutung: Sie stürzen halt beim Shutdown einfach ab, weil sie nicht gut gemacht sind. Geordneter Shutdown ist schwieriger, als es klingt. Auswirkungen hat es nicht, außer dass man für einzwei Sekunden den Dialog sieht.
3) Das Problem trat erstmals im ersten Installationsversuch von Kubuntu 19.10 auf. Da stand die Maschine hier aber schon für ~1 Jahr (eher mehr). In den Logs sehe ich nichts; aber wenn das System hart einfriert, ist das ja nicht unüblich.
4) Das hat funktioniert vor der Installation von Debian 10 (vorher lief 9 gut). Ob PA Schuld hat, oder eine Schicht darunter, weiß ich nicht. Lösen konnte ich es bisher nicht. Es "könnte" "irgendwas" mit dem Mikrofon zu tun haben, denn genau das fehlt, nachdem PA neu gestartet wird. Mehr weiß ich noch nicht. Ich habe es auch erstmal beiseitegelegt. Derzeit hängt hier viel an dem Grub-Problem (8), weil daran auch Softwaretests hängen, an denen wiederum die Weiterarbeit an praktisch 'allem anderen' hängt (ja, ich habe sogar Test Cases für den ganzen Kram).
5) Klar, das kann alles sein. Bisher habe ich es nicht gelöst bekommen. PA wird von systemd neu gestartet, sobald es crasht. Logs habe ich jetzt nicht griffbereit, weil die Geräte nicht angeschlossen sind und hier rumfliegen. Da es das WLAN auch nicht tut, benötigt es eine gewisse Vorbereitung, da ran zu kommen.
6) Laut https://wiki.debian.org/InstallingDebianOn/Allwinner sollte es unterstützt sein. Und auch da: Es lief mit Debian 9. Es ist ein Broadcom 43362 Chip. Firmware ist natürlich proprietär, kommt aber alles mit Debian mit. Ich hatte mal eine Äußerung gesehen, die (inoffiziell) bestätigt hat, dass es diese Regression gibt. Link habe ich nicht aufbewahrt, weil es keinerlei weitere Infos hatte, und auch unklar war, ob da jemand etwas wusste oder nur vermutete. Immerhin muss noch jemand über das gleiche Problem gestolpert sein. Die meisten Leute nehmen aber wohl kein normales Debian auf diesen Dingern, daher findet man grundsätzlich wenig.
7) Naja, CPU ist ein Ryzen 7 1800X, 16GB RAM, GPU ist eine Radeon 580X, und >20fps schaffe ich nur mit durchschnittlichen Grafiksettings, die aber offensichtliche Unschönheiten haben. Alles etwas subjektiv, sorry... Aber ich hätte mit dieser Hardware ein deutlich schöneres Resultat erwartet, ohne dass es zur Diaschau verkommt.
Es mag schon sein, dass es ein Ubuntu-Bug ist. Aber das ist halt das, was ich hier habe. Woanders gibt es dann halt andere Bugs. Es erscheint mir unsinnig, die Distribution zu wechseln, weil dieser eine Bug ubuntuspezifisch zu sein scheint. Die genannten Workarounds helfen mir nicht. Hier ist UEFI und Ubuntu 19.04 - und hier muss es funktionieren. Ich kann die Medien nicht mit einem anderen System vorbereiten (was ja grundsätzlich auch ein lausiger Workaround ist). Zu LTS: Bald kommt 20.04 LTS, und den Grub-Bug haben sie bisher nichtmal assigned. Ich weiß was du von meinen dunklen Vorahnungen hälst, aber ich sehe das noch nicht kommen, dass es in der LTS gefixt sein wird.
9) Ja, haben wir schonmal drüber geschrieben. Ja, es wird wohl an nft liegen. Du hast mir auch schon eine Alternative ans Herz gelegt. Das muss ich halt alles nochmal ansehen und prüfen; wie ich ja schrieb. Das betrifft übrigens wieder die Server, und damit Debian. Sie mögen auch irgendwo vor irgendwas warnen, aber das verhindert ja erstmal nicht, dass es zu dieser Regression kommt. Ich muss also auf jeden Fall das Problem lösen; ob die Release Notes mich darauf (mehr oder weniger spezifisch) hinweisen oder nicht.
10) Das klingt so, als müsse man bei nicht-LTS Versionen mit allem rechnen. Das verstehe ich so eigentlich nicht. Wo findet man den Hinweis, dass diese Versionen potentiell diese extremen Probleme haben können? Auch hier bin ich gespannt; die LTS steht ja vor der Tür, d.h. man sollte es deiner Sicht nach eigentlich schon gelöst haben (btw dann hätte ich schon ein Update erwartet), oder kurz davor stehen. Im Allgemeinen zu LTS: Bisher war fast jede Version (Rolling-Release mal ausgeklammert) jeder Distribution, die ich je installiert hatte verbuggt genug, um Hoffnung in die Folgeversion zu haben. Das muss ich überdenken, das stimmt. Aber bisher bin ich nur ein einziges Mal bei einer LTS geblieben. Das war wirklich mal eine Version, die wirklich gut funktioniert hat in allen Belangen und ist schon viele Jahre her. Auch die letzte LTS war imho kein Knaller.
11) Es liegt daran, stumpft gesagt, dass die Entwickler von QtCreator keine Ahnung von Qt haben, oder wieder wieseln wollten um irgendwas besonders 'chic' zu machen. Beides kein Merkmal für tolle Qualität. Am Kernel liegt es nicht, klar. Aber ich habe die Frage so verstanden, dass Linux "im Ganzen" gemeint ist, mitsamt gängiger Userspace-Tools. Das Theme ist übrigens Breeze Dark - ein Standardtheme. Ich würde es hier nicht erwähnen, wenn ein exotisches Theme schuld daran sein könnte, was ich irgendwo im Orkus ausgebuddelt hätte. Man kann in den Settings sogar thememäßig etwas einstellen, was aber per se ja schon wieder eine Krücke ist (ich habs ja im System schon eingestellt; sogar im Qt-basierten KDE), und auch nicht zu perfekten Resultaten führt.
12) Ich kann mich nicht mehr erinnern, was du genau vorgeschlagen hast, sorry. Wenn es gut gemacht wäre, würde ich erwarten, dass es sich ohne mein großes Zutun selbst integriert. Geht ja auch mit Gtk2, und andersrum auch mit Qt. Nur Gtk3 macht irgendwas mit CSS und kann das einfach nicht mehr (und ich behaupte: Den Entwicklern der Gnome'schen Denkschule ist das ganz recht so). CSDs sind auch imho ärgerlich, vorallem wenn die Helden dann den UI-Thread für längere IO-Aktionen lahmlegen, aber darum gings mir jetzt nicht.
13) Ich weiß, dass es mit einem früheren LTS mal praktisch instantan bootete. Zweidrei Sekunden bis zum Login. Das war das o.g. "eine" gute Ubuntu LTS, was ich je hatte. Es wird 14.04 oder 16.04 gewesen sein. Danach habe ich das nicht mehr gesehen. Es war auch andere (schwächere) Hardware. Ich zähle aber natürlich ab Grub, nicht BIOS usw.
14) Nur darüber könnte ich jetzt wieder Bildschirmseiten schreiben. Nur kurz: Ich bastel so wenig wie möglich und mache das natürlich so defensiv, wie es praktisch geht, und gegen dokumentierte Schnittstellen, soweit möglich. Wenn sich Schnittstellen aber häufig ändern, nützt das alles wenig. Was "defensiv" gewesen wäre, weiß man in der Praxis oft erst, wenn etwas passiert ist (bspw. andere Namen des Profilverz. von FF). Vieles - du wirst es selbst wissen - ist auch schlecht dokumentiert, oder garnicht, unvollständig, und oft veraltet. Man kann Plasma bspw. per Javascript steuern. Was du dazu findest, geht teilweise noch auf KDE4 zurück; modernere Fassungen sind dafür massiv unvollständig (und auch nur _weniger_ veraltet).
> Ja, eine durchaus lange Liste. Je nach dem, welche Versionen Sie einsetzen und wie Sie die Systeme administrieren, denke ich, dass hier ein grobes Muster erkennbar sein könnte, aus dem man schließen könnte, dass Sie selbst für einen signifikanten Teil Ihrer Problem im Wesentlichen ursächlich verantwortlich wären. Man beachte bitte den Konjunktiv. Ich möchte Ihnen keine Vorwürfe machen. Ich habe unnötigerweise auch schon etwaige Probleme produziert. Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
Ich bin da nicht eitel, da kann man mit mir schon drüber diskutieren. Ich weiß natürlich auch ganz genau, was du meinst. Und natürlich treten auch Probleme auf, die ich mir selbst eingebrockt habe. Ungünstig konfiguriert, Skripte schlampig implementiert, Denkfehler, falsche Annahmen, ... Das kommt selbstverständlich alles gelegentlich vor. Aber darüber würde ich mich hier nicht auslassen. Was die Workstations (Ubuntu) angeht, magst du auch Recht haben mit LTS. Das sehe ich bald. Ansonsten sehe ich Fehlermuster seit den 20 Jahren, die ich Linux nutze, und ich sehe einfach die Bugs, die viele andere spendabel ausblenden und umschiffen oder aushalten ohne es wirklich zu merken, und ich lasse mich nicht auf die Dauerschleife ein, dann bei jedem Bug auf ein anderes Tool zu wechseln (das kann in einzelnen Fällen auch mal die Lösung sein, aber so einfach, wie immer getan wird, ist es ja nicht). Meistens ist die Schuldfrage formell wahrscheinlich nicht eindeutig klärbar, aber bei einem "guten" System sollten diese Situation garnicht erst so oft eintreten, dass ich wieder nacharbeiten muss, um einer Regression aus dem Weg zu gehen. Da ist eine Nennung in den Release Notes - selbst wenn es sie gibt - auch keine substanzielle Hilfe.
Tut mir leid für Sie, dass Sie auf so viele Probleme und Fehler stoßen. Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen. Wie administrieren, verwalten und nutzen Sie ihre Installation?
Ich weiß, dass das es Ihnen an dieser Stelle primär nicht darum geht, die Problem jetzt/hier zu lösen, sondern darum, dass sie bestehen und Ihre Aufmerksamkeit verlangen. Aber ich würde das schon gerne näher betrachten wollen, um zu erkennen, woran es denn nun gelegen haben könnte. Bei mir hing es erfahrungsgemäß manchmal auch einfach nur an meinen nachlässigen Administrationsentscheidungen der Systeme. Computer und Software sind ziemlich stupide. Man muss Ihnen sehr genau sagen, was Sie wie zu tun haben, das Bedarf die Möglichkeit größerer Konfigurierbarkeit, Flexibilität und Kontrolle der Software. Andernfalls tut sie, was sie will, indem sie stillschweigend unerwünschte Annahmen trifft, was ja auch nicht gerade das gelbe vom Ei ist, wie man hier häufiger zu Themen wie Mozilla und Firefox lesen kann.
Von Kubuntu oder KDE habe ich so gut wie keine Ahnung, aber ich gehe mal auf ein paar vermutlich unspezifischere
ProblemeSymptombeschreibungen ein:1) Shutdown aus KDE: Wenn er ohne KDE funktioniert, liegt wahrscheinlich kein Hardwarefehler vor. Haben Sie an der Software-Installation etwas geändert, neue Netzwerkadapter/-treiber oder Netzwerkeinhängepunkte konfiguriert?
2) KDE Crash Handler bei Shutdown: Hängt wahrscheinlich mit Symptom 1 zusammen, was meine Analysethese zu 1 auch bestätigen würde. Eine Software-Komponente scheint zu hängen. Was wurde zwischenzeitlich am System verändert, bevor der Fehler auftrat? Was sagen die Fehlerprotokolle?
3) Einfrieren: Wenn das ganze System, sprich nicht nur der Desktop, eingefroren ist, liegt es entweder am Kernel oder an der Hardware. Was sagen die Kernel-Logs? Seit wann besteht das Problem? Was wurde davor am System geändert?
4) PulseAudio friert ein: Das Problem hatten Sie kürzlich schon erwähnt. Konnten Sie schon eine Lösung finden? Falls ja, woran lag es letztlich? Woran macht sich das bemerkbar, dass es PulseAudio sein muss? Könnte es nicht auch der Treiber sein, oder hat es zuvor schon funktioniert? Falls ja, was wurde geändert?
5) Neustart von PA / Mikro: Kann eventuell an der Methode liegen, die zum Neustart von PulseAudio genutzt wurde, oder an fehlerhaften Treibern. Was sagen die Logs?
6) Aktuelles Debian und WLAN: Ein aktualisiertes Debian bringt einen neuen Kernel und damit neue Treiber und Firmware mit. Kernelupgrades bringen oftmals schwere Regressionen mit sich, das gibt sogar der ein oder andere Hauptentwickler zu. Vor Allem wenn zwischen den Versionen so ein großer Abstand besteht, in welchem die Regression niemandem auffiel, weil keiner mit der passenden Hardware das Ding getestet hat. Wird das BananaPi von der eingesetzten Debian-Version unterstützt bzw. anders herum? Welcher Chipsatz? Welches Treibermodul? Sind es proprietäre Treiber?
7) X-Plane: Was heißt "lausig"? Und was heißt "gut"? Erfüllen Sie die Angaben des Spieleherstellers über die Voraussetzungen?
8.) Bug in Ubuntu: Die Beiträge zu dem Fehlerbericht sind ja relativ eindeutig. Der Bug bezieht sich auf UEFI-Systeme, die per GRUB 2.04 (speziell die Version aus Ubuntu 19.10) ISO-Abbilder per loopback booten wollen. Es gibt diverse Workarounds, BIOS oder GRUB 2.02 bzw. Ubuntu 18.04 nutzen. An GRUB 2.04 selbst liegt es offenbar auch nicht, da einer schreibt, dass die Version unter Arch Linux keine derartigen Probleme macht. D.h. Ubuntu/Canonical hat's verbockt. Allerdings ist es auch nicht gerade ratsam auf die Zwischenveröffentlichungen XY.10 zu setzen. Dort wird eine Menge probiert und gefrickelt. Die werden auch nur ein paar Monate unterstützt. Man sollte immer bei den LTS-Versionen bleiben, sprich hier 18.04, wo es ja zu funktionieren scheint. Auf einen Fix in 19.10 würde ich an Ihrer Stelle nicht warten.
9) Bei fail2ban kann ich Ihnen auch nicht helfen, aber das wirkte für mich schon immer irgendwie wie große Frickelei. Hatten Sie das Problem nicht auch schon einmal erwähnt? Lag das nicht an der Umstellung von iptables auf nftables, die auch in Debian vollzogen worden ist? Offenbar hat das Ding niemand rechtzeitig getestet. Die Umstellung und etwaige mögliche Probleme waren unter Debian jedenfalls angekündigt worden, bei Ubuntu bestimmt auch. Lesen Sie die Veröffentlichungshinweise? Man kann auf iptables umstellen, soweit ich weiß. Oder man bleibt bei den stabilen LTS-Versionen. Welche Version kam denn zum Einsatz? Was wurde getan, bevor der der Fehler auftrat?
10) Desktop auf aktuellestem Kubuntu friert ein: Der offensichtliche Fix ist, nicht die Zwischenveröffentlichungen XY.10 einzusetzen, und auf die LTS-Versionen zu setzen. Eine Aktualisierung sollten Sie nur mit dem Hintergedanken ausführen, dass diese riskant ist und etwaige Fehler keine größeren Konsequenzen hätten, da Sie per Sicherung oder Zweitsystem zu einem stabilen Zustand gelangen. Inplace-Upgrades werden von Ubuntu meines Wissens nach auch nur bedingt unterstützt. Hatten Sie all' diese Dinge bedacht?
11) QtCreator und Themes: Klingt erstmal nicht wie ein Problem, dass mit Linux oder der Distribution als solche zu tun hätte. Das liegt wohl eher an Qt oder QtCreator selbst, oder einfach nur am Theme.
12) Integration von Gtk3 in KDE: Das Problem hatten Sie kürzlich auch mal geschildert und ich hatte Ihnen ein Fix vorgeschlagen, den Sie nicht kommentiert hatten. Hat das funktioniert? Das Problem besteht schon seit Längerem, mindestens aber seit GNOME und KDE divergieren, was CSD/SSD (Client-Side-Decoration / Server-Side-Decoration) betrifft. Das Problem ist also auf die Fragmentierung und die Auswahl im Ökosystem zurückzuführen. Die Desktops schieben sich Gegenseitig die Schuld zu, soweit ich das erkennen konnte.
13) Dauer des Bootvorgangs: Was wurde denn am System geändert? Upgrade? (K)Ubuntu 19.10? Inplace? Wieso nicht auf LTS bleiben oder zurückrudern?
14) Portierbarkeit von Automatisierungsskripte: Das hatten Sie auch schon mal geschildert. Es stellen sich die selben Fragen, wie in Punkt 13. Und zusätzlich ist fraglich, ob Sie defensiv programmiert haben, d.h. möglichst wenige Annahmen beim Verfassen Ihrer Skripte getroffen haben. Wenn Sie Annahmen treffen, die bei einem Systemupgrade gebrochen werden, funktioniert es nicht mehr korrekt. Sie müssen, falls möglich, gegen dokumentierte Schnittstellen programmieren. Natürlich kann der Fehler auch bei Ubuntu liegen, falls die Änderungen nicht angekündigt worden sind und gegen frühere Doku verstößt. Ubuntu gibt generell keine starken Schnittstellengarantien über Versionsupgrades hinaus. Der offensichtlich Fix ist daher: Systemupgrades meiden, bei LTS-Versionen bleiben und defensiv und sauber gegen Schnittstellen programmieren.
Ja, eine durchaus lange Liste. Je nach dem, welche Versionen Sie einsetzen und wie Sie die Systeme administrieren, denke ich, dass hier ein grobes Muster erkennbar sein könnte, aus dem man schließen könnte, dass Sie selbst für einen signifikanten Teil Ihrer Problem im Wesentlichen ursächlich verantwortlich wären. Man beachte bitte den Konjunktiv. Ich möchte Ihnen keine Vorwürfe machen. Ich habe unnötigerweise auch schon etwaige Probleme produziert. Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.>> Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen.
>> Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
In der tat ist das alles im Desktop-Bereich GNU/Linux-Typisch - je nach Distributionswahl mehr, oder weniger.
>> Kein System ist fehlerfrei, aber man kann gewisse Vorkehrungen treffen, um diesen vorzubeugen.
>> Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
Für Leute wie mich, die fast keine Ahnung haben, ist es besonders schwer.
Ab der 5.4er Serie ist das Problem beseitigt. Momentan teste ich bereits die 5.5er Serie der Mainline-Kernels. Läuft wieder einwandfrei. Nur auf dem Notebook tut's etwas weh: Die Energiesparfunktionen inkl. Steuerung der Disply-Helligkeit auf dem Thinkpad funktionieren mit den Mainline-Kerneln nicht mehr, was sich natürlich extrem auf die Akkulaufzeit auswirkt!
Aber das Ruckeln ist auf jeden Fall weg!
Ursache waren extreme Auslagerungsorgien auch bei geringster Auslastung, was zu Beginn zu kurzen Freezes führte und dann in der vollkommenen Unbedienbarkeit des System endete (totale Auslastung). Mir jetzt noch unklar, wie das durchrutschen konnte und auf die Menschheit losgelassen werden konnte. Betraf nicht nur Ubuntu sondern auch Arch und vermutlich andere.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Feb 2020 um 00:36.> Bei mir hing es erfahrungsgemäß manchmal auch einfach nur an meinen nachlässigen Administrationsentscheidungen der Systeme. Computer und Software sind ziemlich stupide. Man muss Ihnen sehr genau sagen, was Sie wie zu tun haben, das Bedarf die Möglichkeit größerer Konfigurierbarkeit, Flexibilität und Kontrolle der Software.
Da habe ich schon ein gewisses Grundverständnis von. Ich bin selbst professioneller Softwareentwickler (allerdings Windoof) und benutze versch. Linuxe seit ~2000, hatte auch schon Arch und Gentoo - und habe die nicht verlassen, weil ich mit denen besonders schlecht klargekommen wäre. Ich bin da also nicht völlig unbeleckt. Ich thematisiere hier nicht die Fälle, wo ich mir selbst ein Bein stelle. Das meiste sind Dinge, die entweder schonmal funktioniert haben (wir hatten die Firefox-Sache ja vor einigen Wochen besprochen - das war auch sowas). Ansonsten Dinge, die ich in zig Konfigurationen, auf zig Maschinen über viele Jahre noch nie funktionierend gesehen habe (Akonadi bspw.).
1) Harter Shutdown per Terminal geht. Auf dem Desktop ist der Ablauf aber komplizierter. Da können/müssen laufende Prozesse interagieren, damit sie "du hast hier noch ungespeicherte...willst du wirklich?"-Meldungen anzeigen können, und ich habe hier vermutlich irgendwas laufen, was diesen Ablauf stört. Früher war Virtualbox so ein Kandidat, wo man das beobachten konnte. Es hat mich gefragt, ich hab gesagt "mach zu", und es hat trotzdem den Shutdown einmal unterbrochen. Das nutze ich nicht mehr, aber das kann prinzipiell jedes Tool.
2) Es sind zufällige Dienste, und ich beobachte das ehrlich gesagt seit eh und je. Meine Vermutung: Sie stürzen halt beim Shutdown einfach ab, weil sie nicht gut gemacht sind. Geordneter Shutdown ist schwieriger, als es klingt. Auswirkungen hat es nicht, außer dass man für einzwei Sekunden den Dialog sieht.
3) Das Problem trat erstmals im ersten Installationsversuch von Kubuntu 19.10 auf. Da stand die Maschine hier aber schon für ~1 Jahr (eher mehr). In den Logs sehe ich nichts; aber wenn das System hart einfriert, ist das ja nicht unüblich.
4) Das hat funktioniert vor der Installation von Debian 10 (vorher lief 9 gut). Ob PA Schuld hat, oder eine Schicht darunter, weiß ich nicht. Lösen konnte ich es bisher nicht. Es "könnte" "irgendwas" mit dem Mikrofon zu tun haben, denn genau das fehlt, nachdem PA neu gestartet wird. Mehr weiß ich noch nicht. Ich habe es auch erstmal beiseitegelegt. Derzeit hängt hier viel an dem Grub-Problem (8), weil daran auch Softwaretests hängen, an denen wiederum die Weiterarbeit an praktisch 'allem anderen' hängt (ja, ich habe sogar Test Cases für den ganzen Kram).
5) Klar, das kann alles sein. Bisher habe ich es nicht gelöst bekommen. PA wird von systemd neu gestartet, sobald es crasht. Logs habe ich jetzt nicht griffbereit, weil die Geräte nicht angeschlossen sind und hier rumfliegen. Da es das WLAN auch nicht tut, benötigt es eine gewisse Vorbereitung, da ran zu kommen.
6) Laut https://wiki.debian.org/InstallingDebianOn/Allwinner sollte es unterstützt sein. Und auch da: Es lief mit Debian 9. Es ist ein Broadcom 43362 Chip. Firmware ist natürlich proprietär, kommt aber alles mit Debian mit. Ich hatte mal eine Äußerung gesehen, die (inoffiziell) bestätigt hat, dass es diese Regression gibt. Link habe ich nicht aufbewahrt, weil es keinerlei weitere Infos hatte, und auch unklar war, ob da jemand etwas wusste oder nur vermutete. Immerhin muss noch jemand über das gleiche Problem gestolpert sein. Die meisten Leute nehmen aber wohl kein normales Debian auf diesen Dingern, daher findet man grundsätzlich wenig.
7) Naja, CPU ist ein Ryzen 7 1800X, 16GB RAM, GPU ist eine Radeon 580X, und >20fps schaffe ich nur mit durchschnittlichen Grafiksettings, die aber offensichtliche Unschönheiten haben. Alles etwas subjektiv, sorry... Aber ich hätte mit dieser Hardware ein deutlich schöneres Resultat erwartet, ohne dass es zur Diaschau verkommt.
9) Ja, haben wir schonmal drüber geschrieben. Ja, es wird wohl an nft liegen. Du hast mir auch schon eine Alternative ans Herz gelegt. Das muss ich halt alles nochmal ansehen und prüfen; wie ich ja schrieb. Das betrifft übrigens wieder die Server, und damit Debian. Sie mögen auch irgendwo vor irgendwas warnen, aber das verhindert ja erstmal nicht, dass es zu dieser Regression kommt. Ich muss also auf jeden Fall das Problem lösen; ob die Release Notes mich darauf (mehr oder weniger spezifisch) hinweisen oder nicht.
10) Das klingt so, als müsse man bei nicht-LTS Versionen mit allem rechnen. Das verstehe ich so eigentlich nicht. Wo findet man den Hinweis, dass diese Versionen potentiell diese extremen Probleme haben können? Auch hier bin ich gespannt; die LTS steht ja vor der Tür, d.h. man sollte es deiner Sicht nach eigentlich schon gelöst haben (btw dann hätte ich schon ein Update erwartet), oder kurz davor stehen. Im Allgemeinen zu LTS: Bisher war fast jede Version (Rolling-Release mal ausgeklammert) jeder Distribution, die ich je installiert hatte verbuggt genug, um Hoffnung in die Folgeversion zu haben. Das muss ich überdenken, das stimmt. Aber bisher bin ich nur ein einziges Mal bei einer LTS geblieben. Das war wirklich mal eine Version, die wirklich gut funktioniert hat in allen Belangen und ist schon viele Jahre her. Auch die letzte LTS war imho kein Knaller.
11) Es liegt daran, stumpft gesagt, dass die Entwickler von QtCreator keine Ahnung von Qt haben, oder wieder wieseln wollten um irgendwas besonders 'chic' zu machen. Beides kein Merkmal für tolle Qualität. Am Kernel liegt es nicht, klar. Aber ich habe die Frage so verstanden, dass Linux "im Ganzen" gemeint ist, mitsamt gängiger Userspace-Tools. Das Theme ist übrigens Breeze Dark - ein Standardtheme. Ich würde es hier nicht erwähnen, wenn ein exotisches Theme schuld daran sein könnte, was ich irgendwo im Orkus ausgebuddelt hätte. Man kann in den Settings sogar thememäßig etwas einstellen, was aber per se ja schon wieder eine Krücke ist (ich habs ja im System schon eingestellt; sogar im Qt-basierten KDE), und auch nicht zu perfekten Resultaten führt.
12) Ich kann mich nicht mehr erinnern, was du genau vorgeschlagen hast, sorry. Wenn es gut gemacht wäre, würde ich erwarten, dass es sich ohne mein großes Zutun selbst integriert. Geht ja auch mit Gtk2, und andersrum auch mit Qt. Nur Gtk3 macht irgendwas mit CSS und kann das einfach nicht mehr (und ich behaupte: Den Entwicklern der Gnome'schen Denkschule ist das ganz recht so). CSDs sind auch imho ärgerlich, vorallem wenn die Helden dann den UI-Thread für längere IO-Aktionen lahmlegen, aber darum gings mir jetzt nicht.
13) Ich weiß, dass es mit einem früheren LTS mal praktisch instantan bootete. Zweidrei Sekunden bis zum Login. Das war das o.g. "eine" gute Ubuntu LTS, was ich je hatte. Es wird 14.04 oder 16.04 gewesen sein. Danach habe ich das nicht mehr gesehen. Es war auch andere (schwächere) Hardware. Ich zähle aber natürlich ab Grub, nicht BIOS usw.
14) Nur darüber könnte ich jetzt wieder Bildschirmseiten schreiben. Nur kurz: Ich bastel so wenig wie möglich und mache das natürlich so defensiv, wie es praktisch geht, und gegen dokumentierte Schnittstellen, soweit möglich. Wenn sich Schnittstellen aber häufig ändern, nützt das alles wenig. Was "defensiv" gewesen wäre, weiß man in der Praxis oft erst, wenn etwas passiert ist (bspw. andere Namen des Profilverz. von FF). Vieles - du wirst es selbst wissen - ist auch schlecht dokumentiert, oder garnicht, unvollständig, und oft veraltet. Man kann Plasma bspw. per Javascript steuern. Was du dazu findest, geht teilweise noch auf KDE4 zurück; modernere Fassungen sind dafür massiv unvollständig (und auch nur _weniger_ veraltet).
> Ja, eine durchaus lange Liste. Je nach dem, welche Versionen Sie einsetzen und wie Sie die Systeme administrieren, denke ich, dass hier ein grobes Muster erkennbar sein könnte, aus dem man schließen könnte, dass Sie selbst für einen signifikanten Teil Ihrer Problem im Wesentlichen ursächlich verantwortlich wären. Man beachte bitte den Konjunktiv. Ich möchte Ihnen keine Vorwürfe machen. Ich habe unnötigerweise auch schon etwaige Probleme produziert. Das gehört zum Leben und zur der Flexibiltät und der Entwicklungsmentalität von Linux.
Ich bin da nicht eitel, da kann man mit mir schon drüber diskutieren. Ich weiß natürlich auch ganz genau, was du meinst. Und natürlich treten auch Probleme auf, die ich mir selbst eingebrockt habe. Ungünstig konfiguriert, Skripte schlampig implementiert, Denkfehler, falsche Annahmen, ... Das kommt selbstverständlich alles gelegentlich vor. Aber darüber würde ich mich hier nicht auslassen. Was die Workstations (Ubuntu) angeht, magst du auch Recht haben mit LTS. Das sehe ich bald. Ansonsten sehe ich Fehlermuster seit den 20 Jahren, die ich Linux nutze, und ich sehe einfach die Bugs, die viele andere spendabel ausblenden und umschiffen oder aushalten ohne es wirklich zu merken, und ich lasse mich nicht auf die Dauerschleife ein, dann bei jedem Bug auf ein anderes Tool zu wechseln (das kann in einzelnen Fällen auch mal die Lösung sein, aber so einfach, wie immer getan wird, ist es ja nicht). Meistens ist die Schuldfrage formell wahrscheinlich nicht eindeutig klärbar, aber bei einem "guten" System sollten diese Situation garnicht erst so oft eintreten, dass ich wieder nacharbeiten muss, um einer Regression aus dem Weg zu gehen. Da ist eine Nennung in den Release Notes - selbst wenn es sie gibt - auch keine substanzielle Hilfe.