J’ai le même problème et aussi avec 6.9.5

En Anglais j’ai vu pas mal d’articles dans divers forum et on explique la situation par l’encryptage (nouveauté) des noyaux qui nécessitent un nouveau bootloader avec un contournement par intervention sur /usr/lib/ostree-boot

Je n’ai pas pu procéder à la manip parce que le répertoire n’existe pas chez moi et je n’ai pas réussi à trouver le paquet qui le fournit.

Voir:

https://discussion.fedoraproject.org/t/after-a-system-update-bad-shim-signature-silverblue-f40/120347/5

    Après sollicitation par l’équipe, je n’ai malheureusement pas résolu mon problème et il persiste avec le kernel 6.9.6 je ne sais pas si mon cas est particulier ou si d’autres rencontrent cette difficulté, je démarre donc toujours sur le 6.8.9 qui me dépanne bien.
    À noter que sur mon poste principal qui est resté sur Fedora 39, les nouveaux kernels fonctionnent parfaitement, je reste indécis pour tenter une réinstall complète, car je suis passablement déçu de la version Fedora 40 KDE. Je vais encore patienter puisqu’il s’agit de mon poste d’appoint très peu utilisé.
    Si d’autres sont dans ce souci ? …..

    Le problème n’est pas lié à KDE car je l’ai sous LXDE et cela se passe dès le boot. Comment est partitionné le pc : dos, gpt ? gpt dans mon cas.
    Quand je démarre le pc sur un live et que je lance fdisk, j’ai un message d’erreur que j’ai pas eu le temps d’approfondir mais je suppose que cela lance la vérification du disque avec les nouveaux noyaux mais ce n’est qu’une supposition

      Bon c’est ok, il faut remplacer resume par noresume dans /etc/default/grub et régénérer
      avec
      # grub2-mkconfig -o /boot/grub2/grub.cfg
      et ça boot

      NovFedo Pour connaître le type de table de partition utilisé, tu peux te servir de
      $ sudo parted -l

        je suis intrigué, j’ai bien ce resume mais il ne correspond à aucun disque !
        ...kernelopts="root=UUID=0281b194-e2c1-44a8-b7af-e42757eefbe2 ro resume=UUID=54cd66e9-5a81-4669-bf6f-8a7b4a8f1759

        # ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 23 juin  12:45 0281b194-e2c1-44a8-b7af-e42757eefbe2 -> ../../sda2
lrwxrwxrwx 1 root root 10 23 juin  12:45 1295ff76-cac4-400b-b967-47a3b604a8c2 -> ../../sda3
lrwxrwxrwx 1 root root 10 23 juin  12:45 cda39123-ff8b-440d-9310-e1b82eab3cc9 -> ../../sda4
lrwxrwxrwx 1 root root 10 23 juin  12:45 f3b9e437-786e-4ec1-8f03-ef04d81fece8 -> ../../sda1

        à quoi correspond ce resume ?

          fgland

          Je ne sais pas chez moi voici ce que ça donne
          Mais ce que je sais, c’est qu’après la manip ça fonctionne impeccable, à toi de voir

          0 -- 14:57:35 fedora@gil- $ ~  :             cat /etc/default/grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="noresume=UUID=21ae02b6-5d05-4d77-be36-3a4115fffaee rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true




ls -l /dev/disk/by-uuid/
total 0
drwxr-xr-x. 2 root root 100 29 juin  14:53 .
lrwxrwxrwx. 1 root root  10 29 juin  14:53 4781877e-ec3a-4334-823e-306b8e1cb6ab -> ../../sda2
lrwxrwxrwx. 1 root root  10 29 juin  14:53 b06ec8eb-bae0-4124-9119-b2514f7211c7 -> ../../sda4
lrwxrwxrwx. 1 root root  10 29 juin  14:53 b35e59a4-3423-4a4a-b66e-848ca809f654 -> ../../sda3
drwxr-xr-x. 8 root root 160 29 juin  14:53 ..

            ce qui a permis de corriger le problème chez moi c’est de faire

            rpm -ql shim-x64

            et j’ai constaté que la mise à jour ne se faisait pas dans le sous-répertoire /boot/efi/EFI d’où je fait le boot

            copier la dernière version de shimx64.efi vers ce sous-répertoire a permit d’utiliser 6.9.5

            Il y a maintenant au boot un écran de violation de sécurité avant le menu grub…….

              gbuvard
              Moi, je ne suis pas en UEFI bootloader ma machine date de 2014 en Bios, donc effectivement la solution doit être différente, mais c’est bien ainsi, on couvre tous les cas. Merci à toi.
              Bon dimanche.

                24 jours plus tard

                Bonjour,

                J’avais aussi ce problème depuis le passage au Kernel 6.8.10 et je pensais que la solution finirai par apparaître au fil des nouvelles versions. Ce qui ne fut pas le cas et mes 12 entrées antérieurs au 6.8.10 dans le dnf.conf allaient bientôt s’épuiser au fur et a mesure des mises à jour et du coup la dernière entrée valide disparaître….

                Merci pour la solution proposée avec le remplacement de resume par noresume dans le Grub qui règle le problème. Ce qui me chagrine c’est de le faire sans explication. Sans doute ce problème est il limité à certain Pcs anciens. Mon disque est un SSD en GPT et les paritions en EXT4.

                14 jours plus tard

                Je n’ai pas trouvé de solution pour mon portable. Une réinstallation à tout remis en ordre, donc sans doute une scorie liée aux multiple system-upgrade.