Bonjour
Alors voilà, mes mises à jour de kernel ne me permettent plus de démarrer, je ne peux démarrer que sur le kernel 6.8.9 j’ai supprimé le 6.8.10 et le 6.8.11, mais le problème se représente avec le 6.9.4.


J’ai fait, après redémarrage, sur 6.8.9.
#journalct -xb
https://www.dropbox.com/scl/fi/kgwoys9eg0abmbndxiwn8/jounal.txt?rlkey=rc2pz3pgbp0uk1wbalrhrcowt&st=qctfhq0v&dl=0

Mais ça reste opaque pour moi, si vous pouvez me dire ce que je peux faire pour tenter de résoudre mon problème, car je ne comprends absolument pas ce qui se passe, merci à vous.

  • 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

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.