Noyau linux-libre 5.16-3 failed

Pour aider le diagnostic, j’aimerais savoir si tu as un système de fichiers de type XFS qui est automatiquement monté au démarrage. Tu peux par exemple montrer la sortie cette commande depuis le système fonctionnel :
$ lsblk -f

XFS est le type de système de fichiers que choisit par défaut l’installateur Trisquel pour /home. Aussi, as-tu attendu que le redémarrage te mène à un prompt, c’est-à-dire à un "#" après lequel tu peux entrer des commandes ? C'est que j’ai de mon côté laissé le démarrage se poursuivre jusqu’à un tel prompt, que j’ai reçu un message d’erreur indiquant l’impossibilité de monter /home (aussi du type XFS sur mon système) et qu’en essayant monter /home à la main depuis ce prompt, la commande semblait geler le système.

Rien qui ait donc l’air d’être lié au montage de ton /home (effectivement en XFS). Jxself dit qu’il n’a, de son côté, rien changé depuis la version 5.16.2, que la version 5.16.4 devrait arriver dans son dépôt aujourd’hui et que nous allons donc voir si elle résout nos problèmes.

Si tu veux déjà tester la version qui sera bientôt dans son dépôt : https://jxself.org/kernel-testing/linux-image-5.16.4-gnu_5.16.4-gnu-1.0_amd64.deb

De mon côté, je suis resté bloqué sur Plymouth. Je n’ai attendu qu’une dizaine de minutes cette fois et ni Esc ni Ctrl+Alt+F1 me donnait un terminal. Le « recovery mode » semble démarrer normalement (avec /home monté), rien n'a attiré mon attention dans la sortie de journalctl -xb, et je ne suis pas parvenu à redémarrer normalement : après de nombreuses secondes, la commande reboot m’a rendu la main, sans imprimer quoi que soit; systemctl reboot m’a montré plusieurs erreurs, demandé de vérifier le statut de reboot.target et ne semblait jamais terminer.

Pour trouver le commit précis ayant introduit le problème, la recherche par dichotomie s’applique. Jxself compile des noyaux que je teste. Nous en sommes à la troisième itération, donc à 2³ = 8 fois moins de commits parmi lesquels chercher. Selon jxself, neuf itérations au total devraient être suffisantes (je suppose donc que, sauf erreur de sa part, il y a eu un peu plus de 2⁹ = 512 commits entre la version 5.16.2 e 5.16.3).

Comme nous faisons probablement face au même problème, https://jxself.org/kernel-testing/linux-image-5.16.2-1a4cefba5cb2fc9d74e859b2e8b21fac97e5563-gnu_1a4cefba5cb2fc9d74e859b2e8b21fac97e5563_amd64.deb devrait fonctionner chez toi alors que https://jxself.org/kernel-testing/linux-image-5.16.2-8423ec05aff2b41ca657e56fb3dd7ca0da566cb1-gnu_8423ec05aff2b41ca657e56fb3dd7ca0da566cb1_amd64.deb non (si tu veux tester pour confirmer). Il s’agit de notre intervalle actuel.

EDIT : à la quatrième itération, https://jxself.org/kernel-testing/linux-image-5.16.2-96d936e9c05c7e8864ff9cc928a2d5c19f0ac3c3-gnu_96d936e9c05c7e8864ff9cc928a2d5c19f0ac3c3_amd64.deb na marche pas ici (et probablement chez toi) et https://jxself.org/kernel-testing/linux-image-5.16.2-1a4cefba5cb2fc9d74e859b2e8b21fac97e5563-gnu_1a4cefba5cb2fc9d74e859b2e8b21fac97e5563_amd64.deb demeure donc la version avec le plus de commits qui fonctionne.

