Ca vient du plugin installonlyn qui definit le nombre de versions a garder pour chaque paquet liste dans sa configuration.

Par defaut il garde toujours deux noyaux, donc la premiere fois il en ajoute un, puis il en supprime un a chaque fois qu'il en installe un nouveau.

Si tu tiens a conserver une version particuliere d'un certain paquet, tu devrais t'orienter vers le plugin version-lock. Fais un tour sur le blog de drpixel pour savoir comment l'utiliser.
remi wrote:Voir la configuration de l'extension yum installonly qui permet de défiir le nombre de noyaux à conserver (regarde dans /etec/yum/plugin...)
Merci, je viens d'aller voir et j'avais effectivement un "tokeep = 2" que je viens de passer à 3.

Mais alors, une question se pose : si la configuration de cette extension indiquait 2, pourquoi avais-je 3 noyaux bel et bien installés (2.6.15, 2.6.17, 2.6.18) juste avant ce dernier upgrade ?
remi wrote:Mais si tu n'as pas besoin d'un noyau, pourquoi l'installer ?
Pour deux raisons : 1) parce que si je n'en ai pas besoin sur l'instant, il pourrait l'être plus tard, si le(s) soft(s) qui m'empêchent de l'utiliser deviennent compatibles au nouveau noyau. 2) pour expérimenter le fonctionnement d'outils (n'existants pas dans les dépôts connus) sous ce dernier noyau, même si je ne peux moi-même pas l'utiliser au quotidien.

EDIT :
version-lock : d'ac, surement la solution en attendant de trouver un moyen d'avoir ces satanés vmware tools sous le dernier noyau. je vais y faire un tour, merci 🙂
Merci, je viens d'aller voir et j'avais effectivement un "tokeep = 2" que je viens de passer à 3.
Et tu vas le passer a 4 au prochain ? Puis a 5 ? Puis... :-?

Pas super pratique...
Non non, je vais aller voir ces version-lock dont tu m'as parlé (j'avais pas vu ta réponse au moment ou je répondais à remi ; cf. mon EDIT précédent). Enfin, le mieux serait bien sûr d'avoir des vmware tools qui ne posent aucun pb quel que soit le noyau.
Bon, je suis sur la page de drpixel concernant version-lock : http://fedoraproject.org/extras/5/i386/repodata/repoview/yum-versionlock-0-0.6-3.fc5.html. Quelle est la différence avec la liste "à exclure" de yum ?

Aussi, est-ce que c'est approprié à mon cas, sachant que je veux garder le kernel 2.6.17 compatible aux VMware Tools et en même temps profiter des maj vers le dernier kernel à côté ? Ainsi, ,je peux travailler au quotidien sous 2.6.17 et faire mes essais sous le dernier kernel.

Autrement dit, je ne veux pas empêcher la mise à jour, mais préserver de l'effacement un kernel antérieur !
Justement, j'avais mal compris. Version-lock bloque sur une version, elle n'est donc pas mise a jour.

La liste exclude permet de ne pas installer un paquet.

L'ideal dans ton cas serait une liste exclude mais en suppression... Je crois pas que ca existe par contre...

Regarde sur le wiki du site, il y a une page sur les plugins de yum. Tu y trouveras peut etre une solution...
D'ac, là je dois aller en rendez-vous, mais je regarde plus tard et viendrai dire si j'ai trouvé. Merci bochecha
Bon, je suis allé voir le wiki du site, rubrique plugins de yum et je ne vois rien qui, comme tu l'as justement défini, permette de dresser une "liste d'exclusion à la suppression". En attendant, si jamais un upgrade m'effaçait le kernel 2.6.17 utile aux VMware tools, je garde les rpm de kernel et kernel-devel 2.6.17 afin de pouvoir les réinstaller en local par un 'rpm --force'.

Si quelqu'un a une autre idée, pas d'hésitation 😉
Moi j'ai bien une idee, mais je sais pas si elle va te plaire... :-?

Plutot que VMware, utilise qemu... :roll:
Autre solution pour conserver le kernel 2.6.17 au fil des maj du kernel :

Je suis allé voir le source (/usr/lib/yum-plugins/installonlyn.py) du plugin en charge du maintien d'un set de kernels et je remarque qu'il ne supprime jamais le kernel qui est en train de tourner :

--- extrait du source Python ----
for (n, a, e, v, r) in installed:
if (v, r) == (curv, curr): # don't remove running
continue
---

Il me suffit donc de ne mettre à jour le kernel qu'en ayant booté sous kernel 2.6.17 pour le préserver !

Bon, sinon je ne pratique pas le Python, mais il me semble que "v" est la variable à laquelle est ici assignée la partie avant le "-" d'un numéro de version de kernel et que, si tel est le cas, l'ajout d'une exlusion exprimée comme suit durant le passage en revue des kernels installés devrait le faire (et cette fois, que ce kernel 2.6.17 soit celui en cours ou non) :

if v == "2.6.17": # ne pas effacer le kernel 2.6.17-*
continue

A approfondir !

