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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec
