Reprise du message précédent :
Bonjour tout le monde,
 
J'ai une question de noob sur les kernels (et leur update) : y-a-t-il un lien entre le hardware d'un poste (genre portable) et "la branche" de kernel max ?
 
Je m'explique, dans ma boite on a par exemple du :
 
* Dell Latitude 5580 (Ubuntu 20.04) avec un kernel à jour 5.4.0-131-generic
* HP ProBook 450 G6 (Ubuntu 20.04) avec un kernel à jour là aussi en 5.4.0-131-generic
* HP ProBook 450 G7 (Ubuntu 20.04) avec un kernel à jour 5.15.0-52-generic
 
=> Les postes sont mis à jour via un repo spécifique, et je constate donc des écarts "de branche" en fonction du matériel . Ou du moins ça en donne vraiment l'impression.
 
Et j'ai eu beau chercher, je n'ai rien trouvé comme explication
 
Si quelqu'un pouvait éclairer ma lanterne je lui en serai très reconnaissant

d'une manière générale non, à la limite sur du matos vraiment antique ça peut arriver mais là tes postes sont plutôt modernes.

Ton explication est simple : « Les postes sont mis à jour via un repo spécifique »
Il te faut aller causer avec les gestionnaires de ce dépôt.

Ces machines devraient être compatibles avec les derniers 6.x (EliteBook G7 850 & G8 855 inside).

Dans ce topic, tu trouveras un outil qui facilite les gestion des noyaux :
https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

Ok, merci pour vos retours ! Je vais me renseigner sur la gestion de notre dépôt local.

Je rajouterai juste que plus le matos est vieux, plus il est improbable qu'il continue d’être testé donc de nouveaux bugs peuvent arrivés avec les nouvelles versions de Linux... Jusqu'au jour ou le matos est tellement sans dev qu'il finit par voir son support viré du noyau; par exemple Linux ne supporte plus les 386 et va peut-être aussi arrêté de supporter les 486.

Avec du retard, je viens de mettre à jour la FP (pas mal occupé en ce moment)  
Merci à o'gure pour la transition.

Salut tout le monde,
 
je n'ai pas encore eu le fin mot de l'histoire sur la différence de kernels qu'on voit sur nos postes, par contre le fait d'avoir fait un test de remplacement de repository (repo de la boite par repo Canonical) n'a rien changé sur un Dell Latitude 3390 de test => kernel toujours en 5.4.* et pas 5.15.*
 
A votre connaissance il n'y aurait pas de limite à l'évolution des kernels suite à des mises à jour ?

l'apt update fonctionne bien ? si tu recherches un paquet mis à jour régulièrement (genre python3), il apparaît bien disponible dans la même version que ce que tu vois si tu recherches sur packages.debian.org ?

Tout dépend de la version de ta distrib' ... Sur Jammy (22.04), tu as les noyaux oem :  

 
Tout dépends du "noyau maitre" (je ne sais pas comment le dire xD).
 
