Stable&backports : kernel et pilotes graphiques libres

Bonjour ! Je souhaiterais utiliser les backports sur ma Debian stable pour profiter :
– des améliorations du noyau Linux
– des améliorations des pilotes graphiques libres (il y a eu pas mal de mouvements récemment)

J’ai suivi la marche la doc francophone sur le wiki officiel, en ajoutant cette ligne à mon /etc/apt/sources.list (suffisant pour mon objectif je dirais) :

Édition : finalement le « contrib non-free » est nécessaire pour couvrir les firmwares-linux-nonfree…

En exécutant aptitude, il y a plein de nouveaux paquets, dont tout ce qui concerne Linux 3.10. Ça semble bien se présenter.

S’en suit tout une liste de questions que je pose aux habitués avant de me lancer :
– comment peut-on obtenir la liste des paquets sur wheezy-backports en ligne de commande (une seule si possible) ?
– quel paquet installer pour installer le noyau 3.10 (il y en a une paire) ?
– les pilotes libres sont-ils backportés ? dans ce cas quel paquet installer ?
– l’installation du noyau 3.10 va-t-elle mettre à jour automatiquement Grub ?
– les nouveaux noyaux sont-ils installés automatiquement ? ou cela nécessite-t-il une intervention manuelle ?
– lors de l’apparition du noyau 3.12 dans les backports, le noyau 3.10 disparaîtra-t-il ?

Merci de partager votre expérience :wink:

Bon, je viens de sauter le pas. (pré-requis : le dépôt wheezy-backports dans le sources.list)

1ère étape : installation du noyau 3.10

Il y a un soucis de initramfs, mais aptitude en ligne de commande trouve une solution. La ligne de commande est bien moins déconcertante qu’en lançant aptitude « en graphique ».

2nde étape : les différents paquets dipos + mise à jour des firmware-linux-nonfree

[code]# aptitude

aptitude -t wheezy-backports[/code]

Notez qu’en lançant « aptitude » ou « aptitude -t wheezy-backports », la liste des paquets pouvant être mis à jour change. La deuxième commande augmente la priorité par défaut du dépôt wheezy-backports (plus faible que wheezy), autorisant la mise à jour vers des versions plus récentes. Supposition : le scénario pourrait être proposé « en graphique » dans la première étape en lançant « aptitude -t wheezy-backports ».

En faisant le tour, et en cherchant ce qui est lié aux pilotes graphiques libres, on ne trouve que le paquets firmware-linux-nonfree à mettre à jour (ce paquet permet une bonne communication des pilotes libres avec le matériel).

Édition : j’ai merdé dans un « répondre »

Pas de soucis rencontrés à ce jour. J’essaierai de répondre à mes questions un de ces 4…

Hello !

Je me demandais quelle version de kernel tu peux trouver dans les backport de wheezy. google ne m’a pas aidé…
Pour l’instant je suis en 3.2 (normalement le max avec Wheezy 7.2)

J’ai quelques soucis avec l’install d’une carte PCI-E USB3.0, j’avais envie de tenter un kernel plus recent, ca bouge beaucoup ces derniers mois !

Je dirais que pour ton soucis matériel, un noyau récent peut vraisemblablement aider…

Noyau le plus récent dans Wheezy-backports = 3.10

Théoriquement la liste des paquets du dépôt doit pouvoir être trouvée ici : http://packages.debian.org/wheezy-backports/ (Malheureusement la page est vide, j’ai envoyé un mail à l’administrateur du site)

Sinon, en fouillant directement dans les dépôts, tu peux directement regarder la liste des paquets présents dans ce fichier : http://ftp.debian.org/debian/dists/wheezy-backports/main/binary-amd64/Packages.gz

wget http://ftp.debian.org/debian/dists/wheezy-backports/main/binary-amd64/Packages.gz gunzip -c Packages.gz | grep -e "^Package:" | grep -e linux-image

