- Registriert
- 12 Jan. 2020
- Beiträge
- 50
hallo, ich poste deshalb im Linux-Subforum, weil das Problem in erster Linie mit Linux zu tun hat. Ich würde jedoch nicht ausschließen, dass es sich um Hardware-Problem handelt und ins P-Serie-Subforum gehört. Falls dem so sein sollte, tut es mir leid.
Ih habe seit einigen Wochen ein Thinkpad P43S und verwende die Vorabversion von Kubuntu 20.04. mit Kernel 5.4.0-14.
Das folgende Problem liegt war jedoch auch unter 19.10 in exakt gleicher Ausprägung schon aufgetreten.
Dies war auch eine Hoffnungen hinter dem Wechsel hin zur Beta-Version von Focal Fossa, wenngleich die ausschlaggebenden Gründe andere waren.
Das Problem tritt glücklicherweise nur sporadisch auf, sodass ich es bisher immer zähneknirschend mit dem Power-Buttion „weggedrückt“ habe.
Um zur Sache zu kommen: Manchmal schlägt der Boot-Vorgang fehl. Dabei gibt es drei unterschiedliche Szenarien:
1. Das System bleibt im Plymouth-Spash-Screen von Kubuntu hängen. (mittlere Häufigkeit)
2. Anstelle von SDDM taucht ein nicht blinkender Cursor oben links auf — ebenfalls auf unbegrenzte Zeit. (sehr selten)
3. Es erscheint folgende Fehlermeldung (am häufigsten) :
Für das Bild habe ich natürlich den Plymouth-Screen deaktiviert und "noplymouth" anstelle von "quit splash" gesetzt — eben um die Log-Meldungen zu sehen, wobei der letzte Teil auch schon mit "quit splash" sporadisch aufgetreten war, allerdings nur teilweise — manchmal eben auch nur der hängende Splash-Screen oder der weiße Cursor.
Das erste Szenario wird mit "noplymouth" so in der Form natürlich nicht mehr auftreten, denn ein Splash-Screen, der nicht geladen wird, beibt auch nicht hängen.
Das Problem trat »gefühlt« häufig nach dem Switchen zwischen GPU-Modi auf, sprich »intel« vs »on-demand« vs »nvidia«. Allerdings nur »gefühlt« und es kann auch Zufall sein, denn dank Render-Offloading via Nvidia-PRIME ist die Zahl der GPU-Switches sehr überschaubar und war bisher eigentlich nur zu Testzwecken und einmal als wegen eines temporären Bugs in KDE Plasma 5 mit dem Nvidia-Treiber (wurde binnen zwei Tagen gefixt). Da ist erst eine Fehlermeldung im Zusammenhang mit VirtualBox. VirtualBox ist installiert.
Nun werde ich darauf hingewiesen, dass ein Debug-Kernel geladen wird.
Anschlieißend Letzt ist ein Modul/Gerät "not responding".
Am Ende steht dann eine Warteschleife auf einen »start job«, um unbenutzte Blöcke zu entfernen. Ich hatte hin und wieder auch schon längere Zeit gewartet gewartet (Toilette, Kaffee, Einkaufen) und es ist bisher noch nicht von alleine verschwunden.
Wie schon geschrieben, ist dieses Szenario schon in gleicher Weise schon unter Kubuntu 19.10 mit Kernel 5.3 aufgetreten.
Unter Windows 10 ist mir bislang nichts dergleichen aufgefallen. Allerdings fehlt mir da die empirische Erfahrung, weil ich das native Windows bisher erst dreimal gestartet habe, weshalb ich auch schon den Key auf eine VirtualBox umgelegt habe. Irgendwann werde ich es wahrscheinlich auch löschen.
Doch zur Zeit brauche ich den Speicherplatz nicht.
Ih habe seit einigen Wochen ein Thinkpad P43S und verwende die Vorabversion von Kubuntu 20.04. mit Kernel 5.4.0-14.
Das folgende Problem liegt war jedoch auch unter 19.10 in exakt gleicher Ausprägung schon aufgetreten.
Dies war auch eine Hoffnungen hinter dem Wechsel hin zur Beta-Version von Focal Fossa, wenngleich die ausschlaggebenden Gründe andere waren.
Das Problem tritt glücklicherweise nur sporadisch auf, sodass ich es bisher immer zähneknirschend mit dem Power-Buttion „weggedrückt“ habe.
Um zur Sache zu kommen: Manchmal schlägt der Boot-Vorgang fehl. Dabei gibt es drei unterschiedliche Szenarien:
1. Das System bleibt im Plymouth-Spash-Screen von Kubuntu hängen. (mittlere Häufigkeit)
2. Anstelle von SDDM taucht ein nicht blinkender Cursor oben links auf — ebenfalls auf unbegrenzte Zeit. (sehr selten)
3. Es erscheint folgende Fehlermeldung (am häufigsten) :
Für das Bild habe ich natürlich den Plymouth-Screen deaktiviert und "noplymouth" anstelle von "quit splash" gesetzt — eben um die Log-Meldungen zu sehen, wobei der letzte Teil auch schon mit "quit splash" sporadisch aufgetreten war, allerdings nur teilweise — manchmal eben auch nur der hängende Splash-Screen oder der weiße Cursor.
Das erste Szenario wird mit "noplymouth" so in der Form natürlich nicht mehr auftreten, denn ein Splash-Screen, der nicht geladen wird, beibt auch nicht hängen.
Das Problem trat »gefühlt« häufig nach dem Switchen zwischen GPU-Modi auf, sprich »intel« vs »on-demand« vs »nvidia«. Allerdings nur »gefühlt« und es kann auch Zufall sein, denn dank Render-Offloading via Nvidia-PRIME ist die Zahl der GPU-Switches sehr überschaubar und war bisher eigentlich nur zu Testzwecken und einmal als wegen eines temporären Bugs in KDE Plasma 5 mit dem Nvidia-Treiber (wurde binnen zwei Tagen gefixt). Da ist erst eine Fehlermeldung im Zusammenhang mit VirtualBox. VirtualBox ist installiert.
Nun werde ich darauf hingewiesen, dass ein Debug-Kernel geladen wird.
Anschlieißend Letzt ist ein Modul/Gerät "not responding".
Am Ende steht dann eine Warteschleife auf einen »start job«, um unbenutzte Blöcke zu entfernen. Ich hatte hin und wieder auch schon längere Zeit gewartet gewartet (Toilette, Kaffee, Einkaufen) und es ist bisher noch nicht von alleine verschwunden.
Wie schon geschrieben, ist dieses Szenario schon in gleicher Weise schon unter Kubuntu 19.10 mit Kernel 5.3 aufgetreten.
Unter Windows 10 ist mir bislang nichts dergleichen aufgefallen. Allerdings fehlt mir da die empirische Erfahrung, weil ich das native Windows bisher erst dreimal gestartet habe, weshalb ich auch schon den Key auf eine VirtualBox umgelegt habe. Irgendwann werde ich es wahrscheinlich auch löschen.
Doch zur Zeit brauche ich den Speicherplatz nicht.
Zuletzt bearbeitet:
