Kernel 5.2.0-2 AMD64 aus unstable unter testing

[mcdaniels]

Hallo,
nachdem sich mein System (AMD Ryzen 7 3600) interessanterweise nach ca. 1h mit einem recht eigentümlichen Verhalten: Maus funktioniert, ich kann aber nichts mehr anklicken, Tastatur reagiert nicht, das System läuft aber weiter (Youtube läuft zb auch weiter), verabschiedet, habe ich mir heute gedacht ich hole mir den letzten Kernel aus unstable.

Da ich hiermit aber wenig Erfahrung habe, ist für mich fraglich, ob meine Vorgangsweise in Ordnung war:

1.) sources.list um unstable erweitert
2.) Kernel und headers 5.2.0-2 installiert
3.) Paket nvidia-driver aus unstable installiert
4.) System mit neuem Kernel hochgefahren - funktioniert
5.) sources.list -> unstable entfernt und auf bullseye rückgesetzt

Was meint ihr?

Das System läuft.

Danke!

PS: Gibt es ein eigenes Repository für die aktuellsten Kernels, welche man ggf. in die sources.list einbauen kann? Ich habe zwar gesucht, aber nix gefunden. Die Backports helfen mir hier ja auch nicht weiter...

EDIT: Hier gibts ne kleinere Abhandlung des Themas: viewtopic.php?t=169533 die mich aber auch nicht schlauer macht...

[KP97]

Du kannst jederzeit einen Kernel separat installieren. Entweder aus dem Sid-Repo oder direkt von der Paketdatenbank.
Vielleicht kommt der 5.2er ja auch mal nach Testing, aber es hat schon Ewigkeiten gedauert, bis der mal in Sid gelandet ist.
Du kannst natürlich auch den aktuellen Stable von kernel.org nehmen - momentan 5.2.9 - und selbst kompilieren.

[JTH]

Was meint ihr?

Wenn du dabei darauf achtest, nicht versehentlich mehr Pakete als gewollt aus Unstable zu installieren, ist das so okay. Mache ich, wenn – sehr selten – mal notwendig, schon ewig genau so.

Man kann natürlich auch Unstable dauerhaft in der sources.list lassen und sich vor den Unstable-Pakete per Pinning „schützen“. Aber die „Arbeit“ habe ich mir bisher nie gemacht.

[KBDCALLS]

Was meint ihr?

Wenn du dabei darauf achtest, nicht versehentlich mehr Pakete als gewollt aus Unstable zu installieren, ist das so okay. Mache ich, wenn – sehr selten – mal notwendig, schon ewig genau so.

Man kann natürlich auch Unstable dauerhaft in der sources.list lassen und sich vor den Unstable-Pakete per Pinning „schützen“. Aber die „Arbeit“ habe ich mir bisher nie gemacht.

Das ist aber die saubesrste Lösung . Sid setzt man per Pinnig auf -1 und den Kernel samt Headers und was sonst noch dazugehört auf 500

[Teobald]

Ist inzwischen in Debian Testing enthalten. hat dazu geführt, dass zwei Notebooks nicht mehr funktionieren:
Acer swift 5: kein Wlan
Medion xxx: kein Touchpad

Beim Start den alten Kernel wählen und beide gehen wieder.