[Ubuntu-QC] Mettre à niveau tout en préservant un noyau ancien

Gilbert Dion gilbertdion at gmail.com
Dim 4 Oct 16:19:12 UTC 2020


Merci, merci, merci pour ces très éclairantes et très claires explications.
Qui me font comprendre pourquoi les performances de mon installation n'ont
cessé de se dégrader depuis un bon moment. Je faisais avec, parce que
j'avais acquis la conviction que le le noyau linux ne supportait *plus* le
matériel graphique de mon ordinateur (un iMac 27 po. de 2011), du moins
c'est ce que j'avais compris sans trop comprendre à l'époque. Je me
débattais alors avec le problème de l'intensité de l'affichage dont le
réglage se perdait au retour de l'écran de veille (écran noir). J'ai ainsi
tweaké quelques configurations, sans résultat. Puis on est passé du noyau
4.10 à 4.13 avec la version 17.04, et c'est là que j'ai perdu l'affichage.

Je retiens de tout ça que le système *live* gère le matériel exactement de
la même façon qu'une fois installé de façon permanente. Je n'en étais pas
sûr! C'était parce que la mise à niveau, d'après ce que j'en
déduis, préservait des ajustements apportés antérieurement. Et je retiens
surtout que la réinstallation est préférable à la mise à niveau.

Je viens de retester la version *live* sur USB. Tout baigne. Je vais donc
procéder dans les prochains jours à la réinstallation. De toute façon, mon
ordi est tellement encombré de choses obsolètes qu'un bon ménage ne fera
pas de tort!

@+,
g


Le dim. 4 oct. 2020 à 00:02, Jean Christophe André <
jean-christophe.andre at auf.org> a écrit :

