Forum

les deux dernières mises à jour avec le kernel 5.1.0 ne bootent pas chez moi, malgré la mise à jour du pacquet nvidia 340.xx


quelques extraits du journal là où il y a des erreurs:

-- Logs begin at Sun 2019-03-10 18:14:02 CET, end at Thu 2019-05-02 12:28:42 CEST. --
mai 02 12:28:30 ficus4 kernel: microcode: microcode updated early to revision 0xba, date = 2010-10-03
mai 02 12:28:30 ficus4 kernel: Linux version 5.1.0-desktop-0.rc7.1.mga7 (iurt@scwx861.mageia.org) (gcc version 8.3.1 20190419 (Mageia 8.3.1-0.20190419.2.mga7)) #1 SMP Mon Apr 29 09:51:04 UTC 2019
mai 02 12:28:30 ficus4 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.1.0-desktop-0.rc7.1.mga7 root=UUID=0d976471-ee9c-41fa-a0cd-a104940e5abd ro failsafe


-- L'unité (unit) systemd-random-seed.service a terminé son démarrage, avec le résultat done.
mai 02 12:28:33 ficus4 systemd-udevd[580]: Specified user 'tss' unknown
mai 02 12:28:33 ficus4 systemd-udevd[580]: Specified group 'tss' unknown
mai 02 12:28:34 ficus4 systemd[1]: Started Flush Journal to Persistent Storage.
-- Subject: L'unité (unit) systemd-journal-flush.service a terminé son démarrage
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Là il y a cet user inconnu ? mais c'est pas ça le problème ?

mai 02 12:28:40 ficus4 cupsd[738]: Unable to communicate with avahi-daemon: Daemon not running
mai 02 12:28:40 ficus4 systemd[1]: Started CUPS Scheduler.
-- Subject: L'unité (unit) cups.service a terminé son démarrage
-- Defined-By: systemd


mai 02 12:28:40 ficus4 udev-configure-printer[739]: task-printing-server-2018-5.mga7
mai 02 12:28:41 ficus4 udev-configure-printer[739]: ● cups.service - CUPS Scheduler
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Active: active (running) since Thu 2019-05-02 12:28:40 CEST; 567ms ago
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Docs: man:cupsd(8)
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Main PID: 738 (cupsd)
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Status: "Scheduler is running..."
mai 02 12:28:41 ficus4 udev-configure-printer[739]: Memory: 8.4M
mai 02 12:28:41 ficus4 udev-configure-printer[739]: CGroup: /system.slice/cups.service
mai 02 12:28:41 ficus4 udev-configure-printer[739]: └─738 /usr/sbin/cupsd -l
mai 02 12:28:41 ficus4 udev-configure-printer[739]: mai 02 12:28:39 ficus4 systemd[1]: Starting CUPS Scheduler...
mai 02 12:28:41 ficus4 udev-configure-printer[739]: mai 02 12:28:40 ficus4 cupsd[738]: Unable to communicate with avahi-daemon: Daemon not running
mai 02 12:28:41 ficus4 udev-configure-printer[739]: mai 02 12:28:40 ficus4 systemd[1]: Started CUPS Scheduler.
mai 02 12:28:41 ficus4 udev-configure-printer[739]: add usb-001-002
mai 02 12:28:42 ficus4 udev-configure-printer[739]: device devpath is /devices/pci0000:00/0000:00:04.1/usb1/1-1
mai 02 12:28:42 ficus4 udev-configure-printer[739]: MFG:Canon MDL:MG3500 series SERN:- serial:79BF70
mai 02 12:28:42 ficus4 udev-configure-printer[739]: CheckAndInstallDrivers()
mai 02 12:28:42 ficus4 udev-configure-printer[739]: dbus[739]: arguments to dbus_connection_send_with_reply() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 3407.
mai 02 12:28:42 ficus4 udev-configure-printer[739]: This is normally a bug in some application using the D-Bus library.
mai 02 12:28:42 ficus4 udev-configure-printer[739]: D-Bus not built with -rdynamic so unable to print a backtrace
mai 02 12:28:42 ficus4 kernel: kauditd_printk_skb: 19 callbacks suppressed
mai 02 12:28:42 ficus4 kernel: audit: type=1701 audit(1556792922.051:46): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=739 comm="udev-configure-" exe="/usr/lib/udev/udev-configure-printer" sig=6 res=1
mai 02 12:28:42 ficus4 audit[739]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=739 comm="udev-configure-" exe="/usr/lib/udev/udev-configure-printer" sig=6 res=1
mai 02 12:28:42 ficus4 systemd[1]: configure-printer@usb-001-002.service: Main process exited, code=dumped, status=6/ABRT
-- Subject: Unit process exited
-- Defined-By: systemd
:
le problème c'est le daemon avahi pas lancé, pourquoi ?

Bonjour,
Est-ce que tu as l'option nokmsboot sur la ligne d'options du kernel, dans grub2 ?
Je crois que c'est nécessaire pour le pilote nvidia.
avahi est connu aussi sous le nom de microDNS, pour trouver les ordinateurs du réseau local par leur noms, plutôt que par les adresses IP. C'est utile, pratique, mais pas indispensable ni bloquant.

Et je dis ça, je n'ai pas le problème, voir ce que donne

il y a bien l'option "nodkmsboot" au démarrage

pour ce qui concerne le daemon avahi avec le noyau 5.0.8 actuel, tout est normal

[marcel@ficus4 ~]$ systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendo>
Active: active (running) since Thu 2019-05-02 19:39:24 CEST; 10min ago
Main PID: 943 (avahi-daemon)
Status: "avahi-daemon 0.7 starting up."
Memory: 1.5M
CGroup: /system.slice/avahi-daemon.service
├─ 943 avahi-daemon: running [ficus4.local]
└─1015 avahi-daemon: chroot helper
je vais rebooter avec celui qui marche pas pour voir ce que ça donne

car, il n'est pas complètement bloqué; en faisant <ctrl> <Alt> F2 j'ai une invite de login
mais je sais pas quoi en faire, à part "reboot", ça m'évite d'utiliser le bouton de reset de l'ordi;

edit
avec le 5.1.0 qui ne boote pas en graphique, et en ouvrant une autre tty, le daemon-avahi est ok;
j'ai pu lancer "nmon" et constater que ça tourne, 900mo de ram utilisé, et activité cpu systeme par bouffée à 25% sur les 4 cœurs, pas d'accès disque ni de trafic sur le réseau;
si je reviens sur la tty1, rien ne se passe, écran noir;
avant le détour par tty2n j'avais la souris active(le curseur); après, plus rien;
voilà où ça en est avec ce kernel

Édité par marc-andré Le 02/05/2019 à 20h39

Bonjour marc-andre,

Je serais vraiment sadique, si, au milieu de tes problèmes, je venais te dire :
"Ben, fais undo dans l'historique de dnfdragora !"

Tu te retrouves exactement dans la situation que j'abordais sur l'autre fil, et que tu ne comprenais pas.
=> Si tu n'as pas de graphique lors d'un reboot avec un nouveau kernel, il te faut impérativement la commande adequat de "dnf" en TTY pour faire ton "undo" !

Au passage, tu devrais pouvoir la trouver sur le web...

Et puis tu peux toujours éditer ton grub2 au départ, et changer les Nº de kernel nouveaux pour les précédents qui marchaient, et ça bootera en graphique => ce qui te donnera accès au ccm pour les désinstaller ou à ton cher dnfdragora "undo".

Merci

Il n'y a aucun soucis
avec mon grub2 non bricolé, je choisi options avancées, puis le noyau qui boote et tout va bien

pour le undo de dnf, pas besoin du web, "man" est notre ami
History Command
The history command allows the user to view what has happened in past
transactions and act according to this information (assuming the his‐
tory_record configuration option is set).

dnf history [list] [<spec>...]
The default history action is listing information about given
transactions in a table. Each <spec> can be either a <transac‐
tion-spec>, which specifies a transaction directly, or a <trans‐
action-spec>..<transaction-spec>, which specifies a range of
transactions, or a <package-name-spec>, which specifies a trans‐
action by a package which it manipulated. When no transaction is
specified, list all known transactions.

dnf history info [<spec>...]
Describe the given transactions. The meaning of <spec> is the
same as in the History List Command. When no transaction is
specified, describe what happened during the latest transaction.

dnf history redo <transaction-spec>|<package-name-spec>
Repeat the specified transaction. Uses the last transaction
(with the highest ID) if more than one transaction for given
<package-name-spec> is found. If it is not possible to redo some
operations due to the current state of RPMDB, it will not redo
the transaction.

dnf history rollback <transaction-spec>|<package-name-spec>
Undo all transactions performed after the specified transaction.
Uses the last transaction (with the highest ID) if more than one
transaction for given <package-name-spec> is found. If it is
not possible to undo some transactions due to the current state
of RPMDB, it will not undo any transaction.

dnf history undo <transaction-spec>|<package-name-spec>
Perform the opposite operation to all operations performed in
the specified transaction. Uses the last transaction (with the
highest ID) if more than one transaction for given <pack‐
age-name-spec> is found. If it is not possible to undo some op‐
erations due to the current state of RPMDB, it will not undo the
transaction.

mais pour que ça marche, faut avoir fait la transaction avec dnf;
sur mageia7, je l'avais pas encore fait jusqu'à ces jours ci et j'ai utilisé urpmi pour faire la mise à jour qui ne marche pas avec le 5.1.0;
donc pas de "undo" possible avec dnf;

voilà, c'est fait, j'ai supprimé par le ccm les noyaux 5.1.0, et régénéré le grub, et tout va bien;
ça boote direct avec le 5.0.8 qui marche bien

désormais, dnf étant configuré, je vais faire toute les mises à jour avec;
je pourrais ainsi tester le "undo" si nécessaire;

hope you enjoy!

Édité par marc-andré Le 03/05/2019 à 03h24

Bonjour marc-andre

I do ...I do.
...I do it for you...

Avec mon grub2 bricolé je n'aurais pas eu plus de mal

Content que tu t'en sois sorti sans casse.
A+

nouvelle bizarrerie avec ce noyau; 5.1.0;

comme je l'ai désinstallé, je me suis dis que j'allais tenter une nouvelle mise à jour avec dnf;
(étant le seul apparemment à avoir le problème, je soupçonne un soucis de réseau lors de l'installation; en ce moment, le réseau semble perturbé)
Ok la mise à jour a eu lieu ...
sauf qu'il n'y en a aucune trace dans /boot;

ça c'est mon /boot
-rw------- 1 root root 13043341 mars 10 18:32 initrd-4.20.9-desktop-1.mga7.img
-rw------- 1 root root 13200099 mars 10 19:36 initrd-5.0.1-desktop-1.mga7.img
-rw------- 1 root root 13206126 mars 20 21:03 initrd-5.0.3-desktop-1.mga7.img
-rw------- 1 root root 13210922 mars 26 13:32 initrd-5.0.4-desktop-1.mga7.img
-rw------- 1 root root 13208982 mars 29 15:40 initrd-5.0.5-desktop-1.mga7.img
-rw------- 1 root root 13207220 avril 2 16:17 initrd-5.0.5-desktop-2.mga7.img
-rw------- 1 root root 13208935 avril 12 11:26 initrd-5.0.7-desktop-4.mga7.img
-rw------- 1 root root 13259463 avril 19 13:04 initrd-5.0.8-desktop-1.mga7.img
-rw-r--r-- 1 root root 184632 févr. 15 09:17 symvers-4.20.9-desktop-1.mga7.xz
-rw-r--r-- 1 root root 185568 mars 10 12:36 symvers-5.0.1-desktop-1.mga7.xz
-rw-r--r-- 1 root root 185568 mars 19 15:23 symvers-5.0.3-desktop-1.mga7.xz
-rw-r--r-- 1 root root 185576 mars 24 01:02 symvers-5.0.4-desktop-1.mga7.xz
-rw-r--r-- 1 root root 185608 mars 27 22:48 symvers-5.0.5-desktop-1.mga7.xz
-rw-r--r-- 1 root root 185608 mars 29 21:48 symvers-5.0.5-desktop-2.mga7.xz
-rw-r--r-- 1 root root 185676 avril 10 21:07 symvers-5.0.7-desktop-4.mga7.xz
-rw-r--r-- 1 root root 185668 avril 18 21:14 symvers-5.0.8-desktop-1.mga7.xz
-rw-r--r-- 1 root root 3847366 févr. 15 09:17 System.map-4.20.9-desktop-1.mga7
-rw-r--r-- 1 root root 3870034 mars 10 12:36 System.map-5.0.1-desktop-1.mga7
-rw-r--r-- 1 root root 3870293 mars 19 15:23 System.map-5.0.3-desktop-1.mga7
-rw-r--r-- 1 root root 3870839 mars 24 01:02 System.map-5.0.4-desktop-1.mga7
-rw-r--r-- 1 root root 3870895 mars 27 22:48 System.map-5.0.5-desktop-1.mga7
-rw-r--r-- 1 root root 3873018 mars 29 21:48 System.map-5.0.5-desktop-2.mga7
-rw-r--r-- 1 root root 3873409 avril 10 21:07 System.map-5.0.7-desktop-4.mga7
-rw-r--r-- 1 root root 3874495 avril 18 21:14 System.map-5.0.8-desktop-1.mga7
-rw-r--r-- 1 root root 6117248 févr. 15 09:17 vmlinuz-4.20.9-desktop-1.mga7
-rw-r--r-- 1 root root 6154112 mars 10 12:36 vmlinuz-5.0.1-desktop-1.mga7
-rw-r--r-- 1 root root 6154112 mars 19 15:23 vmlinuz-5.0.3-desktop-1.mga7
-rw-r--r-- 1 root root 6154112 mars 24 01:02 vmlinuz-5.0.4-desktop-1.mga7
-rw-r--r-- 1 root root 6154112 mars 27 22:48 vmlinuz-5.0.5-desktop-1.mga7
-rw-r--r-- 1 root root 6158208 mars 29 21:48 vmlinuz-5.0.5-desktop-2.mga7
-rw-r--r-- 1 root root 6158208 avril 10 21:07 vmlinuz-5.0.7-desktop-4.mga7
-rw-r--r-- 1 root root 6158208 avril 18 21:14 vmlinuz-5.0.8-desktop-1.mga7

et ensuite, les transactions dnf d'aujourd'hui

[root@ficus4 ~]# dnf history list
ID | Ligne de commande | Date et heure | Action(s) | Modifié
-------------------------------------------------------------------------------
5 | | 2019-05-03 16:41 | Install | 18
4 | upgrade | 2019-05-03 15:58 | I, U | 11
3 | upgrade | 2019-05-03 02:57 | I, O, U | 11 <
2 | upgrade | 2019-05-01 17:12 | Upgrade | 25 ><
1 | | 2019-04-29 22:30 | Upgrade | 1 >
[root@ficus4 ~]# dnf history info 4
Identifiant de transaction : 4
Temps de début : ven. 03 mai 2019 15:58:00 CEST
Début de RPMDB : 2684:0cdba0f4e059093c7c0a9191f78118deb01b6a0c
Temps de fin : ven. 03 mai 2019 15:59:57 CEST (117 secondes)
Fin de RPMDB : 2685:d6349927517e9d2cde1ee469d5f96e1a154c2ec1
Utilisateur : BRUN Marc-André <marcel>
Code de retour : Réussi
Releasever : 7
Ligne de commande : upgrade
Paquets modifiés :
Installer kernel-desktop-devel-5.1.0-0.rc7.2.mga7-1-1.mga7.x86_64 @mageia-x86_64
Upgrade iwlwifi-firmware-20190503-1.mga7.nonfree.noarch @mageia-x86_64-nonfree
Upgraded iwlwifi-firmware-20190424-1.mga7.nonfree.noarch @@System
Upgrade kernel-firmware-nonfree-20190503-1.mga7.nonfree.noarch @mageia-x86_64-nonfree
Upgraded kernel-firmware-nonfree-20190424-1.mga7.nonfree.noarch @@System
Upgrade radeon-firmware-20190503-1.mga7.nonfree.noarch @mageia-x86_64-nonfree
Upgraded radeon-firmware-20190422-1.mga7.nonfree.noarch @@System
Upgrade ralink-firmware-20190503-1.mga7.nonfree.noarch @mageia-x86_64-nonfree
Upgraded ralink-firmware-20190424-1.mga7.nonfree.noarch @@System
Upgrade rtlwifi-firmware-20190503-1.mga7.nonfree.noarch @mageia-x86_64-nonfree
Upgraded rtlwifi-firmware-20190424-1.mga7.nonfree.noarch @@System
Upgrade cpupower-5.1.0-0.rc7.2.mga7.x86_64 @mageia-x86_64
Upgraded cpupower-5.1.0-0.rc7.1.mga7.x86_64 @@System
Upgrade glibc-6:2.29-8.mga7.x86_64 @mageia-x86_64
Upgraded glibc-6:2.29-7.mga7.x86_64 @@System
Upgrade glibc-devel-6:2.29-8.mga7.x86_64 @mageia-x86_64
Upgraded glibc-devel-6:2.29-7.mga7.x86_64 @@System
Upgrade kernel-desktop-devel-latest-5.1.0-0.rc7.2.mga7.x86_64 @mageia-x86_64
Upgraded kernel-desktop-devel-latest-5.1.0-0.rc7.1.mga7.x86_64 @@System
Upgrade kernel-userspace-headers-5.1.0-0.rc7.2.mga7.x86_64 @mageia-x86_64
Upgraded kernel-userspace-headers-5.1.0-0.rc7.1.mga7.x86_64 @@System

voilà, ce kernel est installé, d'ailleurs, j'ai essayé avec le ccm, il me dit que tout est à jour !
mais il n'est pas dans /boot, ni dans le /boot/grub2/grub.cfg

Marc-André,
As-tu vérifié la place disponible dans /boot. Si c'est une partition à part, elle pourrait être saturée. Tu sembles avoir déjà 8 noyaux anciens. Je te recommande d'en purger.

salut et merci pour la réponse;
non, /boot n'est pas sur une partition séparée;

Bonjour marc-andre (c'est re-moi, je ne te lâche plus )

Je sais que ça ne te servira peut-être pas, mais depuis le passage aux kernels 5.1.x-rc, chez moi, la compilation automatique de mon driver wifi par DKMS ne se fait plus. Pourtant, en la lançant à posteriori, elle s'exécute parfaitement. J'ai donc pensé que ça pourrait provenir d'un problème noyau/DKMS ...peut-être même avec "initrd"...
Est-ce que ton Nvidia se charge de cette façon (DKMS) ?
Si oui, et si tu juges que c'est une piste possible, tu peux peut-être envisager de le désinstaller et de relancer avec "Nouveau" (supprimer l'option "nokmsboot" dans ce cas) pour voir...

A+

salut et merci pour l'idée;
le problème, c'est que bien qu'il soit installé, le noyau 5.1.0 n'est pas dans le menu de grub, donc je peux même pas essayer;
je vais attendre le prochain noyau pour voir comment ça se passe;
j'avais essayé de mettre "nouveau" dans /etc/x11/xorg.conf, mais ça n'avait pas marché; (je crois que j'avais laissé l'option "nokmsboot");
ce "nouveau" me trouble un peu, car en général, le paramètres dans les fichiers de conf sont en anglais !

Des pistes de réflexion en vrac :

1. Le kernel n'apparaît pas dans le gub2.
- As-tu 1 seul "grub2" ou un second en plus avec Fedora ? => S'assurer que le kernel en question ne s'est pas logé éventuellement sur le second grub. => Simple coup d'oeil avec Dophin sous ton kernel qui démarre.
- Car comme tu as 2 disques, peut-être as-tu un second grub sur l'autre disque.
- Peut-être même que ton grub est celui de Fedora sans que tu t'en doutes. Les modifs de Mageia n'y apparaissent pas, c'est normal.
- Dans le bios, tu peux modifier la priorité des disques au lancement, et faire apparaître cet éventuel second grub au boot, au lieu de l'autre.

2. La graphique ne démarre pas.
- Dans ton message du 2/5 à 19H57, tu as pu lancer ce kernel, puisque tu as achoppé sur la graphique et utilisé les TTY...
=> Comment l'as-tu lancé s'il n'apparaît pas dans le grub ?
- Si tu désinstalles "Nvidia", tu peux carrément effacer le /etc/X11/xorg.conf. => Ce fichier est créé par l'installation de nvidia et ne sert pas avec Nouveau ! => Si tu ré-installes Nvidia, il se re-créera automatiquement...
- Nouveau est inséré dans le kernel, il n'y a pas de fichier de conf ! (ni anglais ni autre).
- Pour lancer avec Nouveau, il faut juste désinstaller nvidia (=> possible en TTY root => urpme nvidia -a), et enlever l'option "nokmsboot" au boot.
- Nvidia 340 ne sert que pour des cartes graphiques déjà ancienne. Assure-toi quel driver correspond bien à ta carte.
- Tes précédents kernels fonctionnaient-ils avec Nvidia 340 ?

Bonne soirée

oui, c'est un peu confus car assez inédit comme situation;
1 j'ai 1 MBR sur chaque disque; mais ça ne sert qu'en cas de panne je pense, les deux disques sont bootables indépendamment; mais c'est juste un "jump" sur le dossier /boot de la partition (de l'OS) qui a généré ce MBR; (celui avec lequel on a lancé la commande "grub2-install /dev/sda ou sdb");
je ne sais plus pour quelles raisons, je n'utilise pas le grub de fedora (depuis peut être l'installation de l'opensuse en btrfs non reconnue);en général c'est celui de mageia, la dernière mise à jour (qui peut être celle sur sda1, sda3 ou sdb4); parfois, ça peut être le grub de l'opensuse qui marche pareil;
pour ne pas avoir le grub de fedora, je n'utilise jamais "gnome software" pour les mises à jour, mais directement dnf en terminal; sans jamais faire sur fedora ni grub2-mkconfig ni grub2-install;
Dans le BIOS, je peux manuellement décider après F12 au bon moment de démarrer sur sdb ou sur le dvd; mais je ne peux pas le configurer définitivement, donc, en général, ça démarre toujours avec le MBR de sda, même si je boote un OS qui est sur sdb;
J'ai jamais cherché à mettre à jour le BIOS, car il n'y a aucune raison à chercher les ennuis puisque ça marche ainsi!

2 C'est ça le côté mystérieux de cette histoire; j'ai eut 2 versions de kernel 5.1.0, une avant correctif du driver nvidia, une après; aucune des deux n'a fonctionné; pour ne pas à avoir à passer par le menu des "options avancées", je les ai supprimés; du coup ça marche normalement avec le 5.0.8;
puis, le lendemain, je me suis vu proposer des nouvelles mises à jour, que j'ai faite et il y avait un kernel 5.1.0;
mais celui là, il n'apparaît pas dans le menu de grub, il n'est pas dans /boot ni dans le /boot/grub2/grub.cfg;
bien qu'il soit installé;
tout à l'heure, il y a eut une nouvelle mise à jour, sans noyaux;
je l'ai faite; je n'ai pas rebooté, mais il n'y a aucune raison que le noyau ait apparu; enfin je verrai bien!

3 depuis le début avec mageia5, j'ai ce driver nvidia340 qui marche; c'est une machine de 2008;
d'après le rapport de bug sur l'autre post, de toute façon, il semblerait qu'il ne soit maintenu plus très longtemps;
faudra donc tôt ou tard s'en passer et utiliser le pilote libre;
pour l'instant, j'attends un nouveau kernel, pour voir s'il apparaît; tant que ça reste coincé sur le 5.0.8, je ne fais rien;

