Bonjour,

Je viens de rentrer 3 semaines d’une hospitalisation, du coup je procède à une MàJ du noyau 6.13.9 comme indiqué dans la barre des tâches en bas, et je ne parviens pas à redémarrer, j’ai un beau kernel panic, avec un :

Unable to mount root fs on unknown-block(0,0)

Je soupçonne un souci avec nVidia que j’avais tenté d’installer, puis nettoyé entretemps.

En démarrant sur le noyau précédent 6.13.6, on le constate dans les entrées :

root@jbeziat:~# cat /boot/loader/entries/* 
title Fedora Linux (0-rescue-a64f8a4c47ff40c09c590376d7a42c5a) 39 (KDE Plasma) 
version 0-rescue-a64f8a4c47ff40c09c590376d7a42c5a 
linux /vmlinuz-0-rescue-a64f8a4c47ff40c09c590376d7a42c5a 
initrd /initramfs-0-rescue-a64f8a4c47ff40c09c590376d7a42c5a.img 
options root=UUID=3d8e8625-4807-4826-b324-8d3c4ed42bd3 ro rootflags=subvol=root rhgb quiet nvidia-drm.modeset=1 
grub_users $grub_users 
grub_arg --unrestricted 
grub_class fedora 

title Fedora Linux (6.13.5-200.fc41.x86_64) 41 (KDE Plasma) 
version 6.13.5-200.fc41.x86_64 
linux /vmlinuz-6.13.5-200.fc41.x86_64 
initrd /initramfs-6.13.5-200.fc41.x86_64.img $tuned_initrd 
options root=UUID=3d8e8625-4807-4826-b324-8d3c4ed42bd3 ro rootflags=subvol=root rhgb quiet nvidia-drm.modeset=1 $tuned_params 
grub_users $grub_users 
grub_arg --unrestricted 
grub_class fedora 

title Fedora Linux (6.13.6-200.fc41.x86_64) 41 (KDE Plasma) 
version 6.13.6-200.fc41.x86_64 
linux /vmlinuz-6.13.6-200.fc41.x86_64 
initrd /initramfs-6.13.6-200.fc41.x86_64.img $tuned_initrd 
options root=UUID=3d8e8625-4807-4826-b324-8d3c4ed42bd3 ro rootflags=subvol=root rhgb quiet nvidia-drm.modeset=1 $tuned_params 
grub_users $grub_users 
grub_arg --unrestricted 
grub_class fedora 

title Fedora Linux (6.13.9-200.fc41.x86_64) 41 (KDE Plasma) 
version 6.13.9-200.fc41.x86_64 
linux /vmlinuz-6.13.9-200.fc41.x86_64 
initrd /initramfs-6.13.9-200.fc41.x86_64.img 
options root=UUID=3d8e8625-4807-4826-b324-8d3c4ed42bd3 ro rootflags=subvol=root rhgb quiet nvidia-drm.modeset=1 
grub_users $grub_users 
grub_arg --unrestricted 
grub_class fedora

Toujours sur le noyau précédent 6.13.6, avec la commande :

root@jbeziat:~# lspci 
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 05) 
00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller 
00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1 
00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode] 
00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 (rev f0) 
00:1c.5 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #6 (rev f0) 
00:1c.7 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #8 (rev f0) 
00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9 (rev f0) 
00:1f.0 ISA bridge: Intel Corporation 200 Series PCH LPC Controller (B250) 
00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset Family Power Management Controller 
00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio 
00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus Controller 
01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1) 
01:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1) 
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15) 
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)

Il faut que je supprime le noyau défectueux 6.13.9 ?

Puis faire

dnf upgrade --refresh ?

Edit Nicosss : Correction balises Markdown -> Voir FAQ

    paradise Le pilote Nvidia propriétaire a été installé puis désinstallé comment ? Est-ce que d’autres modifications ont été apportées ?

    Tu peux démarrer sans problème avec les autres noyaux ?

    Si tu désinstalles ce noyau alors il te sera reproposé à la prochaine mise à jour, sauf nouveau noyau disponible.

      Bonjour,

      Comme je n’arrivais pas à faire fonctionner le pilote nVidia, et que finalement je n’en ai pas spécialement besoin, j’avais décidé de tout virer, et j’ai procédé comme suit :

      # dnf remove xorg-x11-drv-nvidia* && sudo dnf remove akmod-nvidia*

      # dnf remove xorg-x11-drv-nvidia-3:565.77-3.fc41.x86_64

      # dnf remove "nvidia-settings" "nvidia-xconfig" "*kmod-nvidia" "xorg*nvidia*"

      Je redémarre sans souci avec le noyau précédent 6.13.6, le souci est avec le dernier 6.13.9.

      La procédure serait donc, à partir du noyau 6.13.6 :

      dnf remove kernel*6.13.9*

      Puis :

      dnf upgrade --refresh

      ???

        paradise Donc le pilote utilisé provenait de RPM Fusion.

        Tu dois aussi retirer l’option nvidia-drm.modeset=1 de ton fichier /etc/default/grub . Il s’agit d’un bug qui n’est pas encore corrigé, voir https://doc.fedora-fr.org/wiki/Carte_graphique_NVIDIA_:_installation_des_pilotes_propri%C3%A9taires#D%C3%A9sinstaller_le_pilote_propri%C3%A9taire_RPM_Fusion .

        Ensuite tu dois regénérer le Grub
        # grub2-mkconfig -o /boot/grub2/grub.cfg

        Puis redémarrer et il est possible que le noyau 6.13.9 fonctionne correctement.

          Bon, j’ai retiré l’option nvidia-drm.modeset=1.

          Mais quand je régénère Grub, j’ai ça :

          # grub2-mkconfig -o /boot/grub2/grub.cfg 