> Ah, désolé, j'ai oublié d'ajouter un « petit bout » sur ta vraie question…
> :-P
>
> Donc, peut-on continuer avec un vieux noyau sur une distribution récente ?
> Probablement que techniquement ça va passer, pour le fonctionnement de base
> du système. Mais il y a plusieurs raisons importantes de ne pas le faire…
>
> 1- la sécurité
>
> Tout code logiciel contient potentiellement des failles de sécurité. On
> peut se dire que tant qu'elles ne sont pas connues, il y a peu de risque
> (ce qui n'est pas vrai, mais c'est un autre débat). Mais quand on parle
> d'utiliser un code logiciel vieux de 3 ans, public de surcroît, dont les
> failles sont également annoncées publiquement, là on peut être certain
> qu'on est dans une situation à risque ! Et quand le code logiciel en
> question est au cœur du système qu'on utilise, tout le système et les
> données qu'il héberge deviennent à risque également. On pourrait se dire :
> « c'est pas grave, j'ai mis en place des filtrages réseau sur la machine, »
> ok, mais qui roule ces filtrages, sinon le système lui-même ? On a déjà vu
> passer des failles de sécurité qui touchaient la couche réseau et qui
> étaient donc déclenchables dès la réception d'un paquet réseau par le
> noyau. De telles failles sont donc exploitables dès qu'on se connecte à un
> Wi-Fi public, par exemple dans un café, une école, une bibliothèque, un
> bus, un train, un aéroport, etc.
>
> 2- la stabilité
>
> Le code du noyau n'évolue pas seul. Les applications utilisent le noyau
> pour communiquer avec le matériel au travers de librairies logicielles, en
> particulier la GNU Libc. Si on met à jour le système, et donc la Libc, mais
> sans mettre à jour le noyau, on peut se retrouver à un moment donné avec un
> décalage trop important entre ce que la Libc propose comme fonctions au
> applications et ce qu'elle peut réellement faire faire par le noyau. Dans
> ce cas, on se retrouve avec des applications qui s'attendent à une certaine
> réponse mais en obtiennent une différente de celle prévue. Normalement la
> Libc est justement là pour cacher ces changements et c'est cela qui
> garantit la portabilité et le bon fonctionnement des applications. Mais si
> la version de la Libc installée est trop éloignée de la version du noyau,
> il risque d'y avoir un moment où cette divergence va se sentir au dessus,
> avec des applications qui ne roulent pas de façon optimales, ou pire, pas
> correctement.
>
> 3- la performance
>
> Les nouveaux noyaux apportent des pilotes plus à jour et donc pratiquement
> toujours (à quelques exceptions près) un meilleur support pour les nouveaux
> matériels ou une amélioration des performances ou des fonctionnalités pour
> les matériels plus anciens. Les nouveaux noyaux apportent également presque
> toujours des améliorations de performances sur les fonctionnalités de base
> du noyau, telles que la gestion de la mémoire, la gestion du réseau, la
> gestion des accès disque, la gestion des systèmes de fichiers, etc. Et ces
> dernières années ces améliorations ont été plutôt impressionnantes ! On a
> constaté des changement importants au niveau de la réactivité du système
> pour une installation bureautique, du fait d'un meilleur ordonnancement des
> processus et de l'amélioration de la gestion mémoire et du cache disque.
>
> 4- la compatibilité
>
> Quand on veut pousser l'exploitation de sa machine jusqu'au maximum de son
> potentiel, on peut se retrouver à un moment donner à avoir besoin
> d'utiliser un module noyau, que ce soit pour obtenir des performances
> optimales ou pour effectuer des tâches qui ne peuvent se faire à
> performances correctes que très bas niveau dans le système. Or un module
> noyau doit être compilé par rapport au noyau sur lequel il va s'exécuter,
> et cela ne se passe bien que si le code du module est compatible avec le
> code du noyau. À un moment donné, quand on continue d'utiliser un noyau
> trop ancien, arrive un moment où les nouveaux modules noyaux développés ne
> supportent plus des versions de noyaux officiellement déclarées comme
> obsolètes (ou juste devenues obsolètes de fait, quand plus aucun
> développeur ne les utilise). Rendu là, on se prive malgré soi de nouvelles
> possibilités intéressantes, du fait que les nouveaux développements ne sont
> plus compatibles avec notre ancien noyau.
>
>
> Bref. Il est vivement recommandé de suivre les évolutions du noyau, ou
> plus généralement de ne pas forcer certains bouts du systèmes à rester en
> arrière lorsqu'on fait une montée de version.
>
> J.C.
>
>
> Le 20-10-03 à 21 h 23, Jean Christophe André a écrit :
>
>         Bonjour à toutes et à tous,
>
> Gilbert, à la lecture de ton premier courriel j'ai tout de suite pensé «
> un souci d'affichage ne peut pas durer aussi longtemps, il faut re-tester
> avec une LiveUSB. » Et tu nous dis ensuite dans ton second courriel que tu
> as testé avec une clé USB et que ça fonctionne sans souci. :-)
>
> Cela confirme directement que le problème n'est pas au niveau du support
> de ta carte graphique par le noyau, mais uniquement un souci de
> configuration du démarrage du noyau dans ton installation actuelle.
> Peut-être est-ce lié à des options de démarrage que tu avais dû mettre à
> l'époque pour supporter ta carte, mais qui n'ont plus de sens (ou jouent
> même contre toi) avec les noyaux plus récents.
>
> Donc mon conseil ici serait de profiter de l'occasion pour réinstaller
> complètement ton système, en ramenant juste la partie /home dans la
> nouvelle installation. Il faudra sans doute réinstaller les logiciels que
> tu avais installés tout du long, mais ça se retrouve facilement en étudiant
> les différences entre des "dpkg --get-selections" lancés sur l'ancien et le
> nouveau système.
>
> Sinon, si tu tiens absolument à chercher l'origine du problème, je te
> recommande de regarder du côté de /etc/default/grub, /etc/modprobe.d/ (et
> /etc/modules) et /etc/initramfs-tools/ qui sont les trois endroits
> classiques où on configurerait des choses qui auraient un impact sur le
> démarrage du noyau.
>
> Bonne chasse ! J.C.
>
>
> Le 20-10-03 à 15 h 46, Gilbert Dion a écrit :
>
> Je ne peux répondre à la question de savoir quel affichage n'est plus
> supporté, il n'y a pas d'affichage. Ça survient donc longtemps avant de
> pouvoir choisir Wayland ou X11 pour ouvrir une session. Trois secondes
> après le démarrage, «ça» s'éteint littéralement. Seul le mode «recovery» à
> faible résolution fonctionne.
>
> Détail: quand l'écran passe au noir, après un temps d'inactivité, il
> reprend toujours à sa pleine luminosité. Je dois chaque fois rediminuer la
> luminosité. À 100 pour cent, le processeur en vient à chauffer tellement
> que le ventilateur roule à fond la caisse.
>
> Depuis trois ans, j'ai installé chaque nouvelle version du noyau qui
> m'était proposée, et chaque fois, l'affichage reste mort. J'ai même
> installé le plus récent noyau, en vain.
>
> Fait curieux: j'ai testé, il y a un an, Ubuntu bionic *live* sur une clé
> USB, et l'affichage fonctionnait.
>
> Je veux juste savoir s'il est possible de préserver le noyau 4.10.
>
> Gilbert
>
> Le sam. 3 oct. 2020 à 14:28, Steve Nadeau <stevenado at gmail.com> a écrit :
>
>> Est-ce possible de savoir quel affichage n'est plus supporté?
>>
>> perso, je ne conseillerai pas d'actualiser Ubuntu à la version la plus
>> récente sans que le noyau suive.
>>
>> mieux vaut faire une copie de sécurité du système, passer à la nouvelle
>> version dans son entièreté et si ça ne va vraiment pas, revenir en arrière
>> avec la copie de sécurité et songer à une autre alternative.
>>
>> y'a t-il possibilité de débrancher le disque dur et d'en brancher un
>> autre pour ainsi installer tout le nouveau système et le tester? ce serait
>> encore plus simple.
>>
>> Steve
>> Le 2020-10-03 à 14 h 19, Gilbert Dion a écrit :
>>
>> Bonjour,
>>
>> Depuis la version du kernel qui a succédé à 4.10.0-37, l'affichage n'est
>> plus supporté. Si bien que je roule encore sur ce noyau qui date de fin
>> 2016, je crois.
>>
>> Je veux passer à la nouvelle version d'Ubuntu, mais je tiens à préserver
>> le kernel 4.10. Comment m'y prendre?
>>
>> Gilbert
>>
>> --
>> Ubuntu-quebec mailing list
>> Ubuntu-quebec at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec
>>
>
> --
> Jean Christophe ANDRÉ  @  Agence universitaire de la Francophonie
> ✉ : 3034, boul. Édouard-Montpetit, Montréal (QC)  H3T 1J7, CANADA
> / Note personnelle : merci de m'envoyer préférablement des fichiers au \
> \ format OpenDocument (.odt, .ods, .odp, …) ou autre format ouvert.    /
>
>
> --
> Jean Christophe ANDRÉ  @  Agence universitaire de la Francophonie
> ✉ : 3034, boul. Édouard-Montpetit, Montréal (QC)  H3T 1J7, CANADA
> / Note personnelle : merci de m'envoyer préférablement des fichiers au \
> \ format OpenDocument (.odt, .ods, .odp, …) ou autre format ouvert.    /
>
> --
> Ubuntu-quebec mailing list
> Ubuntu-quebec at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <https://lists.ubuntu.com/archives/ubuntu-quebec/attachments/20201004/822d4f7f/attachment-0001.html>


Plus d'informations sur la liste de diffusion Ubuntu-quebec