merci pour l'éclaircissement sur nvidia;

bon aucune amélioration de ce problème;
je fait toutes les mises à jour, avec dnfdragora, et je suis toujours bloqué sur le 5.0.8;

[root@ficus4 ~]# dnf history info 12
Identifiant de transaction : 12
Temps de début : mar. 07 mai 2019 09:27:40 CEST
Début de RPMDB : 2715:570b4d47088b21235157eeb14f0b235280c30395
Temps de fin : mar. 07 mai 2019 09:29:58 CEST (138 secondes)
Fin de RPMDB : 2716:b0c08edf26ca689a42a6c965d9acd8fb726a4760
Utilisateur : Système <unset>
Code de retour : Réussi
Releasever : 7
Ligne de commande :
Paquets modifiés :
Installer kernel-desktop-devel-5.1.0-1.mga7-1-1.mga7.x86_64 @mageia-x86_64
Upgrade cpupower-5.1.0-1.mga7.x86_64 @mageia-x86_64
Upgraded cpupower-5.1.0-0.rc7.2.mga7.x86_64 @@System
Upgrade epiphany-3.32.2-1.mga7.x86_64 @mageia-x86_64
Upgraded epiphany-3.32.1.2-2.mga7.x86_64 @@System
Upgrade gnome-contacts-3.32.1-1.mga7.x86_64 @mageia-x86_64
Upgraded gnome-contacts-3.32-2.mga7.x86_64 @@System
Upgrade gtk+2.0-2.24.32-5.mga7.x86_64 @mageia-x86_64
Upgraded gtk+2.0-2.24.32-4.mga7.x86_64 @@System
Upgrade kernel-desktop-devel-latest-5.1.0-1.mga7.x86_64 @mageia-x86_64
Upgraded kernel-desktop-devel-latest-5.1.0-0.rc7.2.mga7.x86_64 @@System
Upgrade lib64gtk+-x11-2.0_0-2.24.32-5.mga7.x86_64 @mageia-x86_64
Upgraded lib64gtk+-x11-2.0_0-2.24.32-4.mga7.x86_64 @@System
Upgrade lib64gtk+2.0_0-2.24.32-5.mga7.x86_64 @mageia-x86_64
Upgraded lib64gtk+2.0_0-2.24.32-4.mga7.x86_64 @@System
Upgrade lib64gtk-gir2.0-2.24.32-5.mga7.x86_64 @mageia-x86_64
Upgraded lib64gtk-gir2.0-2.24.32-4.mga7.x86_64 @@System
Upgrade lib64v4l-wrappers-1.16.6-1.mga7.x86_64 @mageia-x86_64
Upgraded lib64v4l-wrappers-1.16.5-4.mga7.x86_64 @@System
Upgrade lib64v4l0-1.16.6-1.mga7.x86_64 @mageia-x86_64
Upgraded lib64v4l0-1.16.5-4.mga7.x86_64 @@System
Upgrade simple-scan-3.32.2.1-1.mga7.x86_64 @mageia-x86_64
Upgraded simple-scan-3.32.2-2.mga7.x86_64 @@System
Upgrade v4l-utils-1.16.6-1.mga7.x86_64 @mageia-x86_64
Upgraded v4l-utils-1.16.5-4.mga7.x86_64 @@System
[root@ficus4 ~]#

il y a bien eu une installation d'un kernel 5.1.0, mais toujours aucune trace dans /boot;
et bien sûr, au menu de grub, la 5.0.8 est la dernière proposée !

donc, quand un noyau est installé avec dnfdragora, est ce qu'il y a d'autre commandes à faire pour que ça soit pris en compte, et que le dossier /boot soit populés avec les fichiers "adhoc" et que le fichier /grub2/grub.cfg soit mis à jour !