Changer de kernel =3a quels autres =c3=a9l=c3=a9ments doit-on mettre =c3=a0 jour =3f
8 réponses
Pierre www.aribaut.com
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de
changer le kernel, on me parle d'autres éléments qui doivent être mis à
jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on
doit mettre à jour ?
Autres questions :
- quand je change de kernel avec ukuu, cela met à jour ces autres
éléments ou pas ?
- lors du boot avec grub ou dans le gestionnaire de mises à jour, cela
met à jour ces autres éléments ou pas ?
Sur la doc Ubuntu, ils ne parlent pas de ces autres éléments, ils disent
simplement :
https://doc.ubuntu-fr.org/kernel
"Installer et utiliser une autre version de noyau est à réserver aux
utilisateurs avertis.
Ne pas installer un noyau d'une architecture différente de celui déjà
pré-installé.
L'installation du noyau d'une autre version d'Ubuntu rend impossible
l'installation des pilotes supplémentaires, qui seront toujours
"activés" mais pas en cours d'utilisation.
La version du serveur graphique pré-installée n'est pas forcément
compatible avec d'autres noyaux. Sauf à savoir ce que vous faites,
n'installez pas un nouveau noyau sans installer la version du serveur
graphique correspondante.
Installation simple
Rendez-vous sur le site correspondant à la version de noyau voulue: soit
packages.ubuntu.com (kernels stables, par défaut de toutes les versions
d'Ubuntu), soit kernel.ubuntu.com (version de développement, appelée
"mainline", que les développeurs vous demanderont généralement de tester).
Téléchargez les 4 paquets composant le kernel voulu, généralement:
linux-headers-<version>_<version>_all.deb
linux-headers-<version>-generic_<version>_<votre_architecture>.deb
linux-image-<version>-generic_<version>_<votre_architecture>.deb
linux-image-extra-<version>-generic_<version>_<votre_architecture>.deb
(optionnel, mais généralement requis pour les tests)
Si votre système est 64bit, <votre_architecture> est amd64.
Si votre système est 32bit, <votre_architecture> est i386.modifiez le
fichier
Installez les paquets téléchargés (par exemple en double-cliquant dessus
puis installer via la Logithèque) dans l'ordre ci-dessus.
Mettre à jour le menu Grub (sudo update-grub)
Redémarrez l'ordinateur. Le menu GRUB vous permettra de choisir le
nouveau noyau."
Je suppose que quand je change le kernel via le grub ou via le
gestionnaire de mises à jour, graphiquement, ou via ukuu, cela installe
ces 4 paquets, non ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre www.aribaut.com
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ? Autres questions : - quand je change de kernel avec ukuu, cela met à jour ces autres éléments ou pas ? - lors du boot avec grub ou dans le gestionnaire de mises à jour, cela met à jour ces autres éléments ou pas ? Sur la doc Ubuntu, ils ne parlent pas de ces autres éléments, ils disent simplement : https://doc.ubuntu-fr.org/kernel "Installer et utiliser une autre version de noyau est à réserver aux utilisateurs avertis. Ne pas installer un noyau d'une architecture différente de celui déjà pré-installé.
Je reste sur la même architecture, amd64 et le même matos.
L'installation du noyau d'une autre version d'Ubuntu rend impossible l'installation des pilotes supplémentaires, qui seront toujours "activés" mais pas en cours d'utilisation.
Je n'ai pas de pilote supplémentaire, pas de pilote propriétaire, tout est donc dans le kernel au niveau pilotes, cela devrait simplifier les choses.
La version du serveur graphique pré-installée n'est pas forcément compatible avec d'autres noyaux. Sauf à savoir ce que vous faites, n'installez pas un nouveau noyau sans installer la version du serveur graphique correspondante.
Le lien en question, pour la version du serveur graphique : https://fr.wikipedia.org/wiki/X.Org Dernière version 1.20, du 10 mai 2018 Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server" je rajoute donc sudo et là j'ai : "X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu Current Operating System: Linux 4.15.0-42-generic" Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y a longtemps. Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ? Éventuellement mettre à jour à la version 1.20 ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de
changer le kernel, on me parle d'autres éléments qui doivent être mis à
jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on
doit mettre à jour ?
Autres questions :
- quand je change de kernel avec ukuu, cela met à jour ces autres
éléments ou pas ?
- lors du boot avec grub ou dans le gestionnaire de mises à jour, cela
met à jour ces autres éléments ou pas ?
Sur la doc Ubuntu, ils ne parlent pas de ces autres éléments, ils disent
simplement :
https://doc.ubuntu-fr.org/kernel
"Installer et utiliser une autre version de noyau est à réserver aux
utilisateurs avertis.
Ne pas installer un noyau d'une architecture différente de celui déjà
pré-installé.
Je reste sur la même architecture, amd64 et le même matos.
L'installation du noyau d'une autre version d'Ubuntu rend impossible
l'installation des pilotes supplémentaires, qui seront toujours
"activés" mais pas en cours d'utilisation.
Je n'ai pas de pilote supplémentaire, pas de pilote propriétaire, tout
est donc dans le kernel au niveau pilotes, cela devrait simplifier les
choses.
La version du serveur graphique pré-installée n'est pas forcément
compatible avec d'autres noyaux. Sauf à savoir ce que vous faites,
n'installez pas un nouveau noyau sans installer la version du serveur
graphique correspondante.
Le lien en question, pour la version du serveur graphique :
https://fr.wikipedia.org/wiki/X.Org
Dernière version 1.20, du 10 mai 2018
Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais
Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are
allowed to run the X server"
je rajoute donc sudo et là j'ai :
"X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu
Current Operating System: Linux 4.15.0-42-generic"
Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y
a longtemps.
Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc
m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ?
Éventuellement mettre à jour à la version 1.20 ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ? Autres questions : - quand je change de kernel avec ukuu, cela met à jour ces autres éléments ou pas ? - lors du boot avec grub ou dans le gestionnaire de mises à jour, cela met à jour ces autres éléments ou pas ? Sur la doc Ubuntu, ils ne parlent pas de ces autres éléments, ils disent simplement : https://doc.ubuntu-fr.org/kernel "Installer et utiliser une autre version de noyau est à réserver aux utilisateurs avertis. Ne pas installer un noyau d'une architecture différente de celui déjà pré-installé.
Je reste sur la même architecture, amd64 et le même matos.
L'installation du noyau d'une autre version d'Ubuntu rend impossible l'installation des pilotes supplémentaires, qui seront toujours "activés" mais pas en cours d'utilisation.
Je n'ai pas de pilote supplémentaire, pas de pilote propriétaire, tout est donc dans le kernel au niveau pilotes, cela devrait simplifier les choses.
La version du serveur graphique pré-installée n'est pas forcément compatible avec d'autres noyaux. Sauf à savoir ce que vous faites, n'installez pas un nouveau noyau sans installer la version du serveur graphique correspondante.
Le lien en question, pour la version du serveur graphique : https://fr.wikipedia.org/wiki/X.Org Dernière version 1.20, du 10 mai 2018 Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server" je rajoute donc sudo et là j'ai : "X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu Current Operating System: Linux 4.15.0-42-generic" Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y a longtemps. Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ? Éventuellement mettre à jour à la version 1.20 ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Pierre www.aribaut.com
Le 10/12/2018 à 22:33, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
La version du serveur graphique pré-installée n'est pas forcément compatible avec d'autres noyaux. Sauf à savoir ce que vous faites, n'installez pas un nouveau noyau sans installer la version du serveur graphique correspondante.
Le lien en question, pour la version du serveur graphique : https://fr.wikipedia.org/wiki/X.Org Dernière version 1.20, du 10 mai 2018 Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server" je rajoute donc sudo et là j'ai : "X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu Current Operating System: Linux 4.15.0-42-generic" Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y a longtemps. Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ? Éventuellement mettre à jour à la version 1.20 ?
Sous Xubuntu 18.10 (avant mises à jour) la même commande montre un serveur graphique Xorg en version 1.20.1, pour un kernel 4.18.0-10. Donc je suppose qu'en mettant à jour Xorg en 1.20.1, cela assure la compatibilité pour les kernel 4.18, au niveau serveur graphique. La question suivante, vous la devinez : on met comment à jour Xorg ? Facile à faire ? Si j'en crois ce topic, on dirait que c'est pas simple : https://ubuntuforums.org/showthread.php?t#95199 On lui dit : "You could wait for it to show up in 18.10 & try there (probably some point in july) Otherwise you'd need to package build the xserver-xorg-core source & replace all current 1.19 installed packages with 1.20 packages." Finalement le gars laisse tomber l'idée de mettre à jour Xorg et décide d'attendre la version 18.10 : "Will wait mc4man, thanks for answer!" -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 22:33, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
La version du serveur graphique pré-installée n'est pas forcément
compatible avec d'autres noyaux. Sauf à savoir ce que vous faites,
n'installez pas un nouveau noyau sans installer la version du serveur
graphique correspondante.
Le lien en question, pour la version du serveur graphique :
https://fr.wikipedia.org/wiki/X.Org
Dernière version 1.20, du 10 mai 2018
Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais
Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are
allowed to run the X server"
je rajoute donc sudo et là j'ai :
"X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu
Current Operating System: Linux 4.15.0-42-generic"
Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y
a longtemps.
Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc
m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ?
Éventuellement mettre à jour à la version 1.20 ?
Sous Xubuntu 18.10 (avant mises à jour) la même commande montre un
serveur graphique Xorg en version 1.20.1, pour un kernel 4.18.0-10.
Donc je suppose qu'en mettant à jour Xorg en 1.20.1, cela assure la
compatibilité pour les kernel 4.18, au niveau serveur graphique.
La question suivante, vous la devinez : on met comment à jour Xorg ?
Facile à faire ?
Si j'en crois ce topic, on dirait que c'est pas simple :
https://ubuntuforums.org/showthread.php?t#95199
On lui dit :
"You could wait for it to show up in 18.10 & try there (probably some
point in july)
Otherwise you'd need to package build the xserver-xorg-core source &
replace all current 1.19 installed packages with 1.20 packages."
Finalement le gars laisse tomber l'idée de mettre à jour Xorg et décide
d'attendre la version 18.10 :
"Will wait mc4man, thanks for answer!"
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 22:33, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 21:55, Pierre www.aribaut.com a écrit :
La version du serveur graphique pré-installée n'est pas forcément compatible avec d'autres noyaux. Sauf à savoir ce que vous faites, n'installez pas un nouveau noyau sans installer la version du serveur graphique correspondante.
Le lien en question, pour la version du serveur graphique : https://fr.wikipedia.org/wiki/X.Org Dernière version 1.20, du 10 mai 2018 Sous Linux Mint 19 (après toutes les mises à jour faites), si je fais Xorg -version il me dit "/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server" je rajoute donc sudo et là j'ai : "X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-138-generic x86_64 Ubuntu Current Operating System: Linux 4.15.0-42-generic" Je suis déjà surpris de ne pas avoir la version 1.20 qui est sortie il y a longtemps. Si par exemple, je mets le kernel 4.18 sur linux mint 19, je dois donc m'assurer que la version x.org 1.19-6 est compatible avec le kernel 4.18 ? Éventuellement mettre à jour à la version 1.20 ?
Sous Xubuntu 18.10 (avant mises à jour) la même commande montre un serveur graphique Xorg en version 1.20.1, pour un kernel 4.18.0-10. Donc je suppose qu'en mettant à jour Xorg en 1.20.1, cela assure la compatibilité pour les kernel 4.18, au niveau serveur graphique. La question suivante, vous la devinez : on met comment à jour Xorg ? Facile à faire ? Si j'en crois ce topic, on dirait que c'est pas simple : https://ubuntuforums.org/showthread.php?t#95199 On lui dit : "You could wait for it to show up in 18.10 & try there (probably some point in july) Otherwise you'd need to package build the xserver-xorg-core source & replace all current 1.19 installed packages with 1.20 packages." Finalement le gars laisse tomber l'idée de mettre à jour Xorg et décide d'attendre la version 18.10 : "Will wait mc4man, thanks for answer!" -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Marc SCHAEFER
Pierre www.aribaut.com wrote:
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui assure l'ABI entre les applications et le kernel. Parfois, certaines applications font des appels directs aux appels systèmes, mais en général ça passe par un stub de la libc. Il y a des cas rares où si la libc n'est pas en phase avec le kernel, tu peux avoir des problèmes. Mais en général la libc est assez intelligente pour s'adapter au kernel réel qui tourne. Exemple concret: j'utilise lxc (conteneur linux) et dans ce cas, la virtualisation utilise un seul kernel pour toutes les machines virtuelles. J'ai en test une stretch en conteneur dans un host jessie, avec pas mal d'applications (serveur x2go avec desktop complet + édition vidéo + traitement d'image + R), et cela fonctionne bien. J'ai toutefois eu (mais avec wheezy host et conteneur jessie) une fois un problème de syscall pas supporté. Dans ce cas j'avais préchargé simplement la nouvelle libc pour ce soft particulier et étrangement ça avait marché. D'un autre côté et dans le cas inverse qui t'occupe (p.ex. stretch avec kernel plus récent), adapter aussi la libc peut poser des problèmes car les applications ont été compilées avec.
Pierre www.aribaut.com <pedro@valencia.com.invalid> wrote:
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de
changer le kernel, on me parle d'autres éléments qui doivent être mis à
jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on
doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui
assure l'ABI entre les applications et le kernel. Parfois, certaines
applications font des appels directs aux appels systèmes, mais
en général ça passe par un stub de la libc.
Il y a des cas rares où si la libc n'est pas en phase avec le kernel,
tu peux avoir des problèmes. Mais en général la libc est assez
intelligente pour s'adapter au kernel réel qui tourne.
Exemple concret: j'utilise lxc (conteneur linux) et dans ce cas,
la virtualisation utilise un seul kernel pour toutes les machines
virtuelles.
J'ai en test une stretch en conteneur dans un host jessie, avec
pas mal d'applications (serveur x2go avec desktop complet +
édition vidéo + traitement d'image + R), et cela fonctionne bien.
J'ai toutefois eu (mais avec wheezy host et conteneur jessie)
une fois un problème de syscall pas supporté. Dans ce cas
j'avais préchargé simplement la nouvelle libc pour ce soft
particulier et étrangement ça avait marché.
D'un autre côté et dans le cas inverse qui t'occupe (p.ex.
stretch avec kernel plus récent), adapter aussi la libc
peut poser des problèmes car les applications ont été
compilées avec.
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui assure l'ABI entre les applications et le kernel. Parfois, certaines applications font des appels directs aux appels systèmes, mais en général ça passe par un stub de la libc. Il y a des cas rares où si la libc n'est pas en phase avec le kernel, tu peux avoir des problèmes. Mais en général la libc est assez intelligente pour s'adapter au kernel réel qui tourne. Exemple concret: j'utilise lxc (conteneur linux) et dans ce cas, la virtualisation utilise un seul kernel pour toutes les machines virtuelles. J'ai en test une stretch en conteneur dans un host jessie, avec pas mal d'applications (serveur x2go avec desktop complet + édition vidéo + traitement d'image + R), et cela fonctionne bien. J'ai toutefois eu (mais avec wheezy host et conteneur jessie) une fois un problème de syscall pas supporté. Dans ce cas j'avais préchargé simplement la nouvelle libc pour ce soft particulier et étrangement ça avait marché. D'un autre côté et dans le cas inverse qui t'occupe (p.ex. stretch avec kernel plus récent), adapter aussi la libc peut poser des problèmes car les applications ont été compilées avec.
Pierre www.aribaut.com
Le 11/12/2018 à 09:19, Marc SCHAEFER a écrit :
Pierre www.aribaut.com wrote:
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui assure l'ABI entre les applications et le kernel. Parfois, certaines applications font des appels directs aux appels systèmes, mais en général ça passe par un stub de la libc. Il y a des cas rares où si la libc n'est pas en phase avec le kernel, tu peux avoir des problèmes. Mais en général la libc est assez intelligente pour s'adapter au kernel réel qui tourne.
Merci, je suppose que plus la libc est vieille, plus il y a de risques de ne pas être en phase, par contre libc récente, comme tu dis, cela doit bien se passer. Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais eu de problème graphique. Là aussi je suppose que si j'avais mis un kernel récent avec une version de Xorg vieille, alors là j'augmente les risques d'incompatibilité. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 11/12/2018 à 09:19, Marc SCHAEFER a écrit :
Pierre www.aribaut.com <pedro@valencia.com.invalid> wrote:
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de
changer le kernel, on me parle d'autres éléments qui doivent être mis à
jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on
doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui
assure l'ABI entre les applications et le kernel. Parfois, certaines
applications font des appels directs aux appels systèmes, mais
en général ça passe par un stub de la libc.
Il y a des cas rares où si la libc n'est pas en phase avec le kernel,
tu peux avoir des problèmes. Mais en général la libc est assez
intelligente pour s'adapter au kernel réel qui tourne.
Merci, je suppose que plus la libc est vieille, plus il y a de risques
de ne pas être en phase, par contre libc récente, comme tu dis, cela
doit bien se passer.
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
eu de problème graphique.
Là aussi je suppose que si j'avais mis un kernel récent avec une version
de Xorg vieille, alors là j'augmente les risques d'incompatibilité.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
On me dit que lorsqu'on change de kernel, il ne faut pas se contenter de changer le kernel, on me parle d'autres éléments qui doivent être mis à jour, mais cela reste mystérieux : quels sont ces autres éléments qu'on doit mettre à jour ?
En fait, c'est la bibliothèque C standard (glibc probablement) qui assure l'ABI entre les applications et le kernel. Parfois, certaines applications font des appels directs aux appels systèmes, mais en général ça passe par un stub de la libc. Il y a des cas rares où si la libc n'est pas en phase avec le kernel, tu peux avoir des problèmes. Mais en général la libc est assez intelligente pour s'adapter au kernel réel qui tourne.
Merci, je suppose que plus la libc est vieille, plus il y a de risques de ne pas être en phase, par contre libc récente, comme tu dis, cela doit bien se passer. Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais eu de problème graphique. Là aussi je suppose que si j'avais mis un kernel récent avec une version de Xorg vieille, alors là j'augmente les risques d'incompatibilité. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Marc SCHAEFER
Pierre www.aribaut.com wrote:
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un serveur virtuel à distance), probablement quelque chose qui ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
surtout qu'il y a des drivers kernel pour X11.
Pierre www.aribaut.com <pedro@valencia.com.invalid> wrote:
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un
serveur virtuel à distance), probablement quelque chose qui
ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un serveur virtuel à distance), probablement quelque chose qui ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
surtout qu'il y a des drivers kernel pour X11.
Pierre www.aribaut.com
Le 11/12/2018 à 17:00, Marc SCHAEFER a écrit :
Pierre www.aribaut.com wrote:
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un serveur virtuel à distance), probablement quelque chose qui ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
surtout qu'il y a des drivers kernel pour X11.
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif d'avoir à jour, quelles versions au minimum, dans les "requires", exemple pour le kernel 4.18.0-13.14 : https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html Requires Name Value libc6 >= 2.14 libelf1 >= 0.142 libssl1.1 >= 1.1.0 linux-headers 4.18.0-13 -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 11/12/2018 à 17:00, Marc SCHAEFER a écrit :
Pierre www.aribaut.com <pedro@valencia.com.invalid> wrote:
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un
serveur virtuel à distance), probablement quelque chose qui
ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
surtout qu'il y a des drivers kernel pour X11.
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif
d'avoir à jour, quelles versions au minimum, dans les "requires",
exemple pour le kernel 4.18.0-13.14 :
https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html
Je me dis la même chose pour le serveur graphique Xorg (j'avais vu qu'il
mon conteneur a certes des outils X mais pas de serveur (x2go est un serveur virtuel à distance), probablement quelque chose qui ressemble à Xvfb et delta intelligents.
faut qu'il soit compatible), quand j'ai changé de kernel, je n'ai jamais
surtout qu'il y a des drivers kernel pour X11.
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif d'avoir à jour, quelles versions au minimum, dans les "requires", exemple pour le kernel 4.18.0-13.14 : https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html Requires Name Value libc6 >= 2.14 libelf1 >= 0.142 libssl1.1 >= 1.1.0 linux-headers 4.18.0-13 -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Marc SCHAEFER
Pierre www.aribaut.com wrote:
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif d'avoir à jour, quelles versions au minimum, dans les "requires", exemple pour le kernel 4.18.0-13.14 : https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html
En fait, beaucoup de distributions ont des concepts de `backports': tu restes à une version stable, mais tu ajoutes quelques packages plus récents. L'avantage est que grâce au système de pinning[1], seuls les packages absolument nécessaires seront installés, de manière cohérente. Par exemple sur backports.debian.org, on voit que pour stretch tu peux mettre un kernel 4.17. A voir si cela provoque d'autres mises à jour. Le seul risque est en cas de mise à jour d'une version stable à une autre: il se peut que les packages "trop" récents créent des problèmes de dépendances. [1] https://debian-facile.org/doc:systeme:apt:pinning
Pierre www.aribaut.com <pedro@valencia.com.invalid> wrote:
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif
d'avoir à jour, quelles versions au minimum, dans les "requires",
exemple pour le kernel 4.18.0-13.14 :
https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html
En fait, beaucoup de distributions ont des concepts de `backports':
tu restes à une version stable, mais tu ajoutes quelques packages
plus récents. L'avantage est que grâce au système de pinning[1],
seuls les packages absolument nécessaires seront installés,
de manière cohérente.
Par exemple sur backports.debian.org, on voit que pour
stretch tu peux mettre un kernel 4.17. A voir si cela provoque
d'autres mises à jour.
Le seul risque est en cas de mise à jour d'une version stable
à une autre: il se peut que les packages "trop" récents créent
des problèmes de dépendances.
Je vois que c'est en partie indiqué sur pkgs.org, ce qui est impératif d'avoir à jour, quelles versions au minimum, dans les "requires", exemple pour le kernel 4.18.0-13.14 : https://ubuntu.pkgs.org/18.10/ubuntu-proposed-main-amd64/linux-headers-4.18.0-13-generic_4.18.0-13.14_amd64.deb.html
En fait, beaucoup de distributions ont des concepts de `backports': tu restes à une version stable, mais tu ajoutes quelques packages plus récents. L'avantage est que grâce au système de pinning[1], seuls les packages absolument nécessaires seront installés, de manière cohérente. Par exemple sur backports.debian.org, on voit que pour stretch tu peux mettre un kernel 4.17. A voir si cela provoque d'autres mises à jour. Le seul risque est en cas de mise à jour d'une version stable à une autre: il se peut que les packages "trop" récents créent des problèmes de dépendances. [1] https://debian-facile.org/doc:systeme:apt:pinning
Jo Engo
Le Mon, 10 Dec 2018 22:33:45 +0100, Pierre www.aribaut.com a écrit :
Éventuellement mettre à jour à la version 1.20 ?
1. Avoir le dépôt kivabien 2. laisser faire en général «ça marche» -- -!- mode/#debian-fr [-o ptitlouis] by ptitlouis < Gniarf> DIEU EST APPARU < Gniarf> DANS TON CUL -- Gniarf in "Révélation" -- #debian-fr
Le Mon, 10 Dec 2018 22:33:45 +0100, Pierre www.aribaut.com a écrit :
Éventuellement mettre à jour à la version 1.20 ?
1. Avoir le dépôt kivabien
2. laisser faire
en général «ça marche»
--
-!- mode/#debian-fr [-o ptitlouis] by ptitlouis
< Gniarf> DIEU EST APPARU
< Gniarf> DANS TON CUL
-- Gniarf in "Révélation" --
#debian-fr
Le Mon, 10 Dec 2018 22:33:45 +0100, Pierre www.aribaut.com a écrit :
Éventuellement mettre à jour à la version 1.20 ?
1. Avoir le dépôt kivabien 2. laisser faire en général «ça marche» -- -!- mode/#debian-fr [-o ptitlouis] by ptitlouis < Gniarf> DIEU EST APPARU < Gniarf> DANS TON CUL -- Gniarf in "Révélation" -- #debian-fr
