Welche Testing-Pakete für Intel/Skylake?

[Klammer]

Hey hey,

ich brauche mal rat, welche Pakete aka. Treiber "in der Regel" entscheidend sind wenn es um Dinge wie Chipsatz, Ethernet, Intel-Grafik, etc. geht.
Mir ist klar, dass das vom Einzelfall abhängt, doch daher mein Szenario weshalb ich verwundert bin.

Situation
Ich habe ein Notebook mit Skylake-Architektur. Installiert habe ich das aktuelle Debian (8.5) und demzufolge den entsprechenden Kernel linux-image-3.16.0-4-amd64.

In meine Sources habe ich ebenfalls jessie-backports und testing mit aufgenommen, wobei die drei Quellen wie folgt gepinnt sind:

• 700 stable
• 600 backports
• 500 testing

Die Ausgabe via lspci ergibt, dass die entsprechenden Geräte nicht "überzeugend" (d.h. nicht der konkrete Bezeichner) erkannt werden, sondern bloß mit allgemeinen "intel-devices" label versehen sind (die konkrete Ausgabe kann ich bei bedarf noch nachliefern - müsse dazu das System aber weider neu aufsetzen).

Ich habe nun versucht nach und nach einzelnen Pakete zunächst aus Backports zu laden u.A. den aktuellen backport-Kernel linux-image-4.6.0-0.bpo.1-amd64.
Die Pakete sind

• xserver-xorg-video-intel
• firmware-linux-nonfree
• firmware-misc-nonfree
• libdrm-intel1
• intel-microcode

dies brachte allerding keine Verbesserung. Auch ein selbige Pakete (abgesehen vom Kernel) aus testing zu laden brachte keine Änderung.

Erst als ich pauschal

Code: Alles auswählen

 apt-get -t testing upgrade

ausgeführt habe (backports hier brachte auch nichts) lößte alle Probleme und sämtliche Geräte wurden anschließend erkannt.

Daher nun meine Frage:
Welche Pakete könnten die entsprechende Aktualisierung in testing bezüglich allgmeiner Hardwareunterstüzung enthalten, so dass nur dieses geladen werden müssten? Gibt es hier generell Verdächtige typische Paket-Bündel oder sind dies tatsächlich so spezielle Einzelpakete für jedes Gerät seperat, dass man dies so allgemein garnicht vermuten kann?
Ich mein: In der Auflistung der Pakete, die durch das Upgrade-Kommando oben von apt angezeigt werden als zu aktualisieren, ist nirgends eines dabei, welches im Namen auf "Intel" o.Ä. schließen läßt.

Wäre super, wenn ihr mir hier weiterhelfen könnt

[rendegast]

Mit obigem Set (+ kernel) aus backports hast Du schon richtig ausgewählt.

Wenn es dann doch erst mit testing/stretch klappt, dann bleibe dabei.

Dem 'upgrade' solltest Du noch ein 'dist-upgrade' hinterherschieben,
gegebenenfalls 'dist-upgrade --no-install-recommends'.
Das pinning und die jessie-/jessie-backports-Quellen kannst Du dann weglassen.


Hinterher noch mit zBsp. apt-show-versions, deborphan u.ä. entsprechenden Überbleibseln nachspüren, die sich eventuell als Ostereier erweisen könnten.
Auch sowas

Code: Alles auswählen

dpkg -l | egrep -v "^ii"

[Klammer]

Okay, du empfiehlst mir echt alles auf Testing zu upgraden? Hmm, komm ich wohl nicht drum rum... :/
Bin nur kein Freund von nicht-stable Systemen. Aber okay. Vielen Dank für den Tipp.

Eins noch: Wenn ich jetzt komplett auf stable/backports verzichte und für das Upgrade stable wähle, dann direkt nach diesen upgrade/dist-upgrade aber wieder stable bzw. Backports nach oben pinne, werden dann irgendwann wieder die stable-Packages geupgraded wenn diese dann in ferner Zukunt neuere Versionsnummern haben als die, die ich mir damals aus testing geholt habe?
Also was ich meine: Weiß apt noch später, dass diese Pakete aus "testing" stammen und überbügelt diese selbst bei neueren Version in stable am enden nicht?

[rendegast]

Okay, du empfiehlst mir echt alles auf Testing zu upgraden?

Keine richtige Empfehlung, eher Pragmatismus.
Es hätte halt mit dem obigen Paketset aus backports funktionierten müssen/sollen, hätte ...

Weiß apt noch später, dass diese Pakete aus "testing" stammen und überbügelt diese selbst bei neueren Version in stable am enden nicht?

Dazu würde in sources.list nicht "testing" gesetzt, sondern der Name "stretch",
da dieser beim Release erhalten bleibt.

Besonderheit des backports-Repo.
Einmal ist backports per default auf Pin-Priority 100 gesetzt.
Solltest Du dennoch ein spezielles Pinning gesetzt haben, so beachte

$ apt-cache policy
...
release o=Debian Backports,a=jessie-backports,n=jessie-backports,l=Debian Backports
...

daß die release-Pin a= und n= auf den Namen gesetzt sind und sich das beim Release ändert.
Möglichkeiten zur Berücksichtigung sind zBsp.:
Pin: release o=Debian Backports,l=Debian Backports
oder
Pin: release o=Debian Backports,a=*-backports,n=*-backports,l=Debian Backports