/etc/default/grub: ligne 6: nvidia-drm.modeset=1 : commande introuvable

          Et le noyau 6.13.9 ne fonctionne toujours pas.

          Edit Nicosss : Correction balises Markdown -> Voir FAQ

            paradise J’ai corrigé tes messages concernant l’utilisation du bloc code en Markdown.

            Je t’invite vivement à lire les Conditions d’utilisation dont le lien est aussi en bas de page ainsi que plus particulièrement la FAQ du Forum. Merci par avance afin de faciliter la lisibilité.

            Que retourne
            $ cat /etc/default/grub

              Oui, désolé pour les balises.

              $ cat /etc/default/grub 
GRUB_TIMEOUT="5" 
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" 
GRUB_DEFAULT="saved" 
GRUB_DISABLE_SUBMENU="true" 
GRUB_TERMINAL_OUTPUT="console" 
GRUB_CMDLINE_LINUX="rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau
" nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init 
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"

              Mince, il y a toujours nvidia-drm.modeset=1.

              Normal, puisque Grub n’a pas été régénéré… 🙄

              Et ce n’est pas cohérent, s’il n’y a plus rien de nVidia, Nouveau ne doit pas être blacklisté, je m’en rends compte à présent…

              Edit Nicosss : Correction balises Markdown -> Voir FAQ

                paradise Normal, puisque Grub n’a pas été régénéré… 🙄

                Non ce n’est pas grub qui génère ce fichier, c’est le contraire.
                Edite la ligne et après quiet, supprime la directive nvidia-drm.modeset=1
                Puis tu enregistres le fichier, et à ce moment tu peux relancer grub2-mkconfig.

                  paradise Faudra prendre le temps de relire pour l’utilisation du bloc de code.

                   GRUB_CMDLINE_LINUX="rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau" nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

                  Il y a un peu beaucoup d’options à supprimer dont celles ajoutées en plus à la fin.
                  Je pense que plusieurs tentatives et modifications ont été apportées.

                      Nicosss

                      L'utilisation du bloc de code : parce que cela doit être sur une seule ligne ? En utilisant la balise >_ dans les contrôles supplémentaires ?

                      GRUB_CMDLINE_LINUX="rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau" nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

                      Si je fais un simple copier-coller à partir de la console, avec juste la balise </> :

                      GRUB_CMDLINE_LINUX="rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau" nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

                      ça sort en deux lignes tel quel, mais là c’est OK ?

                      $ cat /etc/default/grub 
GRUB_TIMEOUT="5"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="saved"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau" nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"

                          paradise C’est mieux, tu as l’air d’avoir compris l’utilisation pour le bloc de code.

                          Si tu as bien désinstallé les pilotes Nvidia alors il faut aussi supprimer les options de trop.
                          Pour utiliser nouveau, ta ligne doit ressembler à

                          GRUB_CMDLINE_LINUX="rhgb quiet"

                          Tu peux simplement faire l’essai depuis le Grub au démarrage en éditant les options du kernel en appuyant sur la touche E puis en retirant les options et enfin appuyer sur la touche F10.
                          Cette opération sera temporaire donc si tout va bien alors tu pourras modifier ton fichier /etc/default/grub de la même sorte et générer le Grub pour qui ce soit permanent.

                            Le souci venait de initramfs.

                            J’ai suivi cette procédure :

                            ls -la /boot
dracut  -f --regenerate-all
ls -la /boot
reboot

                            Et tout est nickel 🙂 :

                            $ uname -r 
6.13.9-200.fc41.x86_64

                            J’en ai profité pour épurer/etc/default/grub :

                            $ cat /etc/default/grub  
