didier gaumet a écrit : > > Je n'ai vraiment pas grande idée de ce qui peut causer ces problèmes > mais en plus des bons conseils de Frédéric, peut-être: > > - prendre connaissance du changement de pilote par défaut VA-API des > GPU Intel avec le passage à Bullseye (modifier la variable mentionnée > permettra peut-être de voir ce qui se passe) > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html#new-vaapi-default-driver > > - vérifier que les paquets intel-microcode, firmware-linux, firmware- > misc-nonfree sont installés: ils ne sont peut-être pas nécessaires mais > pourraient être utiles > > - vérifier que les paquets va-api nécessaires sont installés et que les > logiciels sont configurés pour utiliser va-api plutôt que vdpau ou > autre (en automatique, normalement ça devrait être bon) > > - vérifier que le noyau et les modules ne sont pas chargés avec des > options spécifiques ou que ces options spécifiques n'interfèrent pas > avec le décodage vidéo > > - vérifier que l'ordonnanceur (scheduler) du noyau est celui par défaut > ou que l'ordonanceur choisi n'interfère pas avec le décodage vidéo > (j'émets là une supposition, je ne sais même pas dans le détail comment > changer cet ordonnanceur, mais comme Joël descend plus profondément que > moi dans la technique...) > > - pour éventuellement (je n'ai jamais utilisé) avoir plus d'infos sur > ce qui se passe, installer le paquet intel-gpu-tools, vérifier si des > outils permettent un diagnostic et les utiliser > > Voilà, tout ça est assez théorico-conditionnel, désolé :-)
Je vais regarder tout ça, merci. \begin{mode déprime} Plus loin sur la page https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html, je lis que usrmerge sera bientôt obligatoire. Mais quand est-ce que ça s'arrêtera de déconner ? Après systemd qui est un bloatware à problème (des tas de choses merdoient joyeusement dès qu'on n'est plus dans une configuration standard et se soldent par des verrues dans /etc/systemd, ce serait acceptable si systemd n'était pas capable de mettre en vrac une machine l'empêchant de booter jusqu'au bout !), on va se taper obligatoirement usrmerge ? Mince, il n'y a pas que le poste de travail, il y a aussi l'embarqué pour lequel on est contraint de partitionner aux petits oignons (surtout lorsqu'on utilise des mémoires de type NAND). Il y a aussi toutes les configurations à client lourds, diskless où systemd se vautre lamentablement dans la configuration par défaut. Ce que je reproche à systemd, c'est le fait d'être une usine à gaz avec des fuites et des effets de bords rigolos (ou pas) empêchant par exemple dans certaines configurations le démarrage del'un ou l'autre des daemons (j'ai des exemples avec le daemon NFS, des bases de données, je n'ose même pas parler des passades de franche rigolade avec des disques de swap iSCSI)... Ou pire, empêchant le redémarrage d'un système sur un noyau un peu ancien lors d'une mise à jour foirée parce qu'il dépend beaucoup (trop) du noyau. Quant à usrmerge, c'est une mauvaise réponse à une bonne question. Un Unix devrait pouvoir démarrer avec un / en ro (et qui le reste), ne serait-ce que pour récupérer un système minimal utilisable pour remettre d'équerre /usr, même à distance. Là, on va être obligé de bidouiller un ramdisk pour monter au démarrage /usr, embarquer une copie des modules nécessaires dans ledit ramdisk et la configuration du bidule... Et si /usr est corrompu ? Mélanger / et /usr est la pire chose qui puisse exister. Ou alors, il faut aller au bout de la démarche et tout coller dans le même répertoire : /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin et toutes les bibliothèques (pour qu'on sache exactement où elles se trouvent histoire de simplifier la vie du chargeur dynamique). Je vais aller prendre un Lexomil tant ce monde me déprime. \end{mode déprime] Bien cordialement, JKB