-
EDIT : scuse, j'avais pas vu ta réponse juste au-dessus, bochecha. Oui, je préfère garder VMware, simplement parce que j'ai énormément de config dessus en dehors de Fedora (entre 15 et 25 selon les moments pour faire face à des tests divers et variés ; non, j'ai pas dis avariés).
Ca marche !

J'ai fait ça aussi méthodiquement que possible. Voici le résultat (sorry pour le côté pompeux mais ça me permet un copier/coller à partir de ce que j'ai sur disque) :

-----DEBUT DE NOTES.TXT ------
26/11/2006 - installonlyn_patch (sur base installonlyn 0.90 pour Fedora Core 5)

BUT : Modification du plugin yum installonlyn, afin qu'il n'efface jamais le noyau 2.6.17 utile aux VMware Tools de VMware Workstation 5.0, sans pour autant bloquer la mise à jour vers un noyau plus récent. Et ce quelle que soit la valeur "tokeep" de "/etc/yum/pluginconf.d/installonlyn.conf" et le nombre de noyaux actuellement installés.

NB : Par extrapolation, il est possible de protéger n'importe quelle version en l'indiquant en lieu et place du literal "2.6.17" dans le source Python installonlyn.py

ORG : Idée née sur http://forums.fedora-fr.org/viewtopic.php?pid=112688 en discutant avec remi et bochecha.

TEST : Ayant actuellement un noyau 2.6.17 et 2.6.18, j'ai forcé l'installation d'un 2.6.15 (kernel et kernel-devel). J'ai ensuité désinstallé le 2.6.18 (toujours kernel et kernel-devel) pour être à deux noyaux. Puis, j'ai rebooté sur le noyau 2.6.15 et vérifié que l'option tokeep (cf. BUT) était bien à 2. J'ai lancé une mise à jour du kernel (et kernel-devel) afin de retrouver le 2.6.18. Au final, le 2.6.17 qui aurait dû être supprimé (puisqu'il ne tourne pas au moment de la mise à jour et que l'ajout du 2.6.18 fait passer le nombre de noyaux installés à 1 de trop vis à vis des 2 autorisés par tokeep) ne l'a pas été.

INSTALL : Sauvegarder /usr/lib/yum-plugins/installonlyn.*, effacer .pyc et .pyo, écraser .py avec celui fourni ici, lancer yum pour vérifier qu'il génère bien le .pyc

FUTUR POSSIBLE : ajouter et gérer une option "dontremove" à "/etc/yum/pluginconf.d/installonlyn.conf"
-----FIN DE NOTES.TXT ------

Et pour le source modifié du plugin installonlyn, il faut chercher les deux petites lignes avec "# ***ELN-PATCH" dans le commentaire :

-----DEBUT DE INSTALLONLYN 0.90 MODIFIE ------
# A plugin for yum which only leaves n 'kernel' packages installed instead
# of infinitely doing installonly
#
# Copyright 2005 Red Hat, Inc.
# Jeremy Katz <katzj@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# version 0.90

import os
from rpmUtils import miscutils
from yum.constants import *
from yum.plugins import TYPE_CORE, TYPE_INTERFACE, PluginYumExit
from yum.packages import YumInstalledPackage

requires_api_version = '2.1'
plugin_type = (TYPE_CORE,)

def sortPackages(pkg1,pkg2):
"""sort pkgtuples by evr"""
return miscutils.compareEVR((pkg1[2:]),(pkg2[2:]))

def get_running_kernel_version_release():
"""This takes the output of uname and figures out the (version, release)
tuple for the running kernel."""
ver = os.uname()[2]
for s in ("bigmem", "enterprise", "smp", "hugemem",
"guest", "hypervisor", "xen0", "xenU"):
if ver.endswith(s):
ver = ver.replace(s, "")
if ver.find("-") != -1:
(v, r) = ver.split("-", 1)
return (v, r)
return (None, None)

def config_hook(conduit):
global num_tokeep
num_tokeep = conduit.confInt('main', 'tokeep', default=2)

def postresolve_hook(conduit):
ts = conduit.getTsInfo()
rpmdb = conduit.getRpmDB()
conf = conduit.getConf()
mems = ts.getMembers()
toremove = []
for instpkg in conf.installonlypkgs:
for m in mems:
if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
and m.ts_state in ('i', 'u'):
installed = rpmdb.returnTupleByKeyword(name=m.name)
if len(installed) >= num_tokeep - 1: # since we're adding one
numleft = len(installed) - num_tokeep + 1
(curv, curr) = get_running_kernel_version_release()

installed.sort(sortPackages)
for (n, a, e, v, r) in installed:
if (v, r) == (curv, curr): # don't remove running
continue

if v == "2.6.17": # ***ELN_PATCH :
continue # don't remove the 2.6.17-* kernel's

if numleft == 0:
break
toremove.append(YumInstalledPackage(rpmdb.returnHeaderByTuple((n,a,e,v,r))[0]))
numleft -= 1

map(lambda x: ts.addErase(x), toremove)
-----FIN DE INSTALLONLYN MODIFIE ------

F'est tout ! Le mieux serait ce qui est dit en rubrique "FUTUR POSSIBLE" plus haut, mais bon, enfin, c'est réglé pour ce qui est de l'urgence 😉