La liste des paquets debian-backports est maintenant disponible ici :
http://packages.debian.org/wheezy-backports/

Celle des paquets relatifs au noyau ici :
http://packages.debian.org/wheezy-backports/kernel/

Pour signaler les anomalies sur le site debian.org, envoyer un email ici : debian-www AT lists.debian.org

Bonjour,

Je viens de mettre a jour mon kernel, en 3.10 et les firwares (celui pour wifi et celui pour le son).

Tu demandais comment savoir ce qu’il fallait installe/upgrade (et puis ca pourra certeinement servir a d’autres personnes) :
Sur ce site : neowin.net/forum/topic/11624 … rt-kernel/ le mec explique qu’il faut bien identifier le kernel qu’on a avec cette commande :

Et ne pas oublier d’identifier les firwares avec celle la :

Ensuite y a plus qu’a upgrade/installer…

Ca fait quelques jour que tu as mis a jour ton kernel, est ce que tu as vu des modifications au niveau des performances et compagnie ??
Perso j’ai encore vu de modif.

[quote=“lludol”]Ca fait quelques jour que tu as mis a jour ton kernel, est ce que tu as vu des modifications au niveau des performances et compagnie ??
Perso j’ai encore vu de modif.[/quote]
Un être humain ne peut pas voir la différence à l’œil nu, c’est des améliorations microscopiques qui ne font une différence que sur les machines chargées à fond en permanence. Même si un kernel améliore certaines opérations de l’ordre de 1% (c’est énorme) faut bien se rendre compte que c’est souvent des opérations qui ne prennent que quelques millisecondes au pire du pire. Déjà que je suis pas capable de faire la différence entre 100ms et 99ms (ce qui est plus qu’énorme pour un appel système) alors t’imagines bien que quand on arrive dans les microsecondes voire nanosecondes c’est… hum… pas facile de voir l’amélioration. :wink:

Bref, c’est des économies de bouts de chandelles qui n’ont d’effet réel que lorsque la charge est très importante.

Le vrai intérêt d’un kernel récent sur les postes bureautique c’est pas la performance (ça concerne plutôt les applications utilisateur, c’est elles qui bouffent tout le temps de calcul) mais le support matériel pour les périphériques récents.

@syam
Ok, c’est note, merci pour l’explicaiton.

Y’a quand même des Michael Larabel qui te font des benchmarks à tout va sur différents kernels, pour cerner les améliorations de la pile graphique, des gens qui rapportent que tel commit améliore telle situation de 10% si ce n’est pas 120, donc tout dépends de ce qu’on mesure…

Pour ma part je n’ai aucun benchmark (sinon le nombre de FPS à Tuxracer, tiens il faudra que je le fasse tourner celui-là…), c’est juste que j’utilise les drivers libres pour des cartes AMD/ATI, et que je souhaite tirer profit des dernières améliorations : c’est surtout la gestion de la conso qui n’intéresse.

Je suis passé à ~70 FPS à ExtremeTuxRacer… Il ne me semble pas avoir déjà tâté ce genre de « score » avec ma carte graphique HD5570. J’ai plutôt souvenir de ~30-40 FPS (mais je dois avouer que je ne suis pas bien sûr)… Ça reste un « benchmark » après.

Sais pas.

Voici la liste que tu recherches (je suis parti du principe que ton processeur était en 64 bits), et effectivement il y a plusieurs paquets disponibles, mais tu vas vite trouver celui dont tu as besoin : packages.debian.org/search?suite … image-3.10

Ceux qui se terminent par “-dbg” sont pour les développeurs qui veulent debugguer le noyau. Donc tu peux déjà éliminer ceux-là.
Ensuite il y a les noyaux qui contiennent “-rt-”, ce sont des noyaux pour faire du temps réel, genre pour contrôler un missile, une machine-outil,… Pas pour toi non plus.
Du coup il ne te reste plus grand chose :