En gros tu as un paquet qui dit "le noyau sera un 5.4" et qui va ensuite installer uniquement les évolutions de la branche 5.4 et ne passera jamais au 5.15 (sauf si tu lui demande manuellement ou lors d'une maj de la version de ta Ubuntu).
 
Là je ne retrouve plus mais par exemple sur proxmox pour passer du 5.15.* au 5.19.* je dois installer "pve-kernel-5.19" qui lui fera descendre le 5.19.17 et autres évolutions du 5.19.
 
Je ne sais pas si j'ai été très clair   .

L'étape d'après, tu gères les noyaux avec KRN (PPA kernel ou directement les sources kernel.org)

Snowear !
 
Je viens de remarquer que sur certains postes on a un kernel HWE alors que d'autres non ! Et effectivement, en HWE on peut avoir des kernel 5.15.* sur une version 20.04 LTSC.

Au risque de passer pour un idiot , on parlait de Rust dans le 6.x (6.1?) de mémoire, donc il faudra un autre compilateur aussi non? Je demande car toujours pas la fibre et sous Debian ça pourrait être un peu délicat aussi si c'est un truc récent...

Je compile les 6.0.x sous Debian 11 sans problèmes

Oui mais la on est au 6.1 déjà, du coup j'ai un doute. Le dernier 6.0(.12 je crois) pas de soucis.

J'attends le 6.1.1 pour le compiler sous Debian paskeu c'est des VM au taf et que je ne suis pas tout le temps dessus

Le 6.1 se compile sans soucis sous Debian 11 (faudra que je reboot à l'occasion d'ailleurs…).

Dans le doute, j'ai pris une VM bac à sable et la compil' 6.1.0 passe crème sur Debian.

Merci, je confirme, ça fonctionne très bien.

https://kernel.ubuntu.com/~kernel-p [...] /amd64/log
 
j'ai eu le même souci en compilant les sources sur mon gros PC. Le mode UEFI oblige la signature, et ça couine.
Aucun problème sur un système legacy/BIOS

Dans l'ordre :
1. es tu en secure boot sur la machine cible ?  

• Non, pas de soucis, un noyau non signé fait l'affaire (krn cc ou cci)
• Oui, passe la à la question 2

2. as tu généré tes propres clés ?  

• Non, pas de soucis, le lien https://wiki.debian.org/SecureBoot (chapitre Generating et Enrolling)
• Oui, passe à la question 3

3. as tu paramétré KRN avec les fichiers de clés générés ?  

• Non, fais un « krn configure RESET »
• Oui, appelle un marabout qui répare les motos russes

Il existe une autre approche si tu as le secure boot activé.  

• Tu généres les clés et tu les installes dans l'UEFI de la bécane.  
• Tu paramètres KRN avec les fichiers.  
• Tu installes un noyau non signé.  
• Tu signes le noyau installé avec un « krn signkernel Version »
• Tu rebootes.

1) oui
2) jamais eu besoin de générer quoi que ce soit, les précédentes compilations passaient sans problème
3) je n'ai pas utilisé ton script sur ce PC

Lors de la compil de base, le noyau n'est pas signé.
 
Des certificats sont certes générés, mais ils ne sont pas inscrits dans l'UEFI (mokutil --import). J'ai passé un peu de temps à comprendre les mécanismes de recompilation du noyau pour pondre « krn CompilSign » afin d'avoir un paquet contenant un noyau signé ainsi que les modules.  
 
Au pire du pire, tu génères des paquets sur un Legacy/BIOS, tu installes les paquets sur l'UEFI/SB et tu les signes avant de rebooter.  

WTF le 6.1.1 est passé
ils ont dû changer un truc, mais lequel

le 6.1 tourne sur la framboise 3.14
on va tenter le 6.2 dès qu'on aura compris les modifications apportées

Dites les barbu(e)s , vous savez si il y a des "travaux" en cours au niveau soucis de plantage avec certaines CG AMD / gestion de l'énergie pour ces cartes? Car c'est pour ça que je compile toujours le dernier noyau, mais vu que le soucis reste présent je me demande si je ne devrais pas revenir sur le noyau par défaut Debian.  
 
(Il y a un truc pour éviter les plantages, à savoir forcer la CG à la puissance maxi, ça fonctionne mais ça bouffe de l'énergie...)

C'est mystérieux ce souci car toutes les cartes amd ne sont pas touchées
J'ai trouvé ce truc de forcer la puissance maxi aussi sur le net
Mais ça ne touchait pas ma 6800 par exemple

Quels symptômes ça te fait ? que constate tu ?

J'en avais largement parlé dans le sujet Debian jusqu'à ce que je trouve cette astuce sur le net. En gros le PC plantait avec l'écran qui devenait tout blanc ou quelque chose comme ça et je crois que le ventilateur de la CG se mettait à fond aussi. Même les "touches magiques" Linux ne fonctionnaient plus, il fallait éteindre le PC en appuyant plusieurs secondes sur le bouton on/off. J'ai pas en tête ma CG, je peux vérifier si ça t'intéresse. Avec cette commande (voir ci-dessous, si ça peut servir...) plus aucun soucis, mais une CG à 45-50°C tout le temps et une conso qui va avec je suppose.

EDIT: J'oubliais: L'image "sautait" aussi parfois avant de planter, sachant que parfois 3 plantages par jour et parfois rien pendant une semaine. Très étrange...

j'ai fini par foutre à la benne ma 980ti car j'avais un problème de ce type justement (depuis une mise à jour en février dernier sur debian testing) j'ai supposé que c'était un problème avec les drivers nvidia et après l'avoir remplacée par une RX6800 je n'ai effectivement plus de problème...
Dans mon cas c'était l'écran qui s'éteignait au bout de ~10 minutes quand la carte était en idle (quand j'étais pas dans un jeu en gros), avec un sympathique "GPU has fallen off the bus." (parmi toute une brouette de messages d'erreur) dans dmesg. Jamais trouvé de solution, même en forçant les fréquences max en permanence ça arrivait quand même. Alors que sous windows je n'avais pas de problème.
En cherchant sur internet on trouve plein de gens qui ont ce type de problème dans des variantes un peu différentes, un vrai casse tête

Selon Phoronix, le 6.2 sort du bois demain .

Un dimanche ??? Il veut pas attendre lundi, au moins ?
 
Bon, de toute façon, sur Arch, on ne passera sûrement pas à la 6.2.x avant la 6.2.1, et on va sans doute pouvoir rigoler de nouveau quand le noyau LTS (que beaucoup gardent comme noyau de secours s’il y a un souci avec le normal) va, lui, passer en 6.1.x et prendre de l’avance sur le normal (vu qu’ils n’ont pas les mêmes mainteneurs et qu’ils ne se coordonnent pas pour éviter ce genre de chose).

Le noyau sort généralement le dimanche je crois bien.

En général les RC sortent le dimanche en fin d'après midi ou dans la soirée.  
Le RC8, c'était autour des 23h00

Hum, ça devrait bientôt le faire, vu sur le git  :

 
On verra demain .
 
 
edit:

Rien sur kernel.org pour le moment ^^"

EDIT : c'est bon c'est dispo !

Faites chauffer vos pcs \o/

J'avais déjà noté une certaine rapidité dans le lancement des applis avec les RC sur mes brouettes ... mais là sur ma grosse config, c'est pas mal du tout.

Préemption des tâches
Linux 6.3 POURRAIT mainliner les patchs RealTime
https://www.phoronix.com/news/Linux-6.3-printk

 
Ha ouai ça remonte loin encore là.
J'imagine le truc qui arrive sur n'importe quel site moderne, ouch!    
Enfin pour ça faudrait déjà qu'un navigateur compatible avec ce genre de CPU arrive à y aller... et là c'est le drame.
à la limite pour le forum HFR ça doit encore passer.  
 
En même temps il y a sûrement des coins du monde qui doivent bien utiliser des PC de 20 ans voir plus.
 
Enfin ça me rappelle que j'avais essayé une ubuntu sur un PC de 2004 genre en 2010 le pilote de la carte graphique (une ATI de l'époque) était déjà incompatible avec le gestionnaire Xorg parce que plus supporté par la nouvelle version.
Et là vous me dites que j'aurai pu trouver un pilote libre sauf que je crois bien que c'était le cas ici vu qu'il n'y en avait pas de propriétaire.

Tu peux surement utiliser lynx ou equivalent sur ce genre de vielles machines.

C’est pour ça qu’un fan de vieux Mac (les Classic, oui) a créé FrogFind!, afin de pouvoir accéder aux contenus des sites modernes via un proxy qui récupère les contenus principaux et simule un affichage en « mode lecture ». Compatible avec tous les navigateurs, même ceux en mode texte.

ça doit limité les interactions sur les sites non ?