J’ai fait par à jxself de tes tests. Comme je lui ai écrit, nous souffrons très probablement du même problème et je trouverais étonnant qu’il affecte Linux (c’est-à-dire pas seulement Linux-libre) : quelle est la probabilité que deux utilisateurs de Trisquel souffre d’un même problème critique (qui ne semble donc pas rare) qui existerait dans le bien-plus-utilisé Linux (avec les blobs) mais qui n’aurait pas été rapporté entre les version 5.16.3 et 5.16.4 ? Peut-être que le commit que nous allons identifier a accidentellement déclenché une modification délétère par le script de deblob...

Si tu veux continuer, parmi les noyaux que j’ai testés, celui avec le plus de commits qui fonctionne ici est https://jxself.org/kernel-testing/linux-image-5.16.2-1a88b7960a3c3b71c1f5071a299a132e41ade25-gnu_1a88b7960a3c3b71c1f5071a299a132e41ade25_amd64.deb et celui avec le moins de commits qui ne fonctionne pas ici est https://jxself.org/kernel-testing/linux-image-5.16.2-2ee1f537cfb838fb1b4c080c3edf8989151f47db-gnu_2ee1f537cfb838fb1b4c080c3edf8989151f47db_amd64.deb

Non, aucune : le noyau démarre avant le reste de la distribution. D'ailleurs je suis de mon côté sur Debian 11.

Est-il bien nécessaire de continuer ?

Ce que nous cherchons à faire est d’identifier le problème précis pour le corriger.

La réponse est Non, car je suis passé sur le noyau de Jason Self (selon les recommandations de Magic) pour un problème matériel (à savoir des déconnexions intempestives et aléatoires du wifi via un dongle) et que celui-ci est peut-être résolu sous T10.

Si avec Linux-libre 5.4, par défaut dans Trisquel 10, tu souffres de nouveau de connexions intempestives, tu peux passer à la version 5.8 ou 5.13, toutes deux disponibles dans le dépôt de Trisquel 10. Si ce n’est pas suffisant, tu peux installer le paquet linux-libre-5.15 (supporté jusqu’en octobre 2027) du dépôt de jxself.

Bref, à moins que seules les premières versions de Linux-libre 5.16 résolvent tes connexions intempestives, tu n’as pas de soucis à te faire : ton matériel fonctionnera bien dans les prochaines années. Néanmoins, il est bon pour tout le monde de corriger les problèmes dans Linux-libre.

Merci pour le retour. Jxself pense avoir identifié le module coupable : iwlwifi. En le blacklistant, le dernier noyau Linux-libre, version 5.16.5, fonctionne ici. Jxself aimerait que tu testes aussi. Pour cela, écris "blacklist iwlwifi" dans /etc/modprobe.d/blacklist.conf:
$ echo blacklist iwlwifi | sudo tee -a /etc/modprobe.d/blacklist.conf
Installe aussi linux-libre ou linux-libre-5.16, dans le dépôt de jxself. Je ne suis pas certain qu’il faille mettre à jour l’initramfs mais je l’ai fait :
$ sudo update-initramfs -u
Tu peux ensuite redémarrer et voir Linux-libre 5.16 démarre.

Est-ce que, comme moi, tu as une carte Wi-Fi avec un chipset Intel (vois la sortie de lspci si tu ne sais pas) et que tu utilises un dongle qui ne nécessite pas de micrologiciel privateur ? Si c’est le cas, blacklister iwlwifi ne te fera pas perdre ta connexion Wi-Fi fonctionnelle, parce que iwlwifi est spécifique aux chipsets Intel.

Il semblerait que le problème vienne réellement de Linux (avec les blobs). En effet, jxself m’a mis à disposition https://jxself.org/kernel-upstream/linux-image-5.16.2-6b5ad4bd0d78fef6bbe0ecdf96e09237c9c52cc1_6b5ad4bd0d78fef6bbe0ecdf96e09237c9c52cc1_amd64.deb et, sans blacklister iwlwifi, ce noyau avec blobs (à utiliser pour corriger le problème seulement !) ne démarre pas non plus. Si tu veux essayer aussi…

Merci à toi aussi pour les tests. Il y a maintenant des réponses à https://lore.kernel.org/stable/20220203161959.3edf1d6e@valencia/T/#u