openSUSE-15.3,Problemkernel mit merkwürdiger Bezeichnung

[Bernd Mayer]

Hallo,

auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.

Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.

Weiß hier jemand was da los ist?


Bernd Mayer

[Andrew]

Post by Bernd Mayer
Hallo,
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.
Weiß  hier jemand was da los ist?
Bernd Mayer

Ich habe spät gestern Abend ein Kernel auf einem alten Laptop
eingespielt, nach dem - warmen - Reboot gab es eine Fehlermeldung, /
(also, root Partition) könnte nicht eingebunden werden.
Trotzdem hat alles wie immer funktioniert.

[Martin Schnitkemper]

Post by Bernd Mayer
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.

Wahrscheinlich ein außerplanmäßiges Update wegen CVE-2022-0185

Post by Bernd Mayer
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.

Bekanntes Problem: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142

Scheint nur Systeme mit Radeon-Grafikkarten zu betreffen.

[Andrew]

Post by Martin Schnitkemper

Post by Bernd Mayer
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.

Wahrscheinlich ein außerplanmäßiges Update wegen CVE-2022-0185

Post by Bernd Mayer
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.

Bekanntes Problem: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142
Scheint nur Systeme mit Radeon-Grafikkarten zu betreffen.

Mein Radeon R7 System hat das Problem nicht, 5.3.18-150300.59.43-default
läuft problemlos.
Mein Radeon Vega 8 System habe ich gar nicht erst hochgefahren, ich
glaube der alte Kernel (.59.40) ist dort installiert.

Im Bug 1195142 habe ich nicht erkennen können, welche Radeons betroffen
sind.

[Bernd Mayer]

Post by Martin Schnitkemper

Post by Bernd Mayer
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.

Wahrscheinlich ein außerplanmäßiges Update wegen CVE-2022-0185

Post by Bernd Mayer
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.

Bekanntes Problem: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142
Scheint nur Systeme mit Radeon-Grafikkarten zu betreffen.

Hallo,

Danke für die Info.

Zwei betroffene PCs haben ältere AMD-Prozessoren (Sockel AM3) mit
integrierter Grafik. Grafikkarte ist keine drin.

Auch nach längerem zuwarten (ca. 5 Min.) kann ich die PCs nicht anpingen
und Zugang über ssh ist auch nicht möglich.

Das sind beides System die ich headless betreibe und über ssh warte, die
Fehlersuche ist dadurch natürlich aufwendiger.

Ich überlege, ob wichtige Kernelmodule fehlen und die initrd nicht
vollständig ist.

Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.

Bei der Installation kam auch eine Meldung ein restart sei notwendig.
Mir war aber nicht klar ob sofortiger Restart gemeint war oder ein
restart nach Abschluß der Kernelinstallation. Ich hatte zugewartet und
nach dem reboot war zypper automatisch aktiv und hat die vorigen
überflüssigen Kernel gelöscht.

Ich muss mal schauen ob ich in den log-Dateien was finde.


Bernd Mayer

[Andrew]

Post by Bernd Mayer

Post by Martin Schnitkemper

Post by Bernd Mayer
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.

Wahrscheinlich ein außerplanmäßiges Update wegen CVE-2022-0185

Post by Bernd Mayer
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.

Bekanntes Problem: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142
Scheint nur Systeme mit Radeon-Grafikkarten zu betreffen.

Hallo,
Danke für die Info.
Zwei betroffene PCs haben ältere AMD-Prozessoren (Sockel AM3) mit
integrierter Grafik. Grafikkarte ist keine drin.
Auch nach längerem zuwarten (ca. 5 Min.) kann ich die PCs nicht anpingen
und Zugang über ssh ist auch nicht möglich.
Das sind beides System die ich headless betreibe und über ssh warte, die
Fehlersuche ist dadurch natürlich aufwendiger.
Ich überlege, ob wichtige Kernelmodule fehlen und die initrd nicht
vollständig ist.
Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.
Bei der Installation kam auch eine Meldung ein restart sei notwendig.
Mir war aber nicht klar ob sofortiger Restart gemeint war oder ein
restart nach Abschluß der Kernelinstallation. Ich hatte zugewartet und
nach dem reboot war zypper automatisch aktiv und hat die vorigen
überflüssigen Kernel gelöscht.
Ich muss mal schauen ob ich in den log-Dateien was finde.
Bernd Mayer

Möglichkeit 1: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c9
("nomodeset" ausprobieren), später wieder aufheben

Möglichkeit 2: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c1

Möglichkeit 3: YaST -> Software Management und dann "Kernel" in
"Protected - Do Not Modify" setzen. Später wieder aufheben.

[Bernd Mayer]

[Problemkernel von openSUSE-15.3]

Post by Andrew

Post by Bernd Mayer
Ich überlege, ob wichtige Kernelmodule fehlen und die initrd nicht
vollständig ist.
Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.
Bei der Installation kam auch eine Meldung ein restart sei notwendig.
Mir war aber nicht klar ob sofortiger Restart gemeint war oder ein
restart nach Abschluß der Kernelinstallation. Ich hatte zugewartet und
nach dem reboot war zypper automatisch aktiv und hat die vorigen
überflüssigen Kernel gelöscht.

Möglichkeit 1: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c9
("nomodeset" ausprobieren), später wieder aufheben
Möglichkeit 2: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c1
Möglichkeit 3: YaST -> Software Management und dann "Kernel" in
"Protected - Do Not Modify" setzen.  Später wieder aufheben.

Hallo,

danke auch an Dich.

Das kannte ich mangels Bedarf noch nicht, daß man den Kernel auf
protected setzen kann.

nomodeset ist wohl ein Parameter für grub.

Wenn die Lösung mit dem Austausch der radeon-Module nicht funktioniert
hätte, dann hätte ich in grub das automatische Booten des älteren
funktionierenden Kernels eingetragen.

Ein zweiter PC wurde mittlerweile auch wieder zum Laufen gebracht.

Bei einem Dritten der zusätzlich zur integrierten Grafik der AMD3+-CPU
eine Grafikkarte Radeon HD6950 eingebaut hat gab es überaschenderweise
keine Probleme. Lsmod zeigt ein geladenes radeon-Modul an. Ich muss noch
nachschauen mit welchem Treiber die Grafikkarte läuft.


Bernd Mayer

[Martin Schnitkemper]

Post by Bernd Mayer
Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.

Nachdem der Bugreport mit dem Status "RESOLVED FIXED" geschlossen wurde
ging ich davon aus, dass das Problem mit der Verteilung eines korrigierten
Pakets behoben wurde.

Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

Das scheint auch zu funktionieren, wie man den Bestätigungen der
nachfolgenden Kommentare entnehmen kann.

[Bernd Mayer]

Post by Martin Schnitkemper

Post by Bernd Mayer
Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.

Nachdem der Bugreport mit dem Status "RESOLVED FIXED" geschlossen wurde
ging ich davon aus, dass das Problem mit der Verteilung eines korrigierten
Pakets behoben wurde.
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.
Das scheint auch zu funktionieren, wie man den Bestätigungen der
nachfolgenden Kommentare entnehmen kann.

Hallo,

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und mkinitrd
laufen lassen.

Insgesamt waren da zahlreiche reboots und Tests notwendig. Das ist schon
eine ungewöhnliche Art ein CVE zu beheben wenn das System dann erstmal
überhaupt nicht bootet und man dann geneigt ist den alten Kernel weiter
zu verwenden.

Danke


Bernd Mayer

[JJenssen]

Post by Bernd Mayer

Post by Martin Schnitkemper

Post by Bernd Mayer
Ich habe schon versucht diesen Kernel über rpm zu deinstallieren. Beim
nächsten update kommen die aber wieder.