GRUB_TIMEOUT="5" 
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" 
GRUB_DEFAULT="saved" 
GRUB_DISABLE_SUBMENU="true" 
GRUB_TERMINAL_OUTPUT="console" 
GRUB_CMDLINE_LINUX="rhgb quiet" 
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"

                            MAIS : suite à une nouvelle MàJ vers 6.13.10, avec dnf update, rebelote !

                            Cette fois j’ai le retour en console :

                            Erreur non critique dans le scriptlet post-transaction : kernel-core-0:6.13.10-200.fc41.x86_64
>>> Sortie du scriptlet :
>>> Sign command: /lib/modules/6.13.10-200.fc41.x86_64/build/scripts/sign-file
>>> Signing key: /var/lib/dkms/mok.key
>>> Public certificate (MOK): /var/lib/dkms/mok.pub
>>>
>>> Autoinstall of module rtl88x2bu/@PKGVER@ for kernel 6.13.10-200.fc41.x86_64 (x86_64)
>>> Cleaning build area... done.
>>> Building module(s).........(bad exit status: 2)
>>> Failed command:
>>> 'make' -j4 KVER=6.13.10-200.fc41.x86_64 KSRC=/lib/modules/6.13.10-200.fc41.x86_64/build
>>>
>>> Error! Bad return status for module build on kernel: 6.13.10-200.fc41.x86_64 (x86_64)
>>> Consult /var/lib/dkms/rtl88x2bu/@PKGVER@/build/make.log for more information.
>>>
>>> Autoinstall on 6.13.10-200.fc41.x86_64 failed for module(s) rtl88x2bu(10).
>>>
>>> Error! One or more modules failed to install during autoinstall.
>>> Refer to previous errors for more information.
>>> /usr/lib/kernel/install.d/40-dkms.install failed with exit status 11.
>>>
>>> [RPM] %posttrans(kernel-core-6.13.10-200.fc41.x86_64) scriptlet échoué, état de sortie 11

                            Donc, souci avec DKMS 🙄!

                            Un rapport avec le module rtl88×2bu (module de dongle wifi) ?

                            Le module de dongle wifi est bien dans /var/lib/dkms, ça pourrait expliquer que ça bloque le reste ??

                            Donc, la solution est ponctuelle, non pérenne.

                            Même procédure pour le nouveau noyau, c’est OK… jusqu’au prochain noyau.

                            $ uname -r 
6.13.10-200.fc41.x86_64

                            Edit Nicosss : Correction balises Markdown -> Voir FAQ

                              Pas simple, ce Marc Down 😁, chez moi le texte en surbrillance apparaît correctement en forme en pré-visualisation.

                              Dans la FAQ :

                              "Soit sélectionner le texte et cliquer sur le bouton “</>” .

                              C’est ce que je fais, mais ça ne semble pas convenir ?

                              Donc, il faut utiliser la balise >_ , là par exemple c’est bon ?

                              Erreur non critique dans le scriptlet post-transaction : kernel-core-0:6.13.10-200.fc41.x86_64
>>> Sortie du scriptlet :
>>> Sign command: /lib/modules/6.13.10-200.fc41.x86_64/build/scripts/sign-file
>>> Signing key: /var/lib/dkms/mok.key
>>> Public certificate (MOK): /var/lib/dkms/mok.pub
>>>
>>> Autoinstall of module rtl88x2bu/@PKGVER@ for kernel 6.13.10-200.fc41.x86_64 (x86_64)
>>> Cleaning build area... done.
>>> Building module(s).........(bad exit status: 2)
>>> Failed command:
>>> 'make' -j4 KVER=6.13.10-200.fc41.x86_64 KSRC=/lib/modules/6.13.10-200.fc41.x86_64/build
>>>
>>> Error! Bad return status for module build on kernel: 6.13.10-200.fc41.x86_64 (x86_64)
>>> Consult /var/lib/dkms/rtl88x2bu/@PKGVER@/build/make.log for more information.
>>>
>>> Autoinstall on 6.13.10-200.fc41.x86_64 failed for module(s) rtl88x2bu(10).
>>>
>>> Error! One or more modules failed to install during autoinstall.
>>> Refer to previous errors for more information.
>>> /usr/lib/kernel/install.d/40-dkms.install failed with exit status 11.
>>>
>>> [RPM] %posttrans(kernel-core-6.13.10-200.fc41.x86_64) scriptlet échoué, état de sortie 11

                                paradise Donc, il faut utiliser la balise >_ , là par exemple c’est bon ?

                                Oui, là c’est très bien. Tu remarqueras dans la FAQ qu’il 2 manières de faire dont une où il faut être en mode texte enrichi et l’autre non.

                                Par ailleurs tu peux aussi modifier ton message si ça ne va pas -> Conditions d’utilisation .

                                  J’étais plus habitué au code HTML, désolé !