Que tu as un souci avec un périphérique de stockage.

Si tu peux donne ce que dit /etc/fstab.

Tu as un montage distant particulier?

    VINDICATORs

    non pas de montage distant

    UUID=4781877e-ec3a-4334-823e-306b8e1cb6ab /                       ext4    defaults        1 1
UUID=b35e59a4-3423-4a4a-b66e-848ca809f654 /home                   ext4    defaults        1 2

      J’ai le même problème sur un portable, j’ai voulu poster ce matin mais n’en ai pas eu le temps.
      Comme @NovFedo, je démarre toujours sur le 6.8.x.
      J’essaierai de poster en soirée

      Nicosss a renommé le titre en Démarrage impossible sur kernel 6.9.4 le .

      Je vais tester sur mon pc portable si j’ai le même résultat.

      Par contre je suis en BTRFS du coup cela ne voudra peut être rien donner…

      Édit : Aucun problème de mon coté en BTRFS. Je n’ai pas de partition en EXT4 dessus, mais j’en ai sur les fixes sans soucis.

      Voici le message d’erreur obtenu par gnome-logs->système :
      Expecting device dev-disk-by\x2duuid-0281b194\x2de2c1\x2d44a8\x2db7af\x2de42757eefbe2.device - /dev/disk/by-uuid/0281b194-e2c1-44a8-b7af-e42757eefbe2...
      dans la section Sécurité on trouve
      09:08:39 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck@dev-disk-by\x2duuid-cda39123\x2dff8b\x2d440d\x2d9310\x2de1b82eab3cc9 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
      et dans Applications :
      9:08:39 systemd: Starting systemd-fsck@dev-disk-by\x2duuid-cda39123\x2dff8b\x2d440d\x2d9310\x2de1b82eab3cc9.service - File System Check on /dev/disk/by-uuid/cda39123-ff8b-440d-9310-e1b82eab3cc9..
      Le pc :

      # inxi -d
Drives:
  Local Storage: total: 119.24 GiB used: 50.43 GiB (42.3%)
  ID-1: /dev/sda vendor: Silicon Power model: SPCC Solid State Disk

inxi -P
Partition:
  ID-1: / size: 47.86 GiB used: 19.38 GiB (40.5%) fs: ext4 dev: /dev/sda2
  ID-2: /boot size: 7.75 GiB used: 421.9 MiB (5.3%) fs: ext4 dev: /dev/sda3
  ID-3: /home size: 60.6 GiB used: 30.64 GiB (50.6%) fs: ext4 dev: /dev/sda4

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

      sda1 n’est plus utilisé, c’était le boot mais avec 500Mo il était trop petit, je l’ai remplacé par l’ancien swap (sda3) qui n’était plus utilisé

      les noyaux insallés

      # rpm -q kernel
kernel-6.8.9-300.fc40.x86_64
kernel-6.8.11-300.fc40.x86_64
kernel-6.9.4-200.fc40.x86_64

      le seul qui marche étant kernel-6.8.9-300.fc40.x86_64

      # inxi -f
CPU:
  Info: dual core model: AMD E-350 bits: 64 type: MCP cache: L2: 1024 KiB
  Speed (MHz): avg: 1440 min/max: 800/1600 cores: 1: 1600 2: 1280
  Flags: 3dnowprefetch abm aperfmperf apic arat clflush cmov cmp_legacy
    constant_tsc cpuid cr8_legacy cx16 cx8 de extapic extd_apicid fpu fxsr
    fxsr_opt ht hw_pstate ibs lahf_lm lbrv lm mca mce misalignsse mmx mmxext
    monitor msr mtrr nonstop_tsc nopl npt nrip_save nx pae pat pausefilter
    pdpe1gb pge pni popcnt pse pse36 rdtscp rep_good sep skinit sse sse2
    sse4a ssse3 svm svm_lock syscall tsc vme vmmcall wdt

      Merci

      6 jours plus tard

      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.