Kernelupdate Suse 15.3 vom 18.7.2021
Hallo *, gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten. Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten. Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen? Gruß Robert -- Homepage: https://www.familiegrosskopf.de/robert
Hallo Robert,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Ich habe gestern auch große Probleme auf einem Server nach dem Kernelupdate gehabt (openSUSE Leap 15.3, Intel CPU i7-7700, Festplatten mit XFS Filesystem und Software RAID-1). Nach jedem Reboot fror das System schon nach wenigen Sekunden oder etwa einer Minute ein. Teils stieg die Load schnell auf über 100 an. Zunächst hatte ich das auf eventuelle Probleme mit dem verwendeten RAID-1 zurückgeführt (teils resync aktiv), dann gab es aber auch Konsolen-Meldungen vom syslogd wie watchdog: BUG: soft lockup - CPU#2 stuck for ... Teils schien der Server noch lesen aber nicht mehr schreiben zu können. Letztlich half der Reboot vom vorigen Kernel 5.3.18-150300.59.76-default statt des aktuellen kernel-default-5.3.18-150300.59.81.1). Zu einem Bug-Report konnte ich mich nicht recht durchringen, da ich von der Thematik nicht viel verstehe und die diversen zugehörigen Informationen in "/var/log/messages" und "/var/log/warn" nicht deuten konnte. Auf meinem Home-System (allerdings u.a. ohne RAID-1) macht der neue Kernel keine Probleme. Viele Grüße Jens P.S.: Wie kann man eigentlich generell mit zypper, yast2 oder rpm die Änderungen in einem Paket-Update abrufen? Ich fand zwar für den Kernel rpm -q --changelog kernel-default aber die ausgegebenen Informationen stammen noch von "Mi Jun 15 2022" während https://www.suse.com/support/update/announcement/2022/suse-su-20222422-1/ vermutlich aktueller ist (ok, das meiste verstehe ich sowieso nicht, ich wollte nur nachsehen, ob irgendetwas bezüglich XFS oder RAID-1 gepatcht wurde).
Hi, On Tue, Jul 19, 2022 at 05:27:25PM +0200, Jens Schleusener wrote:
Hallo Robert,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Ich habe gestern auch große Probleme auf einem Server nach dem Kernelupdate gehabt (openSUSE Leap 15.3, Intel CPU i7-7700, Festplatten mit XFS Filesystem und Software RAID-1). Nach jedem Reboot fror das System schon nach wenigen Sekunden oder etwa einer Minute ein. Teils stieg die Load schnell auf über 100 an. Zunächst hatte ich das auf eventuelle Probleme mit dem verwendeten RAID-1 zurückgeführt (teils resync aktiv), dann gab es aber auch Konsolen-Meldungen vom syslogd wie
watchdog: BUG: soft lockup - CPU#2 stuck for ...
Teils schien der Server noch lesen aber nicht mehr schreiben zu können.
Letztlich half der Reboot vom vorigen Kernel 5.3.18-150300.59.76-default statt des aktuellen kernel-default-5.3.18-150300.59.81.1).
Zu einem Bug-Report konnte ich mich nicht recht durchringen, da ich von der Thematik nicht viel verstehe und die diversen zugehörigen Informationen in "/var/log/messages" und "/var/log/warn" nicht deuten konnte.
Auf meinem Home-System (allerdings u.a. ohne RAID-1) macht der neue Kernel keine Probleme.
Viele Grüße
Jens
P.S.: Wie kann man eigentlich generell mit zypper, yast2 oder rpm die Änderungen in einem Paket-Update abrufen? Ich fand zwar für den Kernel
rpm -q --changelog kernel-default
aber die ausgegebenen Informationen stammen noch von "Mi Jun 15 2022" während
https://www.suse.com/support/update/announcement/2022/suse-su-20222422-1/
vermutlich aktueller ist (ok, das meiste verstehe ich sowieso nicht, ich wollte nur nachsehen, ob irgendetwas bezüglich XFS oder RAID-1 gepatcht wurde).
Lieber in unser advisory schauen, das rpm changelog ist etwas unleserlicher;) Wenn du bei dem soft lockup noch als root: dmesg >logfile machen kannst und uns das logfile mal schicken kannst, wuerde es helfen evt. Ciao, Marcus
On Tue, 19 Jul 2022, Jens Schleusener wrote:
Hallo Robert,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Ich habe gestern auch große Probleme auf einem Server nach dem Kernelupdate gehabt (openSUSE Leap 15.3, Intel CPU i7-7700, Festplatten mit XFS Filesystem und Software RAID-1). Nach jedem Reboot fror das System schon nach wenigen Sekunden oder etwa einer Minute ein. Teils stieg die Load schnell auf über 100 an. Zunächst hatte ich das auf eventuelle Probleme mit dem verwendeten RAID-1 zurückgeführt (teils resync aktiv), dann gab es aber auch Konsolen-Meldungen vom syslogd wie
watchdog: BUG: soft lockup - CPU#2 stuck for ...
Teils schien der Server noch lesen aber nicht mehr schreiben zu können.
Letztlich half der Reboot vom vorigen Kernel 5.3.18-150300.59.76-default statt des aktuellen kernel-default-5.3.18-150300.59.81.1).
Zu einem Bug-Report konnte ich mich nicht recht durchringen, da ich von der Thematik nicht viel verstehe und die diversen zugehörigen Informationen in "/var/log/messages" und "/var/log/warn" nicht deuten konnte.
Auf meinem Home-System (allerdings u.a. ohne RAID-1) macht der neue Kernel keine Probleme.
Eine kleine Warnung an Mitbetroffene: Zumindest auf meinem "Problem"-System zeigte der neue Kernel kernel-default-5.3.18-150300.59.87.1 dieselben Symptome. Viele Grüße Jens Halb-OT: Leider habe ich dieses Mal das gehostete System durch Restaurieren (Kopieren) des vorangegangen funktionierendem /boot Verzeichnisses nicht mehr lauffähig bekommen (erst kein Netzwerk und jetzt wohl auch noch grub Fehler), GAU.
Am 26.07.22 um 23:27 schrieb Jens Schleusener: (...)
Halb-OT: Leider habe ich dieses Mal das gehostete System durch Restaurieren (Kopieren) des vorangegangen funktionierendem /boot Verzeichnisses nicht mehr lauffähig bekommen (erst kein Netzwerk und jetzt wohl auch noch grub Fehler), GAU.
Dabei hat es bei mir geholfen das installierte System(!) von der ISO zu booten (Advanced Options) und dann den grub auf den vorhergehenden Kernel umzustellen. Anschließend habe ich den grub neu konfiguriert (grub-mkconfig -o <pfad>. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am Dienstag, 26. Juli 2022, 23:27:05 CEST schrieb Jens Schleusener:
On Tue, 19 Jul 2022, Jens Schleusener wrote:
Hallo Robert,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze
Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade
auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Ich habe gestern auch große Probleme auf einem Server nach dem Kernelupdate gehabt (openSUSE Leap 15.3, Intel CPU i7-7700, Festplatten mit XFS Filesystem und Software RAID-1). Nach jedem Reboot fror das System schon nach wenigen Sekunden oder etwa einer Minute ein. Teils stieg die Load schnell auf über 100 an. Zunächst hatte ich das auf eventuelle Probleme mit dem verwendeten RAID-1 zurückgeführt (teils resync aktiv), dann gab es aber auch Konsolen-Meldungen vom syslogd wie
watchdog: BUG: soft lockup - CPU#2 stuck for ...
Teils schien der Server noch lesen aber nicht mehr schreiben zu können.
Letztlich half der Reboot vom vorigen Kernel 5.3.18-150300.59.76-default statt des aktuellen kernel-default-5.3.18-150300.59.81.1).
Zu einem Bug-Report konnte ich mich nicht recht durchringen, da ich von der Thematik nicht viel verstehe und die diversen zugehörigen Informationen in "/var/log/messages" und "/var/log/warn" nicht deuten konnte.
Auf meinem Home-System (allerdings u.a. ohne RAID-1) macht der neue Kernel
keine Probleme.
Eine kleine Warnung an Mitbetroffene: Zumindest auf meinem "Problem"-System zeigte der neue Kernel
kernel-default-5.3.18-150300.59.87.1
dieselben Symptome.
Viele Grüße
Jens
Halb-OT: Leider habe ich dieses Mal das gehostete System durch Restaurieren (Kopieren) des vorangegangen funktionierendem /boot Verzeichnisses nicht mehr lauffähig bekommen (erst kein Netzwerk und jetzt wohl auch noch grub Fehler), GAU.
Also bei mir scheint der neue Kernel (kernel-preempt-5.3.18-150300.59.87.1) nun keine Probleme zu machen. Mal abwarten. Gruß Herbert
On Tue, 26 Jul 2022, Jens Schleusener wrote:
On Tue, 19 Jul 2022, Jens Schleusener wrote:
Hallo Robert,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Ich habe gestern auch große Probleme auf einem Server nach dem Kernelupdate gehabt (openSUSE Leap 15.3, Intel CPU i7-7700, Festplatten mit XFS Filesystem und Software RAID-1). Nach jedem Reboot fror das System schon nach wenigen Sekunden oder etwa einer Minute ein. Teils stieg die Load schnell auf über 100 an. Zunächst hatte ich das auf eventuelle Probleme mit dem verwendeten RAID-1 zurückgeführt (teils resync aktiv), dann gab es aber auch Konsolen-Meldungen vom syslogd wie
watchdog: BUG: soft lockup - CPU#2 stuck for ...
Teils schien der Server noch lesen aber nicht mehr schreiben zu können.
Letztlich half der Reboot vom vorigen Kernel 5.3.18-150300.59.76-default statt des aktuellen kernel-default-5.3.18-150300.59.81.1).
Zu einem Bug-Report konnte ich mich nicht recht durchringen, da ich von der Thematik nicht viel verstehe und die diversen zugehörigen Informationen in "/var/log/messages" und "/var/log/warn" nicht deuten konnte.
Auf meinem Home-System (allerdings u.a. ohne RAID-1) macht der neue Kernel keine Probleme.
Eine kleine Warnung an Mitbetroffene: Zumindest auf meinem "Problem"-System zeigte der neue Kernel
kernel-default-5.3.18-150300.59.87.1
dieselben Symptome.
Viele Grüße
Jens
Halb-OT: Leider habe ich dieses Mal das gehostete System durch Restaurieren (Kopieren) des vorangegangen funktionierendem /boot Verzeichnisses nicht mehr lauffähig bekommen (erst kein Netzwerk und jetzt wohl auch noch grub Fehler), GAU.
Ich muss meine Aussage teilweise revidieren: Nach der Erfolgsmeldung von Herbert Albert habe ich noch einmal das Rescue System meines Providers gestartet und erneut das gestern Abend erstellte und gesicherte /boot Verzeichnis mit Kernel 5.3.18-150300.59.87-default durch Kopieren zum aktuellen gemacht. Danach klappte das Booten nach einem Hardware-Reset und "überraschenderweise" scheint das System nun soweit stabil zu laufen. Auch die diversen unverstandenen Fehlermeldungen in /var/log/warn, die möglicherweise auf partielle Schreibprobleme hindeuten könnten, sind verschwunden. Ich erwähne noch einmal, dass es sich um ein XFS Filesystem mit Software RAID 1 Nutzung handelt. Möglicherweise schwächelt das RAID System auch etwas, da bei etwas heftigerer Nutzung das System bei gleichzeitigen einfachen interaktiven Tätigkeiten (Konsolekommandos, vim) teils 5-10 Sekunden lang nicht reagiert (Schreibprobleme?). Auffällig ist auch, dass im /boot Verzeichnis nun drei statt der normal zwei Kernel zu finden sind, wobei die Datei initrd-5.3.18-150300.59.76-default (erster problematischer Kernel) nun seltsamerweise 3.2 % kleiner ist als in den zuvor gesicherten und noch verfügbaren /boot Verzeichnissen. Zu einem erneuten Kontroll-Reboot konnte ich mich aber noch nicht durchringen, da meine Nerven sich erst einmal erholen müssen. Viele Grüße Jens
Am 19.07.22 um 16:06 schrieb Robert Großkopf:
Hallo *,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Gruß
Robert
Hallo Robert, ich nehme an, du meinst das Update auf Kernel 5.3.18-150300.59.81-default. Bei mir hat sich nach dem Kernelupdate (*) das komplette Betriebssystem aufgehängt. Uhr bleibt stehen, <Strg>+<Alt>+<F1> funktioniert nicht. Beim nächsten Versuch ist das bereits während des Startvorgangs vor dem Erscheinen des (grafischen) Login-Screens passiert. Mit dem vorherigen Kernel 5.3.18-150300.59.76-default funktioniert jedoch alles. Liegt anscheinend am Kernel. Viele Grüße, Klaus (*) Dabei gab es folgende Updates: - 2022-07-19 16:01:49|install|kernel-default|5.3.18-150300.59.81.1|x86_64||repo-sle-update|c2055d0d7767a073780c76efdf1b1f81e43ab8 2b4bff7cc238b49a0a4db8e56f| - 2022-07-19 16:01:55|install|kernel-default-extra|5.3.18-150300.59.81.1|x86_64||repo-sle-update|8f1ef015d56b7c2ea469b4e8a7640450 3ec8586fb7c1d480acbeb20025a4129c| - 2022-07-19 16:02:00|install|kernel-default-optional|5.3.18-150300.59.81.1|x86_64||repo-sle-update|5f791a74f07d9238cbececd479607 81a73a64ac06f01636707c912326bad518b|
Am Dienstag, 19. Juli 2022, 17:56:46 CEST schrieb funedv@gmx.de:
Am 19.07.22 um 16:06 schrieb Robert Großkopf:
Hallo *,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Gruß
Robert
Hallo Robert,
ich nehme an, du meinst das Update auf Kernel 5.3.18-150300.59.81-default.
Bei mir hat sich nach dem Kernelupdate (*) das komplette Betriebssystem aufgehängt. Uhr bleibt stehen, <Strg>+<Alt>+<F1> funktioniert nicht. Beim nächsten Versuch ist das bereits während des Startvorgangs vor dem Erscheinen des (grafischen) Login-Screens passiert.
Mit dem vorherigen Kernel 5.3.18-150300.59.76-default funktioniert jedoch alles.
Liegt anscheinend am Kernel.
Viele Grüße, Klaus
(*) Dabei gab es folgende Updates:
- 2022-07-19 16:01:49|install|kernel-default|5.3.18-150300.59.81.1|x86_64||repo-sle-updat e|c2055d0d7767a073780c76efdf1b1f81e43ab8 2b4bff7cc238b49a0a4db8e56f| - 2022-07-19 16:01:55|install|kernel-default-extra|5.3.18-150300.59.81.1|x86_64||repo-sle -update|8f1ef015d56b7c2ea469b4e8a7640450 3ec8586fb7c1d480acbeb20025a4129c| - 2022-07-19 16:02:00|install|kernel-default-optional|5.3.18-150300.59.81.1|x86_64||repo- sle-update|5f791a74f07d9238cbececd479607 81a73a64ac06f01636707c912326bad518b| Hallo Klaus,
nicht nur beim default Kernel auch beim preempt war es etwas nervenaufreibend. Nach dem update war ein reboot angefordert. Der Rechner hat ständig auf die Platte zugegriffen und mehrmals versucht zu booten. Erst nachdem Ruhe auf der Platte war habe ich ihn aus- und wieder eingeschalten, dann hat er richtig gebootet, auch wieder mit Display. Gruß Herbert
Am Dienstag, 19. Juli 2022, 19:32:52 CEST schrieb Herbert Albert:
Am Dienstag, 19. Juli 2022, 17:56:46 CEST schrieb funedv@gmx.de:
Am 19.07.22 um 16:06 schrieb Robert Großkopf:
Hallo *,
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. Das ist nicht nur in KDE so, sondern zeigte gerade auch in IceWM mit Yast das gleiche Verhalten.
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen?
Gruß
Robert
Hallo Robert,
ich nehme an, du meinst das Update auf Kernel 5.3.18-150300.59.81-default.
Bei mir hat sich nach dem Kernelupdate (*) das komplette Betriebssystem aufgehängt. Uhr bleibt stehen, <Strg>+<Alt>+<F1> funktioniert nicht. Beim nächsten Versuch ist das bereits während des Startvorgangs vor dem Erscheinen des (grafischen) Login-Screens passiert.
Mit dem vorherigen Kernel 5.3.18-150300.59.76-default funktioniert jedoch alles.
Liegt anscheinend am Kernel.
Viele Grüße, Klaus
(*) Dabei gab es folgende Updates:
- 2022-07-19 16:01:49|install|kernel-default|5.3.18-150300.59.81.1|x86_64||repo-sle-upd at e|c2055d0d7767a073780c76efdf1b1f81e43ab8 2b4bff7cc238b49a0a4db8e56f| - 2022-07-19 16:01:55|install|kernel-default-extra|5.3.18-150300.59.81.1|x86_64||repo-s le -update|8f1ef015d56b7c2ea469b4e8a7640450 3ec8586fb7c1d480acbeb20025a4129c| - 2022-07-19 16:02:00|install|kernel-default-optional|5.3.18-150300.59.81.1|x86_64||rep o- sle-update|5f791a74f07d9238cbececd479607 81a73a64ac06f01636707c912326bad518b|
Hallo Klaus,
nicht nur beim default Kernel auch beim preempt war es etwas nervenaufreibend. Nach dem update war ein reboot angefordert. Der Rechner hat ständig auf die Platte zugegriffen und mehrmals versucht zu booten. Erst nachdem Ruhe auf der Platte war habe ich ihn aus- und wieder eingeschalten, dann hat er richtig gebootet, auch wieder mit Display.
Gruß Herbert zu früh gefreut. Mit dem neuen Kernel friert das System (OS 15.3 / KDE) nach kürzester Zeit ein. Mit dem Kernel 5.3.18-150300.59.76-preempt ist die Welt in Ordnung. Kann nur hoffen, dass bald ein bereinigtes Update folgt.
Am 19.07.22 um 16:06 schrieb Robert Großkopf: (...)
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert. (...) Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den eventuellen Fehler bei meinem System suchen? Nein, das ist bei einem von mir betreuten Rechner ebenso. Der 81-er Kernel ist irgendwie zu innovativ ;-)
Es war gestern schon spät, daher habe ich nat. keine Logs mitgebracht ~:-[ Die kann ich nun erst in ein paar Tagen nachliefern. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am Mittwoch, 20. Juli 2022, 07:17:57 CEST schrieb Bernd Nachtigall:
Am 19.07.22 um 16:06 schrieb Robert Großkopf: (...)
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen
Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es
immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert.
(...)
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den
eventuellen Fehler bei meinem System suchen?
Nein, das ist bei einem von mir betreuten Rechner ebenso. Der 81-er Kernel ist irgendwie zu innovativ ;-)
Es war gestern schon spät, daher habe ich nat. keine Logs mitgebracht ~:-[ Die kann ich nun erst in ein paar Tagen nachliefern.
Bernd
-- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren. wie wird man denn den innovativen Kernel wieder los? Ein zypper se -si kernel zeigt mir, dass er irgendwie zurückgeholt wurde (iR)
i+ | kernel-preempt | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) Unter Yast wird der 81er unter Zurückgeholte installierte Pakete aufgeführt. Doch wie werde ich ihn los, so dass in grup alles stimmt?
On Wed, Jul 20, 2022 at 03:17:45PM +0200, Herbert Albert wrote:
Am Mittwoch, 20. Juli 2022, 07:17:57 CEST schrieb Bernd Nachtigall:
Am 19.07.22 um 16:06 schrieb Robert Großkopf: (...)
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen
Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es
immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert.
(...)
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den
eventuellen Fehler bei meinem System suchen?
Nein, das ist bei einem von mir betreuten Rechner ebenso. Der 81-er Kernel ist irgendwie zu innovativ ;-)
Es war gestern schon spät, daher habe ich nat. keine Logs mitgebracht ~:-[ Die kann ich nun erst in ein paar Tagen nachliefern.
Bernd
-- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren. wie wird man denn den innovativen Kernel wieder los? Ein zypper se -si kernel zeigt mir, dass er irgendwie zurückgeholt wurde (iR)
i+ | kernel-preempt | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE)
Unter Yast wird der 81er unter Zurückgeholte installierte Pakete aufgeführt.
Doch wie werde ich ihn los, so dass in grup alles stimmt?
einfachster weg: zypper rm kernel-preempt-5.3.18-150300.59.81.1 Ciao, Marcus
Am Mittwoch, 20. Juli 2022, 15:23:04 CEST schrieb Marcus Meissner:
On Wed, Jul 20, 2022 at 03:17:45PM +0200, Herbert Albert wrote:
Am Mittwoch, 20. Juli 2022, 07:17:57 CEST schrieb Bernd Nachtigall:
Am 19.07.22 um 16:06 schrieb Robert Großkopf: (...)
gestern habe ich nach einem Kernelupdate Probleme mit der grafischen
Oberfläche (intel-Grafik onboard). Nach kurzer Zeit passiert es
immer wieder, dass Fenster nicht mehr bedienbar sind, teilweise auch die ganze Oberfläche einfriert.
(...)
Starte ich den vorherigen Kernel, dann kann ich weiter ordentlich arbeiten.
Hat hier irgendjemand ähnliche Erfahrungen gemacht oder muss ich den
eventuellen Fehler bei meinem System suchen?
Nein, das ist bei einem von mir betreuten Rechner ebenso. Der 81-er Kernel ist irgendwie zu innovativ ;-)
Es war gestern schon spät, daher habe ich nat. keine Logs mitgebracht ~:-[ Die kann ich nun erst in ein paar Tagen nachliefern.
Bernd
-- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
wie wird man denn den innovativen Kernel wieder los? Ein zypper se -si kernel zeigt mir, dass er irgendwie zurückgeholt wurde (iR)
i+ | kernel-preempt | package | 5.3.18-150300.59.76.1 | x86_64> | Online updates for openSUSE Leap 15.3 (SLE)
iR | kernel-preempt | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE)
Unter Yast wird der 81er unter Zurückgeholte installierte Pakete aufgeführt.
Doch wie werde ich ihn los, so dass in grup alles stimmt?
einfachster weg:
zypper rm kernel-preempt-5.3.18-150300.59.81.1
Ciao, Marcus Hallo Marcus,
es sind ja mehrere Pakete mit der Kernelnummer installiert. Geht das auch mit wildcarts? Installiert sind: :~ # zypper se -si kernel | grep 5.3.18-150300.59.81.1 iR | kernel-default | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-default-devel | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-default-extra | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-default-optional | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-devel | package | 5.3.18-150300.59.81.1 | noarch | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt-devel | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt-extra | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) iR | kernel-preempt-optional | package | 5.3.18-150300.59.81.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) Übrigbleiben müsste dann: :~ # zypper se -si kernel | grep 5.3.18-150300.59.76.1 i+ | kernel-default | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-default-devel | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-default-extra | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-default-optional | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-devel | package | 5.3.18-150300.59.76.1 | noarch | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-macros | package | 5.3.18-150300.59.76.1 | noarch | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-preempt | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-preempt-devel | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-preempt-extra | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) i+ | kernel-preempt-optional | package | 5.3.18-150300.59.76.1 | x86_64 | Online updates for openSUSE Leap 15.3 (SLE) Wird der 76.1 dann auch beim nächsten booten automatisch von grup genommen? Gruß Herbert
Hallo Herbert, ich habe jetzt Yast aufgerufen und die 3 vorgeschlagenen Kernel-Pakete zum 5.3.18-150300.59.81-default deinstalliert. Kamen in Yast ein paar Nachfragen, ging aber schließlich. Dafür habe ich jetzt den Kernel mit der "76" sowohl al -default als auch als -preempt in Grub auf. Gruß Robert -- Homepage: https://www.familiegrosskopf.de/robert
Hallo Herbert, Am 20.07.22 um 15:35 schrieb Herbert Albert:
zypper rm kernel-preempt-5.3.18-150300.59.81.1
Dieser Befehl zeigt dir die Pakete an, die er löschen würde, und fragt, ob er sie wirklich löschen soll. Wenn du das bestätigst, sorgt er auch dafür, dass grub dir die übrig gebliebenen Kernels anbietet. Du kannst auch in /boot nachsehen, welche Bootimages da sind: $ ls /boot/ | cat boot.readme config-5.3.18-150300.59.68-default config-5.3.18-150300.59.71-default efi grub2 initrd initrd-5.3.18-150300.59.68-default initrd-5.3.18-150300.59.71-default lost+found symvers-5.3.18-150300.59.68-default.gz symvers-5.3.18-150300.59.71-default.gz sysctl.conf-5.3.18-150300.59.68-default sysctl.conf-5.3.18-150300.59.71-default System.map-5.3.18-150300.59.68-default System.map-5.3.18-150300.59.71-default vmlinux-5.3.18-150300.59.68-default.gz vmlinux-5.3.18-150300.59.71-default.gz vmlinuz vmlinuz-5.3.18-150300.59.68-default vmlinuz-5.3.18-150300.59.71-default Und notfalls mit zypper weitere installieren. -- Viele Grüße Michael
Am Mittwoch, 20. Juli 2022, 16:40:54 CEST schrieb Michael Behrens:
Hallo Herbert,
Am 20.07.22 um 15:35 schrieb Herbert Albert:
zypper rm kernel-preempt-5.3.18-150300.59.81.1
Dieser Befehl zeigt dir die Pakete an, die er löschen würde, und fragt, ob er sie wirklich löschen soll. Wenn du das bestätigst, sorgt er auch dafür, dass grub dir die übrig gebliebenen Kernels anbietet. Du kannst auch in /boot nachsehen, welche Bootimages da sind:
$ ls /boot/ | cat boot.readme config-5.3.18-150300.59.68-default config-5.3.18-150300.59.71-default efi grub2 initrd initrd-5.3.18-150300.59.68-default initrd-5.3.18-150300.59.71-default lost+found symvers-5.3.18-150300.59.68-default.gz symvers-5.3.18-150300.59.71-default.gz sysctl.conf-5.3.18-150300.59.68-default sysctl.conf-5.3.18-150300.59.71-default System.map-5.3.18-150300.59.68-default System.map-5.3.18-150300.59.71-default vmlinux-5.3.18-150300.59.68-default.gzZurückgeholte installierte Pakete vmlinux-5.3.18-150300.59.71-default.gz vmlinuz vmlinuz-5.3.18-150300.59.68-default vmlinuz-5.3.18-150300.59.71-default
Und notfalls mit zypper weitere installieren.
--
Viele Grüße
Michael
Hallo, habe jetzt per zypper auch alle 81.1er gelöscht und das System bootet wieder mit dem 76.1er Kernel. Was hat es mit den "iR" markierten Paketen in zypper bzw. in Yast mit "Zurückgeholte installierte Pakete" auf sich? Werden die nun vom System durch einen Befehl wie z.B. zypper up wieder deinstalliert? Offensichtlich nicht, sind wohl nur markiert und der Anwender muss sich selbst kümmern. So recht habe ich das nicht durchschaut. Kann mir der "innovative Kernel" beim nächsten Update wieder aufs System gelangen? Gruß Herbert
On Wed, Jul 20, 2022 at 04:54:51PM +0200, Herbert Albert wrote:
Am Mittwoch, 20. Juli 2022, 16:40:54 CEST schrieb Michael Behrens:
Hallo Herbert,
Am 20.07.22 um 15:35 schrieb Herbert Albert:
zypper rm kernel-preempt-5.3.18-150300.59.81.1
Dieser Befehl zeigt dir die Pakete an, die er löschen würde, und fragt, ob er sie wirklich löschen soll. Wenn du das bestätigst, sorgt er auch dafür, dass grub dir die übrig gebliebenen Kernels anbietet. Du kannst auch in /boot nachsehen, welche Bootimages da sind:
$ ls /boot/ | cat boot.readme config-5.3.18-150300.59.68-default config-5.3.18-150300.59.71-default efi grub2 initrd initrd-5.3.18-150300.59.68-default initrd-5.3.18-150300.59.71-default lost+found symvers-5.3.18-150300.59.68-default.gz symvers-5.3.18-150300.59.71-default.gz sysctl.conf-5.3.18-150300.59.68-default sysctl.conf-5.3.18-150300.59.71-default System.map-5.3.18-150300.59.68-default System.map-5.3.18-150300.59.71-default vmlinux-5.3.18-150300.59.68-default.gzZurückgeholte installierte Pakete vmlinux-5.3.18-150300.59.71-default.gz vmlinuz vmlinuz-5.3.18-150300.59.68-default vmlinuz-5.3.18-150300.59.71-default
Und notfalls mit zypper weitere installieren.
--
Viele Grüße
Michael
Hallo,
habe jetzt per zypper auch alle 81.1er gelöscht und das System bootet wieder mit dem 76.1er Kernel.
Was hat es mit den "iR" markierten Paketen in zypper bzw. in Yast mit "Zurückgeholte installierte Pakete" auf sich? Werden die nun vom System durch einen Befehl wie z.B. zypper up wieder deinstalliert? Offensichtlich nicht, sind wohl nur markiert und der Anwender muss sich selbst kümmern. So recht habe ich das nicht durchschaut.
Kann mir der "innovative Kernel" beim nächsten Update wieder aufs System gelangen?
Das "r" flag ist retracted. zypper patch und zypper up sollten die nicht mehr installieren da sie dieses Flag sehen, sondern erst denn naechsten gefixten Kernel. Ciao, Marcus
Am Mittwoch, 20. Juli 2022, 16:57:28 CEST schrieb Marcus Meissner:
On Wed, Jul 20, 2022 at 04:54:51PM +0200, Herbert Albert wrote:
Am Mittwoch, 20. Juli 2022, 16:40:54 CEST schrieb Michael Behrens:
Hallo Herbert,
Am 20.07.22 um 15:35 schrieb Herbert Albert:
zypper rm kernel-preempt-5.3.18-150300.59.81.1
Dieser Befehl zeigt dir die Pakete an, die er löschen würde, und fragt, ob er sie wirklich löschen soll.
Wenn du das bestätigst, sorgt er auch dafür,
dass grub dir die übrig gebliebenen Kernels anbietet. Du kannst auch in /boot nachsehen, welche Bootimages da sind:
$ ls /boot/ | cat boot.readme config-5.3.18-150300.59.68-default config-5.3.18-150300.59.71-default efi grub2 initrd initrd-5.3.18-150300.59.68-default initrd-5.3.18-150300.59.71-default lost+found symvers-5.3.18-150300.59.68-default.gz symvers-5.3.18-150300.59.71-default.gz sysctl.conf-5.3.18-150300.59.68-default sysctl.conf-5.3.18-150300.59.71-default System.map-5.3.18-150300.59.68-default System.map-5.3.18-150300.59.71-default vmlinux-5.3.18-150300.59.68-default.gzZurückgeholte installierte Pakete vmlinux-5.3.18-150300.59.71-default.gz vmlinuz vmlinuz-5.3.18-150300.59.68-default vmlinuz-5.3.18-150300.59.71-default
Und notfalls mit zypper weitere installieren.
Hallo,
habe jetzt per zypper auch alle 81.1er gelöscht und das System bootet wieder mit dem 76.1er Kernel.
Was hat es mit den "iR" markierten Paketen in zypper bzw. in Yast mit "Zurückgeholte installierte Pakete" auf sich? Werden die nun vom System durch einen Befehl wie z.B. zypper up wieder deinstalliert? Offensichtlich nicht, sind wohl nur markiert und der Anwender muss sich selbst kümmern. So recht habe ich das nicht durchschaut.
Kann mir der "innovative Kernel" beim nächsten Update wieder aufs System gelangen?
Das "r" flag ist retracted.
zypper patch und zypper up sollten die nicht mehr installieren da sie dieses Flag sehen, sondern erst denn naechsten gefixten Kernel.
Ciao, Marcus Halo Marcus,
genial. Nur das deinstallieren bleibt beim user. Gruß Herbert
Am Mittwoch, 20. Juli 2022, 17:08:40 CEST schrieb Michael Behrens:
Am 20.07.22 um 16:54 schrieb Herbert Albert:
... Kann mir der "innovative Kernel" beim nächsten Update wieder aufs System gelangen? ...
Du kannst mit
zypper lu 2>&1 | egrep '(kernel-|^S)'
vorher nachsehen, was angeboten wird.
--
Viele Grüße
Michael
Hallo Michael, danke. Die Fülle der Konsolen-Befehle ist halt unerschöpflich. Gruß Herbert
participants (7)
-
Bernd Nachtigall -
funedv＠gmx.de -
Herbert Albert -
Jens Schleusener -
Marcus Meissner -
Michael Behrens -
Robert Großkopf