Via les mises à jour, un nouveau a été installé, très récemment, le 5.0.9-200. Immédiatement après, une petite vérification qui montre que seuls trois noyaux ont été préservé, le plus ancien ayant été supprimé :
1 [25-04-2019 17:48] fredrick@localhost: ~ $ ls -l /boot
total 182496
-rw-r--r--. 1 root root 202415 8 avril 18:04 config-5.0.7-200.fc29.x86_64
-rw-r--r--. 1 root root 202424 18 avril 03:39 config-5.0.8-200.fc29.x86_64
-rw-r--r--. 1 root root 202424 22 avril 03:24 config-5.0.9-200.fc29.x86_64
drwx------. 4 root root 4096 25 oct. 2018 efi
-rw-r--r--. 1 root root 188476 5 avril 22:25 elf-memtest86+-5.01
drwxr-xr-x. 2 root root 4096 25 oct. 2018 extlinux
drwx------. 5 root root 4096 25 avril 17:47 grub2
-rw-------. 1 root root 71061086 3 janv. 12:25 initramfs-0-rescue-f6e7e9d028354cf689a9dc0fbbc55521.img
-rw-------. 1 root root 22327340 14 avril 22:46 initramfs-5.0.7-200.fc29.x86_64.img
-rw-------. 1 root root 22325746 24 avril 17:18 initramfs-5.0.8-200.fc29.x86_64.img
-rw-------. 1 root root 22341115 25 avril 17:47 initramfs-5.0.9-200.fc29.x86_64.img
drwxr-xr-x. 3 root root 4096 25 oct. 2018 loader
-rw-r--r--. 1 root root 186800 5 avril 22:25 memtest86+-5.01
-rw-------. 1 root root 4169712 8 avril 18:04 System.map-5.0.7-200.fc29.x86_64
-rw-------. 1 root root 4170476 18 avril 03:39 System.map-5.0.8-200.fc29.x86_64
-rw-------. 1 root root 4170930 22 avril 03:24 System.map-5.0.9-200.fc29.x86_64
-rwxr-xr-x. 1 root root 8618168 3 janv. 12:25 vmlinuz-0-rescue-f6e7e9d028354cf689a9dc0fbbc55521
-rwxr-xr-x. 1 root root 8880328 8 avril 18:05 vmlinuz-5.0.7-200.fc29.x86_64
-rwxr-xr-x. 1 root root 8884424 18 avril 03:40 vmlinuz-5.0.8-200.fc29.x86_64
-rwxr-xr-x. 1 root root 8884424 22 avril 03:25 vmlinuz-5.0.9-200.fc29.x86_64
2 [25-04-2019 17:48] fredrick@localhost: ~ $ uname -a
Linux localhost.localdomain 5.0.8-200.fc29.x86_64 #1 SMP Thu Apr 18 01:26:26 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
3 [25-04-2019 17:48] fredrick@localhost: ~ $
Tandis qu'il est demandé de conserver 5 noyaux :
3 [25-04-2019 17:48] fredrick@localhost: ~ $ sudo dnf config-manager --dump |grep installonly
[sudo] Mot de passe de fredrick :
installonly_limit = 5
installonlypkgs = [kernel, kernel-PAE, installonlypkg(kernel), installonlypkg(kernel-module), installonlypkg(vm), multiversion(kernel)]
4 [25-04-2019 18:00] fredrick@localhost: ~ $
Donc, chez moi, ca buggue. Le problème est de pouvoir reproduire les conditions de ce bug si chez certains il n'existe pas ce problème. Déjà que je maitrise mal l'anglais (!), je ne sait pas trop quelles informations complémentaires ajouter.
Edit :
pplemoco wrote:bonjour
je suis curieux de l'issue de cette discussion ;
pour info, la limite à 3 noyaux me convient très bien sur fedora, donc je n'ai jamais cherché à la modifié;
par contre, sur mageia, les noyaux s'accumulent et il faut de temps à autre faire du ménage manuellement;
comme dnf est utilisable, j'avais essayé de configurer le "installonly" comme sur fedora avec 3 et de faire les mises à jour avec dnf (au lieu de urpmi);
et bien ça ne marche pas! (sur mageia6)
les noyaux continuent de s'accumuler au fil des mises à jour;
j'en conclue que dnf (en tout cas sur mageia) ne tient pas compte de ce paramètre;
si ça peut vous donner une idée du problème, voilà ce que j'ai constaté sur ce point;
bonne journée
Concernant dnf sous Mageia, son support n'est pas encore correct. D'une part, dnf ne tient pas compte d'un paramétrage d'une limite à 3 noyaux mais, de fait, ce n'est pas le plus important. Car si on simule une mise à jour avec dnf puis avec urpmi (urpmi --auto-update), les résultats diffèrent alors que ce devrait être les mêmes paquetages à mettre à jour. Je ne sais pas où la situation en est actuellement sous Mageia 7 Cauldron puisque cela fait 3 ou 4 mois que j'ai laché cette distribution.