<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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 <u>plus</u> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Je retiens de tout ça que le système <i>live</i> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Je viens de retester la version <i>live</i> 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!</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:"trebuchet ms",sans-serif;font-size:large;color:rgb(102,51,102)">@+,</span></div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="font-family:"trebuchet ms",sans-serif;font-size:large;color:rgb(102,51,102)">g</span></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 4 oct. 2020 à 00:02, Jean Christophe André <<a href="mailto:jean-christophe.andre@auf.org" target="_blank">jean-christophe.andre@auf.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Ah, désolé, j'ai oublié d'ajouter un « petit bout » sur ta vraie
question… :-P</p>
<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…</p>
<p>1- la sécurité</p>
<p>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.<br>
</p>
<p>2- la stabilité</p>
<p>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.<br>
</p>
<p>3- la performance</p>
<p>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.</p>
<p>4- la compatibilité</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>J.C.<br>
</p>
<p><br>
</p>
<div>Le 20-10-03 à 21 h 23, Jean Christophe
André a écrit :<br>
</div>
<blockquote type="cite">
<p> Bonjour à toutes et à tous,</p>
<p>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. :-)<br>
</p>
<p> 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.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Bonne chasse ! J.C.<br>
</p>
<p><br>
</p>
<div>Le 20-10-03 à 15 h 46, Gilbert Dion a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">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.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">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.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">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. </div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Fait curieux: j'ai
testé, il y a un an, Ubuntu bionic <i>live</i> sur une clé
USB, et l'affichage fonctionnait.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Je veux juste savoir
s'il est possible de préserver le noyau 4.10.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<font face="verdana, sans-serif">Gilbert</font></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le sam. 3 oct. 2020 à 14:28,
Steve Nadeau <<a href="mailto:stevenado@gmail.com" target="_blank">stevenado@gmail.com</a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Est-ce possible de savoir quel affichage n'est plus
supporté? <br>
</p>
<p>perso, je ne conseillerai pas d'actualiser Ubuntu à la
version la plus récente sans que le noyau suive.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Steve<br>
</p>
<div>Le 2020-10-03 à 14 h 19, Gilbert Dion a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">Bonjour,</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">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.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Je veux
passer à la nouvelle version d'Ubuntu, mais je tiens
à préserver le kernel 4.10. Comment m'y prendre?</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Gilbert</div>
</div>
<br>
<fieldset></fieldset>
</blockquote>
</div>
-- <br>
Ubuntu-quebec mailing list<br>
<a href="mailto:Ubuntu-quebec@lists.ubuntu.com" target="_blank">Ubuntu-quebec@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
</blockquote>
<pre cols="72">--
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. /
</pre>
<br>
<fieldset></fieldset>
</blockquote>
<pre cols="72">--
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. /
</pre>
</div>
-- <br>
Ubuntu-quebec mailing list<br>
<a href="mailto:Ubuntu-quebec@lists.ubuntu.com" target="_blank">Ubuntu-quebec@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec</a><br>
</blockquote></div>