Nachdem der Bugreport mit dem Status "RESOLVED FIXED" geschlossen wurde
ging ich davon aus, dass das Problem mit der Verteilung eines
korrigierten
Pakets behoben wurde.
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.
Das scheint auch zu funktionieren, wie man den Bestätigungen der
nachfolgenden Kommentare entnehmen kann.

Hallo,
ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und mkinitrd
laufen lassen.
Insgesamt waren da zahlreiche reboots und Tests notwendig. Das ist schon
eine ungewöhnliche Art ein CVE zu beheben wenn das System dann erstmal
überhaupt nicht bootet und man dann geneigt ist den alten Kernel weiter
zu verwenden.
Danke
Bernd Mayer

Moin,
hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Was mir nicht klar ist bei dem von euch beschriebenen Vorgehen, ist:
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm stehen,
ich komme nicht auf die Wartungskonsole (init 1) und ssh ist auch nicht
moeglich. Wie komme ich also nach dem Update an das auszutauschende
Kernelmodul?
Ich habe:
1. Eine Sicherungskopie des /-Path vor dem Update v. 15.12.2021,
2. Eine parallele aktuelle Debian-Installation,
3. Keine Ahnung von Kerneln und den Startablaeufen (mkinitrd etc.).

Ich waere euch sehr dankbar fuer eine moeglichst genaue Beschreibung
eures Vorgehens, wie ihr das geloest habt.

___

Regards
JJenssen

[Bernd Mayer]

Post by JJenssen

Post by Bernd Mayer

Post by Martin Schnitkemper
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und mkinitrd
laufen lassen.

hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm stehen,
ich komme nicht auf die Wartungskonsole (init 1) und ssh ist auch nicht
moeglich.  Wie komme ich also nach dem Update an das auszutauschende
Kernelmodul?
Ich waere euch sehr dankbar fuer eine moeglichst genaue Beschreibung
eures Vorgehens, wie  ihr das geloest habt.

Hallo,

bei den Standardeinstellungen von openSUSE bleibt der alte Kernel und
der neue Kernel erhalten und über das grub-menü kann man
den vorigen Kernel booten. Dadurch hatte ich Zugang zu den Dateien des
alten und des neuen Kernels.

Ich hatte als root die Datei:

/lib/modules/alter-kernel/drivers/gpu/drm/radeon/radeon.ko.xz
in das entsprechende Verzeichnis des neuen Kernels kopiert und dessen
Version ersetzt.

Danach habe ich mkinitrd aufgerufen damit die initrds neu erstellt werden.


Bernd Mayer

[JJenssen]

Post by Bernd Mayer

Post by JJenssen

Post by Bernd Mayer

Post by Martin Schnitkemper
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und mkinitrd
laufen lassen.

hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm
stehen, ich komme nicht auf die Wartungskonsole (init 1) und ssh ist
auch nicht moeglich.  Wie komme ich also nach dem Update an das
auszutauschende Kernelmodul?
Ich waere euch sehr dankbar fuer eine moeglichst genaue Beschreibung
eures Vorgehens, wie  ihr das geloest habt.

Hallo,
bei den Standardeinstellungen von openSUSE bleibt der alte Kernel und
der neue Kernel erhalten und über das grub-menü kann man
den vorigen Kernel booten. Dadurch hatte ich Zugang zu den Dateien des
alten und des neuen Kernels.
/lib/modules/alter-kernel/drivers/gpu/drm/radeon/radeon.ko.xz
in das entsprechende Verzeichnis des neuen Kernels kopiert und dessen
Version ersetzt.
Danach habe ich mkinitrd aufgerufen damit die initrds neu erstellt werden.
Bernd Mayer

Danke fuer die schnelle Antwort. Kann mich leider dieses WE nicht damit
beschaeftigen. Ich melde mich mit den Fortschritten.

___

Regards
JJenssen

[JJenssen]

Post by Bernd Mayer

Post by JJenssen

Post by Bernd Mayer

Post by Martin Schnitkemper
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und
mkinitrd laufen lassen.

hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm
stehen, ich komme nicht auf die Wartungskonsole (init 1) und ssh ist
auch nicht moeglich.  Wie komme ich also nach dem Update an das
auszutauschende Kernelmodul?
Ich waere euch sehr dankbar fuer eine moeglichst genaue Beschreibung
eures Vorgehens, wie  ihr das geloest habt.

Hallo,
bei den Standardeinstellungen von openSUSE bleibt der alte Kernel und
der neue Kernel erhalten und über das grub-menü kann man
den vorigen Kernel booten. Dadurch hatte ich Zugang zu den Dateien des
alten und des neuen Kernels.
/lib/modules/alter-kernel/drivers/gpu/drm/radeon/radeon.ko.xz
in das entsprechende Verzeichnis des neuen Kernels kopiert und dessen
Version ersetzt.
Danach habe ich mkinitrd aufgerufen damit die initrds neu erstellt werden.
Bernd Mayer

Danke fuer die schnelle Antwort.  Kann mich leider dieses WE nicht damit
beschaeftigen. Ich melde mich mit den Fortschritten.
___
Regards
  JJenssen

Nochmals Dank fuer die Antwort. Bei mir liegen die Treiber in anderen
Verzeichnissen. Der Austausch der Treiber hat aber den Fehler behoben.
Nun hoffe ich, dass das naechste Update nicht denselben Fehler erzeugt.

___

Regards
JJenssen

[Andrew]

Post by Bernd Mayer

Post by JJenssen

Post by Bernd Mayer

Post by Martin Schnitkemper
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und
mkinitrd laufen lassen.

hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm
stehen, ich komme nicht auf die Wartungskonsole (init 1) und ssh ist
auch nicht moeglich.  Wie komme ich also nach dem Update an das
auszutauschende Kernelmodul?
Ich waere euch sehr dankbar fuer eine moeglichst genaue Beschreibung
eures Vorgehens, wie  ihr das geloest habt.

Hallo,
bei den Standardeinstellungen von openSUSE bleibt der alte Kernel und
der neue Kernel erhalten und über das grub-menü kann man
den vorigen Kernel booten. Dadurch hatte ich Zugang zu den Dateien
des alten und des neuen Kernels.
/lib/modules/alter-kernel/drivers/gpu/drm/radeon/radeon.ko.xz
in das entsprechende Verzeichnis des neuen Kernels kopiert und dessen
Version ersetzt.
Danach habe ich mkinitrd aufgerufen damit die initrds neu erstellt werden.
Bernd Mayer

Danke fuer die schnelle Antwort.  Kann mich leider dieses WE nicht
damit beschaeftigen. Ich melde mich mit den Fortschritten.
___
Regards
   JJenssen

Nochmals Dank fuer die Antwort.  Bei mir liegen die Treiber in anderen
Verzeichnissen.  Der Austausch der Treiber hat aber den Fehler behoben.
 Nun hoffe ich, dass das naechste Update nicht denselben Fehler erzeugt.
___
Regards
   JJenssen

Darf nicht passieren, der Fehler ist bereits identifiziert und behoben
worden. Leider dauert es noch etwa 10 Tage bis zum nächsten Leap Kernel.

[JJenssen]

Post by Andrew

Post by Bernd Mayer

Post by JJenssen

Post by Bernd Mayer

Post by Martin Schnitkemper
Statt dessen scheint die Lösung darin zu liegen, dass der Benutzer das
Kernel-Modul mit dem eines früheren Kernels manuell austauscht, so wie es
im Kommentar
https://bugzilla.opensuse.org/show_bug.cgi?id=1195142#c5
beschrieben wurde.

ja auf dem ersten PC habe ich das mittlerweile zum Laufen gebracht.
Ich hatte das alte Kernelmodul von radeon hinüberkopiert und
mkinitrd laufen lassen.