linux-image-3.10-0.bpo.2-amd64 linux-image-3.10-0.bpo.3-amd64
Un soupçon d’intuition nous permet de dire que la 2ème ligne est la même version que la 1ère ligne mais avec quelques bugs en moins (puisque le numéro de build est plus élevé). Pourquoi ils ont laissé la build 2 ? Probablement parce que la build 3 peut poser quelques problèmes dans certains cas très particuliers et que certaines personnes devront utiliser la build 2. Et encore même pas sûr, c’est peut être juste au cas où.

Donc voilà, tu sais quel paquet utiliser.

Les pilotes graphiques libres font partie du noyau. C’est même le but d’un noyau monolithique : intégrer un maximum de pilotes dans le noyau. Comme on peut étendre les fonctionnalités du noyau à l’aide de modules, on parle de noyau monolithique modulaire. Mais dans Debian les pilotes libres sont laissés directement en dur dans le noyau et non sous forme de modules (d’ailleurs je ne suis même pas sûr qu’il soit possible de mettre ces pilotes sous forme de modules, certains pilotes doivent être impérativement intégrés en dur dans le noyau).
Donc si tu mets à jour ton noyau, tu mets obligatoirement à jour tes pilotes graphiques libres. C’est tout l’intérêt du noyau !

Comme on est sous Debian et que l’équipe de dév fait un boulot formidable avec les dépendances, oui.
C’est l’intérêt des dépendances : on met un jour un paquet et hop, le gestionnaire de paquets va s’occuper des dépendances pour maintenir la cohérence du système. En l’occurence, il va appeler “update-grub” après l’installation de ton nouveau noyau.

L’installation d’un backport ne se fait normalement pas automatiquement à l’origine, il faut suivre une procédure manuelle pour forcer la mise à niveau, par exemple pour forcer le backport du noyau 3.10 à la place de ton noyau 3.2 qui est installé par défaut dans Wheezy.
Mais une fois que tu as installé le backport, il va se mettre à jour s’il le faut à chaque fois qu’il y aura une mise à jour car ton gestionnaire de paquets va tout faire pour maintenir les versions qui sont installées. Et donc si le noyau 3.11 est rajouté dans les backports, il ne viendra pas écraser ton 3.10. Mais ton 3.10 sera mis à jour à chaque fois (si nécessaire) à partir du moment où tu l’as installé.

Attention quand même, ce que je dis là c’est le comportement par défaut. Si tu as touché aux priorités des dépôts et des versions dans “/etc/apt/preferences”, tu changes le comportement et là ça va totalement dépendre des paramètres que tu auras mis.

Comme je viens de le dire, non.

Ca aurait été le cas si un méta-paquet avait été disponible dans les backports et que tu l’avais installé. J’explique.

Si tu installes le paquet “linux-image-3.10”, alors ce sera ce paquet qui sera mis à jour et pas un autre.
Maintenant supposons qu’un méta-paquet nommé “linux-image” pointant vers “linux-image-3.10” soit disponible dans les backports et que tu l’aies installé. Le jour où les développeurs sortent le paquet “linux-image-3.12”, ils feront pointer le méta-paquet “linux-image” vers “linux-image-3.12” au lieu de “linux-image-3.10”. Et donc quand tu feras la mise à jour de ton système, le paquet “linux-image” va se mettre à jour, et par le jeu des dépendances le gestionnaire de paquets va savoir qu’il faut mettre à jour aussi “linux-image-3.12”.
Il est même possible (il me semble, ça paraît logique) de faire en sorte que le méta-paquet mette à jour plusieurs versions de noyaux car il suffit de dire que “linux-image” dépend de toutes les versions de noyaux installés pour qu’ils soient également mis à jour. C’est l’intérêt des dépendances et des métas-paquets.

Je suis pas sûr d’avoir été clair sur ce dernier point.

Merci Cluxter pour ces infos… Je commençais à pouvoir répondre à quelques-unes de ces questions, et là mes intuitions sont confirmées :wink: