Que choisir : linux-image 5.14 ou 5.15?

Support Debian
#1

bonjour ,
avec debian bullseye n’ayant constaté aucune mise à jour depuis assez longtemps j’ai vérifé les versions de linux-image disponibles avec :
1 )

apt policy linux-image-amd64
linux-image-amd64:
  Installé : 5.10.84-1
  Candidat : 5.10.84-1
 Table de version :
     5.14.9-2~bpo11+1 100
        100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages
 *** 5.10.84-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
     5.10.46-5 500
        500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages
  1. à partir de synaptic qui m’a donné 5.14 et 5.15 comme dernières versions

D’où 2 questions :

  1. pourquoi malgré l’installation de linux-image-amd64 censé suivre les versions successives mises à jour ce paquet est resté à une version antérieure ?

  2. entre 5.14 proposée par « apt policy » et 5.15 proposé par synaptic quel meilleur choix ?

ps1 : serait-ce la source « bpo » de ces paquets qui en est la cause debian recommandant de l’utiliser avec précaution ? ( où ai-je lu ça je ne sais pas mais je l’ai lu ) .

ps2 : je précise que j’aurais une raison particulière d’installer 5.15 car il a peut-être résolu un problème inexpliqué sous bullseye = gel aléatoire simultané du clavier et du pavé tactile . Ayant utilisé bookworm pendant 15 jours d’affilée sans rencontrer aucun problème de ce genre je me dis que peut-être cette version 5.15 utilisée dans bullseye supprimerait ce bogue .

Installation Debian11 avec video intel non free
#2

Je doit avoir de la merd… dans les yeux mais je ne vois pas de trace de 5.15 dans les propositions de kernel disponible d’après le retour de ton policy.

#3

@zao a précisé que la version 5.15 était proposée par aptitude. Tu vas me dire qu’apt et aptitude utilisent les mêmes sources, donc devraient offrir les mêmes versions. D’après ce que je vois du contenu de bullseye-backports sur packages.debian.org, l’explication pourrait être la suivante :

  • un paquet linux-image-5.15*-amd64-unsigned (non signé pour le secure boot UEFI) est disponible, c’est peut-être lui que @zao a vu dans aptitude
  • il n’y a pas (encore ?) de paquet linux-image-5.15*-amd64 (signé)
  • le méta-paquet linux-image-amd64 dépend du paquet linux-image-5.14*-amd64 qui est le noyau signé le plus récent.

Parce que c’est le méta-paquet linux-image-amd64 de bullseye qui est installé et dépend du noyau 5.10, et à cause de la priorité plus basse du dépôt bullseye-backports, la version de ce dépôt ne sera pas installée automatiquement.

Et pas la version 5.14 ?
Si tu n’utilises pas le secure boot UEFI tu peux installer le noyau 5.15 non signé de bullseye-backports.

#4

j’ai enlevé le " secure boot " depuis longtemps car , il me semble du moins , que pour installer stretch je devais le faire mais maintenant que les versions signées existent je le remettrais dès que 5.15 aura une image signée disponible . C’est une sécurité supplémentaire , non ? ( je vais me renseigner plus avant là-dessus .

en attendant je vais installer la version non signée car si ça pouvaitme corriger le bogue signalé ça m’arrangerait . version synaptic = linux-image-5.15.0-0.bpo.2-amd64-unsigned

merci pour les réponses .

#5

En effet stretch n’était pas compatible avec le secure boot. Buster a été la première version supportant le secure boot.

Mouais, bof. C’est surtout des problèmes potentiels supplémentaires et des complications notamment quand on a besoin de modules externes du noyau (pilote propriétaire comme nvidia ou virtualbox ou module recompilé). Certes on ne peut amorcer qu’avec un chargeur et un noyau signés mais ni la configuration du chargeur d’amorçage, ni l’initramfs ni le reste du système n’étant signés on peut encore faire n’importe quoi avec eux.