hier ist das gleiche mit einer alten Radeon-GraKa. und dem letzten
Update von openSuse 15.3.
Wenn das Update eingespielt ist, bleibt der PC _ohne_ Bildschirm
stehen, ich komme nicht auf die Wartungskonsole (init 1) und ssh
ist auch nicht moeglich.  Wie komme ich also nach dem Update an das
auszutauschende Kernelmodul?
Ich waere euch sehr dankbar fuer eine moeglichst genaue
Beschreibung eures Vorgehens, wie  ihr das geloest habt.

Hallo,
bei den Standardeinstellungen von openSUSE bleibt der alte Kernel
und der neue Kernel erhalten und über das grub-menü kann man
den vorigen Kernel booten. Dadurch hatte ich Zugang zu den Dateien
des alten und des neuen Kernels.
/lib/modules/alter-kernel/drivers/gpu/drm/radeon/radeon.ko.xz
in das entsprechende Verzeichnis des neuen Kernels kopiert und
dessen Version ersetzt.
Danach habe ich mkinitrd aufgerufen damit die initrds neu erstellt werden.
Bernd Mayer

Danke fuer die schnelle Antwort.  Kann mich leider dieses WE nicht
damit beschaeftigen. Ich melde mich mit den Fortschritten.
___
Regards
   JJenssen

Nochmals Dank fuer die Antwort.  Bei mir liegen die Treiber in anderen
Verzeichnissen.  Der Austausch der Treiber hat aber den Fehler
behoben.   Nun hoffe ich, dass das naechste Update nicht denselben
Fehler erzeugt.
___
Regards
    JJenssen

Darf nicht passieren, der Fehler ist bereits identifiziert und behoben
worden.  Leider dauert es noch etwa 10 Tage bis zum nächsten Leap Kernel.

Danke fuer die Info, Andrew

___

Regards
JJenssen

[Bernd Mayer]

Nochmals Dank fuer die Antwort.  Bei mir liegen die Treiber in anderen
Verzeichnissen.  Der Austausch der Treiber hat aber den Fehler behoben.

Hallo,

ich hatte "alter-kernel" als Platzhalter im Pfad für die genaue
Bezeichnung gewählt. Das Abtippen mit der exakten Bezeichnung war mir zu
mühsam und fehlerträchtig.

Liegen die Kernelmodule bei Dir ganz woanders?


Bernd Mayer

[JJenssen]

Post by Bernd Mayer

Nochmals Dank fuer die Antwort.  Bei mir liegen die Treiber in anderen
Verzeichnissen.  Der Austausch der Treiber hat aber den Fehler behoben.

Hallo,
ich hatte "alter-kernel" als Platzhalter im Pfad für die genaue
Bezeichnung gewählt. Das Abtippen mit der exakten Bezeichnung war mir zu
mühsam und fehlerträchtig.
Liegen die Kernelmodule bei Dir ganz woanders?
Bernd Mayer

Ich abe sowohl in
/lib/modules/5.3.18-150300.59.43-default/kernel/drivers/gpu/drm/amd/amdgpu/
die amdgpu.ko.xz gegen die in
/lib/modules/5.3.18-59.24-default/kernel/drivers/gpu/drm/amd/amdgpu/
ausgetauscht,
als auch in
/lib/modules/5.3.18-150300.59.43-preempt/kernel/drivers/gpu/drm/amd/amdgpu/
gegen die in
/lib/modules/5.3.18-59.24-preempt/kernel/drivers/gpu/drm/amd/amdgpu/
dann noch den Treiber radeon.ko.xz in
/lib/modules/5.3.18-150300.59.43-preempt/kernel/drivers/gpu/drm/radeon/
gegen den in
/lib/modules/5.3.18-59.24-preempt/kernel/drivers/gpu/drm/radeon/
wobei die 5.3.18-59.24-* - Kernel die des alten Kernels sind. Ob das
alles noetig war weiss ich nicht, aber jetzt funktioniert es wieder.
Wie Andrew schrieb, soll das Thema aber in ca. 10 Tagen erledigt sein.
Es war fuer mich aber auf jeden Fall lehrreich;)
Trotzdem habe ich in den Pfaden die "alten" Treiber noch als z.B.
amdgpu.ko.xz.good bzw. radeon.ko.xz.good als Kopie hinterlegt, damit ich
danach nicht lange suchen muss, in der Hoffnung dass diese bei einem
Update nicht ueberschrieben werden.

___

Regards
JJenssen

[Martin Schnitkemper]

Post by JJenssen
ich komme nicht auf die Wartungskonsole (init 1) und ssh ist auch nicht
moeglich. Wie komme ich also nach dem Update an das auszutauschende

