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

[Gilbert Dion]

Réinstallation réussie, non sans pépins (iMac et EFI, c'est délicat).
Gestion de l'affichage graphique dorénavant impeccable, sauf une chose que
je vais exposer dans un prochain envoi, à propos du pointeur de la souris
qui disparait.

@+,
g


Le dim. 4 oct. 2020 à 12:19, Gilbert Dion <gilbertdion at gmail.com> a écrit :

> 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/20201016/966f4768/attachment-0001.html>