Du kannst doch den runlevel beim Startvorgang an den Kernel übergeben, also
im Bootmanager die Kommandozeile editieren und eine '1' anhängen, oder
gleich 'init="/bin/bash"' um direkt auf die Konsole zu kommen (jeweils ohne
die '-Anführungzeichen).

Post by JJenssen
3. Keine Ahnung von Kerneln und den Startablaeufen (mkinitrd etc.).

Das ist generell schlecht. Es empfiehlt sich, eine zusätzliche Bootoption
einzurichten, die nur einen Start bis zur Konsole vorsieht, um besser auf
eine solche Situation vorbereitet zu sein.

[Alexander Goetzenstein]

Hallo,

Post by Martin Schnitkemper
Du kannst doch den runlevel beim Startvorgang an den Kernel übergeben, also
im Bootmanager die Kommandozeile editieren und eine '1' anhängen, oder
gleich 'init="/bin/bash"' um direkt auf die Konsole zu kommen (jeweils ohne
die '-Anführungzeichen).

Du meinst, im Bootmenu die default-Option zu belassen und E zu drücken,
richtig? Da taucht dann ein editierbares "Fenster" auf mit dem Inhalt

Post by Martin Schnitkemper
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4 46AC-FC76
else
search --no-floppy --fs-uuid --set=root 46AC-FC76
fi
echo 'Loading Linux 5.14.14-1-default ...'
linuxefi /vmlinuz-5.14.14-1-default root=/dev/mapper/linux-root ${extra_cmdline} splash=silent resume=/dev/linux/swap quiet splash=silent resume=/dev/linux/swap quiet splash=silent resume=/dev/linux/swap quiet mitigations=auto
echo 'Loading initial ramdisk ...'
initrdefi /initrd-5.14.14-1-default

An welcher Stelle genau wäre die 1 bzw. init=/bin/bash anzuhängen oder
einzufügen? Bei meinen wild geratenen Versuchen hat es bislang nicht
funktioniert.

Post by Martin Schnitkemper

Post by JJenssen
3. Keine Ahnung von Kerneln und den Startablaeufen (mkinitrd etc.).

Das ist generell schlecht.

Hier gebe ich zu, dass ich mangels Gelegenheit auch keine Übung habe.

Post by Martin Schnitkemper
Es empfiehlt sich, eine zusätzliche Bootoption
einzurichten, die nur einen Start bis zur Konsole vorsieht, um besser auf
eine solche Situation vorbereitet zu sein.

Auch das habe ich mit yast schonmal nicht hinbekommen. Müsste dafür die
Datei /boot/grub2/grub.cfg editiert werden? Falls ja, was wäre dabei zu
beachten, und wie verhindert man, dass yast das bei nächster Gelegenheit
überschreibt?

[JJenssen]

Post by Bernd Mayer
Hallo,

Post by Martin Schnitkemper
Du kannst doch den runlevel beim Startvorgang an den Kernel übergeben, also
im Bootmanager die Kommandozeile editieren und eine '1' anhängen, oder
gleich 'init="/bin/bash"' um direkt auf die Konsole zu kommen (jeweils ohne
die '-Anführungzeichen).

Du meinst, im Bootmenu die default-Option zu belassen und E zu drücken,
richtig? Da taucht dann ein editierbares "Fenster" auf mit dem Inhalt

Post by Martin Schnitkemper
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4 46AC-FC76
else
search --no-floppy --fs-uuid --set=root 46AC-FC76
fi
echo 'Loading Linux 5.14.14-1-default ...'
linuxefi /vmlinuz-5.14.14-1-default root=/dev/mapper/linux-root ${extra_cmdline} splash=silent resume=/dev/linux/swap quiet

^^^^^^^^
splash=silent resume=/dev/linux/swap quiet splash=silent
resume=/dev/linux/swap quiet mitigations=auto 1

Post by Bernd Mayer

Post by Martin Schnitkemper
echo 'Loading initial ramdisk ...'
initrdefi /initrd-5.14.14-1-default

An welcher Stelle genau wäre die 1 bzw. init=/bin/bash anzuhängen oder
einzufügen? Bei meinen wild geratenen Versuchen hat es bislang nicht
funktioniert.

Post by Martin Schnitkemper

Post by JJenssen
3. Keine Ahnung von Kerneln und den Startablaeufen (mkinitrd etc.).

Das ist generell schlecht.

Hier gebe ich zu, dass ich mangels Gelegenheit auch keine Übung habe.

Post by Martin Schnitkemper
Es empfiehlt sich, eine zusätzliche Bootoption
einzurichten, die nur einen Start bis zur Konsole vorsieht, um besser auf
eine solche Situation vorbereitet zu sein.

Auch das habe ich mit yast schonmal nicht hinbekommen. Müsste dafür die
Datei /boot/grub2/grub.cfg editiert werden? Falls ja, was wäre dabei zu
beachten, und wie verhindert man, dass yast das bei nächster Gelegenheit
überschreibt?

Du setzt die 1 an das Ende der Zeile, die mit 'linuxefi' bzw. 'linux'
beginnt. Ich habe das oben markiert.
Um das als zusaetzliche Bootoption anzulegen reicht es meines Wissens
nicht die grub.cfg zu aendern. Ich habe das vor einiger Zeit mit GRUB2
versucht anzulegen, aber es hat micht ueberfordert. Es waren noch
schoene Zeiten mit 'lilo' oder dem alten GRUB.
Mit Yast habe ich es gar nicht erst versucht.
___

Regards
JJenssen

[Martin Schnitkemper]

Post by JJenssen
versucht anzulegen, aber es hat micht ueberfordert. Es waren noch
schoene Zeiten mit 'lilo' oder dem alten GRUB.

Aus dem gleichen Grund wechselte ich auch zu syslinux. Das entspricht von
der Konfiguration etwa dem, wie man es von grub-legacy kannte.

Wenn man nicht unbedingt eine der wenigen Spezialitäten benötigt, die nur
grub-2 bietet, erscheint mir syslinux als die bessere Wahl.

An die 'lilo'-Zeiten erinnere ich mich eher ungern zurück, da war
die Ablösung durch grub-legacy schon ein Segen.

[Martin Schnitkemper]

Post by Alexander Goetzenstein
An welcher Stelle genau wäre die 1 bzw. init=/bin/bash anzuhängen oder
einzufügen? Bei meinen wild geratenen Versuchen hat es bislang nicht
funktioniert.

Ich würde sagen die Zeile, die mit

| linuxefi /vmlinuz-5.14.14-1-default root=/dev/mapper/linux-root

beginnt.

Möglicherweise funktioniert es auch deshalb nicht, weil openSUSE
mittlerweile auch systemd verwendet und kein SysVinit mehr. Ich hatte das
nur so beschrieben, weil ausdrücklich nach "init 1" gefragt wurde.

Bei systemd wird das über targets gesteuert, z. B. mit
"systemd.unit=multi-user.target" in den Kernel-Parametern, was natürlich
allein schon wegen der fehlenden Lokalisierung der Tastatur zum Zeitpunkt
des Starts anspruchsvoller ist als die Eingabe von nur einer Ziffer. Schon
deswegen sollte man sich im Bootmanager so einen Eintrag vorbereiten.

Post by Alexander Goetzenstein
Auch das habe ich mit yast schonmal nicht hinbekommen.

Das ist auch eher etwas für die Kosole.

Post by Alexander Goetzenstein
Müsste dafür die
Datei /boot/grub2/grub.cfg editiert werden?

Nein, alle Änderungen müssen als dropfiles in /etc/grub.d/ vorgenommen
werden.

Post by Alexander Goetzenstein
Falls ja, was wäre dabei zu
beachten, und wie verhindert man, dass yast das bei nächster Gelegenheit
überschreibt?

yast eher nicht, aber grub-mkconfig.

Deswegen müssen eigene Menüeinträge in /etc/grub.d/40_custom vorgenommen
werden, grub-mkconfig baut dann daraus wieder eine /boot/grub/grub.cfg.
Angeblich soll man die Eintragungen auch direkt in eine
/boot/grub/custom.cfg vornehmen können, das habe ich aber nie versucht.

Mir wurde grub ab Version 2 mit seinen unzähligen Skripten zu kompliziert
und ist für mein Standardsystem ohne Besonderheiten auch oversized.
Deswegen bin ich schon vor Jahren auf syslinux als Bootmanager umgestiegen,
der wesentlich einfacher zu konfigurieren ist.

[Alexander Goetzenstein]

Hallo,
und Danke für den Input.

Post by Martin Schnitkemper
Deswegen müssen eigene Menüeinträge in /etc/grub.d/40_custom vorgenommen
werden, grub-mkconfig baut dann daraus wieder eine /boot/grub/grub.cfg.

Gefunden. Vermutlich kann man da einfach den Default-Eintrag aus der
Datei /boot/grub2/grub.cfg übernehmen und die 1 anhängen.

Der String 46AC-FC76 bezeichnet die UUID der Bootpartition (hier:
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?

Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Post by Martin Schnitkemper
Mir wurde grub ab Version 2 mit seinen unzähligen Skripten zu kompliziert
und ist für mein Standardsystem ohne Besonderheiten auch oversized.

Vielleicht findet sich ja noch jemand anderes, der es erklärend weiterführt?

[JJenssen]

Post by Bernd Mayer
Hallo,
und Danke für den Input.

Post by Martin Schnitkemper
Deswegen müssen eigene Menüeinträge in /etc/grub.d/40_custom vorgenommen
werden, grub-mkconfig baut dann daraus wieder eine /boot/grub/grub.cfg.

Gefunden. Vermutlich kann man da einfach den Default-Eintrag aus der
Datei /boot/grub2/grub.cfg übernehmen und die 1 anhängen.
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Post by Martin Schnitkemper
Mir wurde grub ab Version 2 mit seinen unzähligen Skripten zu kompliziert
und ist für mein Standardsystem ohne Besonderheiten auch oversized.

Vielleicht findet sich ja noch jemand anderes, der es erklärend weiterführt?

Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr gut,
vielleicht als neuen Thread. Ich bezweifle aber, dass sich jemand
dafuer findet:((

___

Regards
JJenssen

[Andrew]

Post by JJenssen

Post by Bernd Mayer
Hallo,
und Danke für den Input.

Post by Martin Schnitkemper
Deswegen müssen eigene Menüeinträge in /etc/grub.d/40_custom vorgenommen
werden, grub-mkconfig baut dann daraus wieder eine /boot/grub/grub.cfg.

Gefunden. Vermutlich kann man da einfach den Default-Eintrag aus der
Datei /boot/grub2/grub.cfg übernehmen und die 1 anhängen.
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Post by Martin Schnitkemper
Mir wurde grub ab Version 2 mit seinen unzähligen Skripten zu kompliziert
und ist für mein Standardsystem ohne Besonderheiten auch oversized.

Vielleicht findet sich ja noch jemand anderes, der es erklärend weiterführt?

Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr gut,
vielleicht als neuen Thread.  Ich bezweifle aber, dass sich jemand
dafuer findet:((
___
Regards
  JJenssen

Yast2 -> System -> Boot Loader (-> Kernel Parameters)
(ja, ich habe Englisch als Sprache eingestellt)

ich verstehe Grub2 eigentlich nicht, aber in der Vergangenheit habe ich
Sachen dort mit Erfolg gedreht. Wenn ich etwas dort nicht verstehe,
lass ich es in ruhe. If it ain't broke, don't fix it.

Bei "Bootloader Options" steht "Probe Foreign OS", braucht man (nur) bei
Dual-Boot. Da ist auch "Hide Menu on Boot", ich sehe lieber die ganze
Meldungen durchrauschen.

[Bernd Mayer]

Post by Andrew

Post by JJenssen
Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr
gut, vielleicht als neuen Thread.  Ich bezweifle aber, dass sich
jemand dafuer findet:((

Yast2 -> System -> Boot Loader (-> Kernel Parameters)
(ja, ich habe Englisch als Sprache eingestellt)

Hallo,

mal in /etc/default/grub reinzuschauen kann auch interessant sein.


Bernd Mayer

[JJenssen]

Post by Bernd Mayer

Post by Andrew

Post by JJenssen
Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr
gut, vielleicht als neuen Thread.  Ich bezweifle aber, dass sich
jemand dafuer findet:((

Yast2 -> System -> Boot Loader (-> Kernel Parameters)
(ja, ich habe Englisch als Sprache eingestellt)

Hallo,
mal in /etc/default/grub reinzuschauen kann auch interessant sein.
Bernd Mayer

Im Moment habe ich keine Probleme mit GRUB2. Mich nerven nur Dinge von
die ich nicht verstehe, obwohl ich mich schon mehrfach mit ihnen befasst
habe. Deshalb waere 'Nachhilfe' angesagt.

___

Regards
JJenssen

[Martin Schnitkemper]

Post by JJenssen
Im Moment habe ich keine Probleme mit GRUB2. Mich nerven nur Dinge von
die ich nicht verstehe, obwohl ich mich schon mehrfach mit ihnen befasst
habe. Deshalb waere 'Nachhilfe' angesagt.

Dann müsstest du mal ins Detail gehen und beschreiben, wo noch
Erklärungsbedarf besteht.

[JJenssen]

Post by Martin Schnitkemper

Post by JJenssen
Im Moment habe ich keine Probleme mit GRUB2. Mich nerven nur Dinge von
die ich nicht verstehe, obwohl ich mich schon mehrfach mit ihnen befasst
habe. Deshalb waere 'Nachhilfe' angesagt.

Dann müsstest du mal ins Detail gehen und beschreiben, wo noch
Erklärungsbedarf besteht.

Hallo Martin,
Du hast das in deiner anderen Antwort an Andrew selbst beantwortet: Was
muss z.B. in 40_custom stehen, um den angeregten Menuepkt.
'Wartungskonsole', was ich durch Anhaengen der '1' in dem GRUB2-Editor
in der Linux-Startzeile mache, weil ich es anders nicht geschafft habe.
Ich haette auch gerne einen Menuepkt., der nur in Level 3 startet.
Zudem habe ich nicht gefunden, ob die Module in allen nn-custom-Files
neu angegeben werden muessen, wie in 10-linux.
Dank fuer den Link zu Arch-Linux und dein Interesse.

___

Regards
JJenssen

[Martin Schnitkemper]

Post by JJenssen
Du hast das in deiner anderen Antwort an Andrew selbst beantwortet: Was
muss z.B. in 40_custom stehen, um den angeregten Menuepkt.
'Wartungskonsole', was ich durch Anhaengen der '1' in dem GRUB2-Editor
in der Linux-Startzeile mache, weil ich es anders nicht geschafft habe.

Hier https://help.ubuntu.com/community/Grub2/CustomMenus ist beispielsweise
anhand eines Beispiels gut erklärt, wie die Einträge in 40_custom aussehen
könnten, um einen weiteren Menüpunkt einzurichten.

Das Anhängen einer Ziffer für den runlevel ist genau so möglich, als wenn
man es manuell in der Kommandozeile eingetragen hätte. Oder man trägt dort
das target ein, wenn man es systemd-konform möchte.

Post by JJenssen
Ich haette auch gerne einen Menuepkt., der nur in Level 3 startet.

Das geht sinngemäß genau so wie für den runlevel 1, nur dann eben die 3
eintragen, oder multi-user.target als unit. Level 3 würde ich sowieso
favorisieren, weil man dann auch die Netzwerkfunktionen hat, die man unter
Umständen braucht, um Pakete nachladen zu können.

Post by JJenssen
Zudem habe ich nicht gefunden, ob die Module in allen nn-custom-Files
neu angegeben werden muessen, wie in 10-linux.

Ich würde mich zunächst einmal an dem Format der automatisch generierten
Konfigurationsdatei /boot/grub2/grub.cfg orientieren und das erst mal so in
eine eigene Konfiguration übernehmen, ergänzt um den gewünschten runlevel.

Versuch macht klug... einfach ausprobieren was unklar ist. Solange du dich
nur an den custom-Dateien versuchst, kann ja nichts anbrennen, weil du über
die vorhandenen Einträge das System weiter booten kannst.

[JJenssen]

Post by Martin Schnitkemper

Post by JJenssen
Du hast das in deiner anderen Antwort an Andrew selbst beantwortet: Was
muss z.B. in 40_custom stehen, um den angeregten Menuepkt.
'Wartungskonsole', was ich durch Anhaengen der '1' in dem GRUB2-Editor
in der Linux-Startzeile mache, weil ich es anders nicht geschafft habe.

Hier https://help.ubuntu.com/community/Grub2/CustomMenus ist beispielsweise
anhand eines Beispiels gut erklärt, wie die Einträge in 40_custom aussehen
könnten, um einen weiteren Menüpunkt einzurichten.
Das Anhängen einer Ziffer für den runlevel ist genau so möglich, als wenn
man es manuell in der Kommandozeile eingetragen hätte. Oder man trägt dort
das target ein, wenn man es systemd-konform möchte.

Post by JJenssen
Ich haette auch gerne einen Menuepkt., der nur in Level 3 startet.

Das geht sinngemäß genau so wie für den runlevel 1, nur dann eben die 3
eintragen, oder multi-user.target als unit. Level 3 würde ich sowieso
favorisieren, weil man dann auch die Netzwerkfunktionen hat, die man unter
Umständen braucht, um Pakete nachladen zu können.

Post by JJenssen
Zudem habe ich nicht gefunden, ob die Module in allen nn-custom-Files
neu angegeben werden muessen, wie in 10-linux.

Ich würde mich zunächst einmal an dem Format der automatisch generierten
Konfigurationsdatei /boot/grub2/grub.cfg orientieren und das erst mal so in
eine eigene Konfiguration übernehmen, ergänzt um den gewünschten runlevel.
Versuch macht klug... einfach ausprobieren was unklar ist. Solange du dich
nur an den custom-Dateien versuchst, kann ja nichts anbrennen, weil du über
die vorhandenen Einträge das System weiter booten kannst.

Den Versuch habe ich immer vermieden, wegen fuer mich unvorhersehbarer
Folgen. Ich werde es noch einmal versuchen.
Danke fuer den Link und deinen Anstoss.

___

Regards
JJenssen

[Bernd Mayer]

Post by Bernd Mayer

Post by Andrew

Post by JJenssen
Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr
gut, vielleicht als neuen Thread.  Ich bezweifle aber, dass sich
jemand dafuer findet:((

Yast2 -> System -> Boot Loader (-> Kernel Parameters)
(ja, ich habe Englisch als Sprache eingestellt)

mal in /etc/default/grub reinzuschauen kann auch interessant sein.

Im Moment habe ich keine Probleme mit GRUB2.  Mich nerven nur Dinge von
die ich nicht verstehe, obwohl ich mich schon mehrfach mit ihnen befasst
habe. Deshalb waere 'Nachhilfe' angesagt.

Hallo,

gerade habe ich noch dies hier speziell für suse gefunden, ein Kapitel
zu grub im Administrationshandbuch von suse:

https://documentation.suse.com/de-de/sles/12-SP4/html/SLES-all/cha-grub2.html

Ansonsten direkt zu den Quellen im manual von grub:

https://www.gnu.org/software/grub/manual/grub/grub.html

Einen Wikipedia-Artikel gibt es auch:
https://de.wikipedia.org/wiki/GRUB2


Bernd Mayer

[JJenssen]

Post by Andrew

Post by JJenssen

Post by Bernd Mayer
Hallo,
und Danke für den Input.

Post by Martin Schnitkemper
Deswegen müssen eigene Menüeinträge in /etc/grub.d/40_custom vorgenommen
werden, grub-mkconfig baut dann daraus wieder eine /boot/grub/grub.cfg.

Gefunden. Vermutlich kann man da einfach den Default-Eintrag aus der
Datei /boot/grub2/grub.cfg übernehmen und die 1 anhängen.
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Post by Martin Schnitkemper
Mir wurde grub ab Version 2 mit seinen unzähligen Skripten zu kompliziert
und ist für mein Standardsystem ohne Besonderheiten auch oversized.

Vielleicht findet sich ja noch jemand anderes, der es erklärend weiterführt?

Einen verstaendlichen Nachhilfekurs fuer GRUB2 faende ich auch sehr
gut, vielleicht als neuen Thread.  Ich bezweifle aber, dass sich
jemand dafuer findet:((
___
Regards
   JJenssen

Yast2 -> System -> Boot Loader (-> Kernel Parameters)
(ja, ich habe Englisch als Sprache eingestellt)
ich verstehe Grub2 eigentlich nicht, aber in der Vergangenheit habe ich
Sachen dort mit Erfolg gedreht.  Wenn ich etwas dort nicht verstehe,
lass ich es in ruhe.  If it ain't broke, don't fix it.
Bei "Bootloader Options" steht "Probe Foreign OS", braucht man (nur) bei
Dual-Boot.  Da ist auch "Hide Menu on Boot", ich sehe lieber die ganze
Meldungen durchrauschen.

So habe ich das auch immer gehalten. Danke fuer die Antwort.

___

Regards
JJenssen

[Martin Schnitkemper]

Post by Andrew
ich verstehe Grub2 eigentlich nicht, aber in der Vergangenheit habe ich
Sachen dort mit Erfolg gedreht. Wenn ich etwas dort nicht verstehe,
lass ich es in ruhe. If it ain't broke, don't fix it.

Wenn aber jemand einen eigenen Menüeintrag wünscht, um eben auf solche
Katastrophen wie einem fehlgeschlagenen Systemstart wegen eines korrupten
Pakets vorbereitet zu sein, dann muss er sich wohl oder übel mit den
Interna von grub auseinandersetzen.

[Martin Schnitkemper]

Post by Alexander Goetzenstein
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?

Ja, mit Partitionslabel. Dann wird die Partition anhand des Labels und
nicht mehr des Gerätenamens oder der UUID angesprochen, was dann auch einen
Hardwarewechsel überleben würde.

Bei einem geplanten Hardwarewechsel sichere ich die Partitionen mit
fsarchiver, das stellt auch die ursprüngliche UUID wieder her, so dass
danach keine Korrekturen an den Einträgen des Bootmanagers notwendig werden.

Post by Alexander Goetzenstein
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Ja, mit Variablen. Das wird ähnlich schon in dem vorhandenen Skript
"/etc/grub.d/10_linux" angewandt und müsste so dann auch in einen eigenen
Skript übernommen werden. Das kann aber eigentlich nur in
"/etc/grub.d/40_custom" passieren, weil nur das auch später von
grub-mkconfig verarbeitet wird. In den Konfigurationsdateien unter /boot
stehen bereits die festen Kernel-Versionsbezeichnungen, die von den Skripts
beim Erstellen gesetzt wurden.

Post by Alexander Goetzenstein
Vielleicht findet sich ja noch jemand anderes, der es erklärend weiterführt?

Es gibt schon gute Beschreibungen, z. B.
https://wiki.archlinux.org/title/GRUB aber es bleibt dennoch eine schwer
verdauliche Kost. Für dein Vorhaben sollten sich aber auch im Netz
Beschreibungen finden lassen.

[Alexander Goetzenstein]

Hallo,

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
/dev/sda4). Kann man das universeller gestalten, etwa für den Fall des
Hardwarewechsels?

Ja, mit Partitionslabel. Dann wird die Partition anhand des Labels und
nicht mehr des Gerätenamens oder der UUID angesprochen, was dann auch einen
Hardwarewechsel überleben würde.

Mist: das endet bei mir mit /dev/sda3, vermutlich wg. LUKS.

Post by Martin Schnitkemper
Bei einem geplanten Hardwarewechsel sichere ich die Partitionen mit
fsarchiver, das stellt auch die ursprüngliche UUID wieder her, so dass
danach keine Korrekturen an den Einträgen des Bootmanagers notwendig werden.

Danke für den Hinweis, das schaue ich mir mal an. Bislang erstelle ich
für den Notfall Abbilder mit dd, aber das bedingt ja die gleiche
Ersatzhardware.

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Ja, mit Variablen. Das wird ähnlich schon in dem vorhandenen Skript
"/etc/grub.d/10_linux" angewandt und müsste so dann auch in einen eigenen
Skript übernommen werden.

Uff...

Post by Martin Schnitkemper
Es gibt schon gute Beschreibungen, z. B.
https://wiki.archlinux.org/title/GRUB aber es bleibt dennoch eine schwer
verdauliche Kost.

Das scheint mir auch so.

[Martin Schnitkemper]

Post by Alexander Goetzenstein
Mist: das endet bei mir mit /dev/sda3, vermutlich wg. LUKS.

Das kann gut möglich sein. Ich habe auch eine LUKS-Vollverschlüsselung und
mal nachgesehen; da ist bei mir auch ein Device eingetragen. Da es sich um
eine NVMe-SSD handelt und es ein solches Gerät im Rechner nur einmal gibt,
ist eine Verwechselung ausgeschlossen. Ob an der Stelle auch die Angabe
eines Labels erlaubt ist, habe ich noch nicht versucht.

Post by Alexander Goetzenstein
Danke für den Hinweis, das schaue ich mir mal an. Bislang erstelle ich
für den Notfall Abbilder mit dd, aber das bedingt ja die gleiche
Ersatzhardware.

Da ist der fsarchiver flexibler: er kann die Sicherung auf einen
Datenträger anderer Größe und auch eines anderen Dateisystem
wiederherstellen und erstellt auch das Dateisystem selber. Im Gegensatz zu
tar ist jede einzelne Datei mit einer Checksumme gesichert so dass bei
einem Lesefehler nicht das gesamte Archiv unbrauchbar ist, sondern nur eine
einzelne Datei. fsarchiver ist der Nachfolger des vielleicht besser
bekannten partimage vom selben Entwickler.

Bei Arch gibt es nicht das Konzept mit den zwei Kerneln, einem neueren und
einem älteren, in sofern stellt sich die Problematik auch nicht, wie man
von welchem Kernel booten soll. Für den Notfall habe ich einen USB-Stick
mit dem Installationsimage, von dem ich booten und in das System wechseln
kann, um eventuelle Reparaturen von außen vornehmen zu können. Im
Paket-Cache halte ich immer zwei Generationen vorrätig, so dass ich auf
eine frühere Version wechseln könnte.

Ich kann mich aber auch nicht erinnern, dass in all den Jahren jemals die
Situation eingetreten ist, dass das System nach einem Update nicht mehr
startete.

[Alexander Goetzenstein]

Hallo,

Post by Martin Schnitkemper
Ich kann mich aber auch nicht erinnern, dass in all den Jahren jemals die
Situation eingetreten ist, dass das System nach einem Update nicht mehr
startete.

jetzt erinnere ich mich wieder, warum ich auf dd gekommen bin: genau das
ist mir passiert, da wurde /boot nicht mehr gefunden, bzw. auch nach
diversen Reparaturversuchen nicht als solches anerkannt. Um LUKS brauche
ich mich dann auch nicht mehr zu kümmern, das ist dann alles im Image
enthalten.

[Martin Schnitkemper]

Post by Alexander Goetzenstein
jetzt erinnere ich mich wieder, warum ich auf dd gekommen bin: genau das
ist mir passiert, da wurde /boot nicht mehr gefunden, bzw. auch nach
diversen Reparaturversuchen nicht als solches anerkannt. Um LUKS brauche
ich mich dann auch nicht mehr zu kümmern, das ist dann alles im Image
enthalten.

Ja, das spricht für die Verwendung von dd. Der fsarchiver arbeitet
dateiorientiert, es wird also die unverschlüsselte Partition gesichert, was
dann voraussetzt, dass man die Sicherung wieder auf einem verschlüsselten
Datenträger erstellt. Man müsste also vor der Sicherung erst die Partition
manuell entsperren und dann das Gerät unter /dev/mapper sichern, und dann
bei der Wiederherstellung zunächst manuell wieder eine verschlüsselte
Partition erstellen, in die dann die Wiederherstellung erfolgen kann.

Mir war nur der Platzbedarf der dd-Images zu groß und die Sicherung auch zu
zeitaufwendig, weil ja auch die unbelegten Bereiche mit gesichert werden,
man also für die Sicherung mindestens eine gleich große externe Platte
haben muss wie die zu sichernde. Da erschien mir der nur gelegentlich
anfallende Mehraufwand für eine Sicherung mit dem fsarchiver vertretbarer.

[Martin Schnitkemper]

Post by Alexander Goetzenstein
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Ich meine mich noch aus meiner SUSE-Zeit daran erinnern zu können, dass auf
den Kernel und die initrd auch noch symbolische Links "vmlinuz" und
"initrd" gesetzt werden. Vermutlich werden die bei einem Kernelupdate
auch wieder neu gesetzt, so dass man in einem zusätzlichen Eintrag in grub
immer nur auf diese beide Links referenzieren müsste, die dann auf die
eigentlichen Dateien zeigen.

Damit würde zwar im Menüeintrag nicht die aktuelle Kernelversion angezeigt,
es würde aber trotzdem immer der aktuelle Kernel mit optional eigenen
Kernelparametern gestartet und man müsste sich auch um die Belegung der
Variablen keine Sorgen machen.

[JJenssen]

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Ich meine mich noch aus meiner SUSE-Zeit daran erinnern zu können, dass auf
den Kernel und die initrd auch noch symbolische Links "vmlinuz" und
"initrd" gesetzt werden. Vermutlich werden die bei einem Kernelupdate
auch wieder neu gesetzt, so dass man in einem zusätzlichen Eintrag in grub
immer nur auf diese beide Links referenzieren müsste, die dann auf die
eigentlichen Dateien zeigen.
Damit würde zwar im Menüeintrag nicht die aktuelle Kernelversion angezeigt,
es würde aber trotzdem immer der aktuelle Kernel mit optional eigenen
Kernelparametern gestartet und man müsste sich auch um die Belegung der
Variablen keine Sorgen machen.

Die Links gibt es immer noch bei openSuse. Verweisen bei mir auf den
vmlinuz-5.3.18-150300.59.43-preempt-Kernel. Ich muss mich noch schlau
machen, was der Unterschied zwischen *-preempt- und *-default-Kernel ist.

___

Regards
JJenssen

[JJenssen]

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
Dann wird mehrfach auf die Kernelversion abgestellt, etwa mit
/vmlinuz-5.14.14-1-default
oder
/initrd-5.14.14-1-default
was dann spätestens nach dem zweiten Update nicht mehr funktionieren
dürfte, wenn der so bezeichnete Kernel gelöscht wurde. Kann man das
dauerhafter hinbekommen?

Ich meine mich noch aus meiner SUSE-Zeit daran erinnern zu können, dass auf
den Kernel und die initrd auch noch symbolische Links "vmlinuz" und
"initrd" gesetzt werden. Vermutlich werden die bei einem Kernelupdate
auch wieder neu gesetzt, so dass man in einem zusätzlichen Eintrag in grub
immer nur auf diese beide Links referenzieren müsste, die dann auf die
eigentlichen Dateien zeigen.
Damit würde zwar im Menüeintrag nicht die aktuelle Kernelversion angezeigt,
es würde aber trotzdem immer der aktuelle Kernel mit optional eigenen
Kernelparametern gestartet und man müsste sich auch um die Belegung der
Variablen keine Sorgen machen.

Die Links gibt es immer noch bei openSuse.  Verweisen bei mir auf den
vmlinuz-5.3.18-150300.59.43-preempt-Kernel.  Ich muss mich noch schlau
machen, was der Unterschied zwischen *-preempt- und *-default-Kernel ist.
___
Regards
  JJenssen

Die Installation der preempt-Kernel resultieren aus einem Bug eines
Paketes zum Update von Oracle Virtualbox vor einiger Zeit. Naeheres hier:
https://forums.opensuse.org/showthread.php/549337-Is-it-normal-that-my-running-kernel-is-kernel-preempt-instead-of-kernel-default
https://forums.opensuse.org/showthread.php/548030-Update-Virtualbox-conflicts-with-Virtualbox
https://forums.opensuse.org/showthread.php/548018-Kernel-preempt.
Nach Deinstallation von Virtualbox + der *-preempt-Kernel, der
Reinstallation der *-default-Kernel und Kopieren der Graphik-Treiber ist
das System wieder in 'normalem' Zustand.

___

Regards
JJenssen

[Alexander Goetzenstein]

Hallo,

Post by JJenssen
Die Links gibt es immer noch bei openSuse. Verweisen bei mir auf den
vmlinuz-5.3.18-150300.59.43-preempt-Kernel. Ich muss mich noch schlau
machen, was der Unterschied zwischen *-preempt- und *-default-Kernel ist.

wo genau finden die sich denn bei Dir, wie heißen sie genau?
Bei mir kann ich keine vmlinuz* finden, die nicht auch eine

Post by JJenssen
# find / -name vmlinuz*
find: Dateisystemschleife erkannt; ‘/.snapshots/1/snapshot’ ist ein Teil der gleichen Schleife wie ‘/’.
/.snapshots/933/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/935/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/936/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/951/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/952/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/953/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/954/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/955/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/956/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/957/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/958/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/959/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/.snapshots/961/snapshot/usr/lib/modules/5.14.14-1-default/vmlinuz
/boot/vmlinuz-5.14.14-1-default
/boot/vmlinuz-5.13.8-1-default
/usr/lib/modules/5.14.14-1-default/vmlinuz

[Bernd Mayer]

Post by Alexander Goetzenstein

Post by JJenssen
Die Links gibt es immer noch bei openSuse. Verweisen bei mir auf den
vmlinuz-5.3.18-150300.59.43-preempt-Kernel. Ich muss mich noch schlau
machen, was der Unterschied zwischen *-preempt- und *-default-Kernel ist.

wo genau finden die sich denn bei Dir, wie heißen sie genau?
Bei mir kann ich keine vmlinuz* finden, die nicht auch eine

Hallo,

vmlinuz und initrd liegen im /boot-Verzeichnis und das sind symlinks auf
nummerierten Versionen.

Bei Debian-Ablegern habe ich diese symlinks auch schon im /-Verzeichnis
gesehen.


Bernd Mayer

[Martin Schnitkemper]

Post by Alexander Goetzenstein
wo genau finden die sich denn bei Dir, wie heißen sie genau?
Bei mir kann ich keine vmlinuz* finden, die nicht auch eine

Post by JJenssen
# find / -name vmlinuz*

Versuche mal zusätzlich "-type l" für die Suche nach symbolischen
Links.

Oder gleich "ls -l /boot", der Link ist dann mit "l" in der ersten Spalte
gekennzeichnet, und durch den Verweis "->" hinter dem Dateinamen.

[Alexander Goetzenstein]

Hallo,

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
wo genau finden die sich denn bei Dir, wie heißen sie genau?
Bei mir kann ich keine vmlinuz* finden, die nicht auch eine

Post by JJenssen
# find / -name vmlinuz*

Versuche mal zusätzlich "-type l" für die Suche nach symbolischen
Links.
Oder gleich "ls -l /boot", der Link ist dann mit "l" in der ersten Spalte
gekennzeichnet, und durch den Verweis "->" hinter dem Dateinamen.

auch ein
find / -type l | grep -i vmlinuz
bringt keine Treffer. Vielleicht hat SuSE das ja abgeschafft?

[Bernd Mayer]

Post by Bernd Mayer
Hallo,

Post by Martin Schnitkemper

Post by Alexander Goetzenstein
wo genau finden die sich denn bei Dir, wie heißen sie genau?
Bei mir kann ich keine vmlinuz* finden, die nicht auch eine

Post by JJenssen
# find / -name vmlinuz*

Versuche mal zusätzlich "-type l" für die Suche nach symbolischen
Links.
Oder gleich "ls -l /boot", der Link ist dann mit "l" in der ersten Spalte
gekennzeichnet, und durch den Verweis "->" hinter dem Dateinamen.

auch ein
find / -type l | grep -i vmlinuz
bringt keine Treffer. Vielleicht hat SuSE das ja abgeschafft?

Hallo,

"SuSE" gibt es ja in mehreren Versionen, etwa Leap, tumbleweed oder SLES.

In openSUSE-Leap-15.3 finde ich die symlinks als vmlinuz und initrd auf
mehreren Systemen etwa in VirtualBox, auf älteren PCs die mehre upgrades
durchgemacht hatten und auf einem neuen PC mit einer frischen Installation.

Ich überlege, wovon dies abhängt oder ob man das irgendwo einstellen
kann. Hier sind das eher Standardinstallationen was dies angeht.


Bernd Mayer

[Alexander Goetzenstein]

Hallo,

Post by Bernd Mayer
"SuSE" gibt es ja in mehreren Versionen, etwa Leap, tumbleweed oder SLES.

hier™ ist es tumbleweed. Schade, wäre praktisch gewesen.

[Martin Schnitkemper]

Post by Bernd Mayer
Insgesamt waren da zahlreiche reboots und Tests notwendig. Das ist schon
eine ungewöhnliche Art ein CVE zu beheben wenn das System dann erstmal
überhaupt nicht bootet und man dann geneigt ist den alten Kernel weiter
zu verwenden.

Da war auch mein erster Gedanke.

Vor allem finde ich es bedenklich, dass man trotz der bekannten Probleme
nicht zeitnah einen fehlerkorrigierten Kernel nachschiebt, sondern die
defekte Version weiter verteilt und damit bewusst in Kauf nimmt, dass
weitere Benutzer mit einer ähnliche Hardwarekonfiguration in das
selbe Problem laufen.

Ein nach einem Update nicht mehr startendes System ist ja keine Bagatelle
und erfordert vom Benutzer umfangreiche manuelle Eingriffe und (wie man am
Diskussionsverlauf sieht) auch entsprechende Kenntnisse. In sofern sollte
das schnell abgestellt werden.

[Bernd Mayer]

Post by Martin Schnitkemper

Post by Bernd Mayer
Insgesamt waren da zahlreiche reboots und Tests notwendig. Das ist schon
eine ungewöhnliche Art ein CVE zu beheben wenn das System dann erstmal
überhaupt nicht bootet und man dann geneigt ist den alten Kernel weiter
zu verwenden.

Da war auch mein erster Gedanke.
Vor allem finde ich es bedenklich, dass man trotz der bekannten Probleme
nicht zeitnah einen fehlerkorrigierten Kernel nachschiebt, sondern die
defekte Version weiter verteilt und damit bewusst in Kauf nimmt, dass
weitere Benutzer mit einer ähnliche Hardwarekonfiguration in das
selbe Problem laufen.
Ein nach einem Update nicht mehr startendes System ist ja keine Bagatelle
und erfordert vom Benutzer umfangreiche manuelle Eingriffe und (wie man am
Diskussionsverlauf sieht) auch entsprechende Kenntnisse. In sofern sollte
das schnell abgestellt werden.

Hallo,

ja - mein erster Gedanke beim Hängen des Kernels war "Oha - ist da
vielleicht eine Festplatte defekt?".

Die genaue Ursache dieses Problems wäre auch interessant, nicht nur die
Abhilfe (herumdoktern am Symptom).

Das setzt sich ja womöglich fort über die Kernelsourcen, es gibt ja
zahlreiche unterschiedliche Systeme da draußen.


Bernd Mayer

[Martin Schnitkemper]

Post by Bernd Mayer
Die genaue Ursache dieses Problems wäre auch interessant, nicht nur die
Abhilfe (herumdoktern am Symptom).

Die Ursache war eine Änderung der Kernel-Entwickler
https://lore.kernel.org/all/***@linuxfoundation.org
die sich die openSUSE-Entwickler über einen Backport eingefangen hatte
und von den Kernel-Entwicklern zwar später korrigiert wurde, da war aber
scheinbar das Kernel-Paket von openSUSE schon draußen.

Post by Bernd Mayer
Das setzt sich ja womöglich fort über die Kernelsourcen, es gibt ja
zahlreiche unterschiedliche Systeme da draußen.

Das Problem wurde durch einen weiteren committ bereits behoben und würde
wahrscheinlich mit einem Paket, erstellt aus den aktuellen Quellen,
nicht mehr auftreten. Aber was nutzt schon eine schnelle Reaktion der
Kernel-Entwickler, wenn der Distributor nicht mitzieht :(

Da zeigt sich aber auch das grundsätzliche Problem, dass man bei openSUSE
an alten Kernel-Versionen wie 5.3.18 festklebt, der noch nicht einmal ein
LTS-Kernel ist. Diese Version ist seit dem 18.12.19 aus der offiziellen
Wartung, folglich müssen alle Änderungen mühsam über Backports
nachvollzogen werden.

[Bernd Mayer]

Post by Bernd Mayer
Hallo,
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.
Dieser Kernel macht auf mehreren Systemen Probleme.

Hallo,

heute gab es ein Kernelupdate für openSUSE-Leap-15.3.


Bernd Mayer

[Andrew]

Post by Bernd Mayer
Hallo,
auf openSUSE-15.3 wurde hier bei updates ein Kernel mit der
ungewöhnlichen Nummerierung 5.3.18-150300.59.43-default eingespielt.
Dieser Kernel macht auf mehreren Systemen Probleme. Beim Booten hängt
das System ohne Bildschirmausgabe. Das Booten bis zum Hängenbleiben
erfolgt auch recht schnell. Die üblichen ausführlichen Meldungen auf der
Konsole, verbunden mit Festplattenaktivitäten, erscheinen nicht.
Weiß  hier jemand was da los ist?
Bernd Mayer

ok, Problem gelöst mit dem Kernel Update.

Sowas ist schon mal passiert - um 2017 mit dem nouveau (nVidia) Treiber.
Da hat jemand ein Update gemacht und ging anschließend im Urlaub. Das
Problem wurde erst behoben als er aus dem Urlaub zurückkehrte, wer
nouveau benutzte musste so lange mit dem alten Kernel arbeiten.