Cyril Brulebois a écrit 605 commentaires

Tu pourrais essayer de déplacer les fichiers d'index (cf. *Release, *Packages et *Sources sous /var/lib/apt/lists/) ailleurs, faire apt-get update, puis vérifier ces mêmes commandes.

En regardant (vraiment rapidement) les historiques des paquets concernés, je n'ai pas vu ces versions être uploadées dans Debian. Dès lors, pourquoi seraient-elles annoncées comme présentes dans bookworm, sur deb.debian.org ?!

Corruption locale au système de fichiers ? Mais ce ne serait vraiment pas de chance que le format ait été conservé, ainsi que les signatures GPG.

Debian Consultant @ DEBAMAX

Désolé si ça n'était pas clair, j'entendais bien apt-cache policy <paquet> notamment avec gnome-shell mais également les paquets aux versions bizarres mentionnées dans la sortie. Je ne vois pas d'où ils peuvent bien venir.

Edit: apt-forktracer est un superbe outil pour vérifier s'il y a des paquets étranges sur un système (qu'ils soient ou non présents dans un dépôt configuré, dans la version installée sur le système). Je l'utilise systématiquement après chaque migration vers une nouvelle version majeure, ça complète très efficacement apt-get autoremove.

Pour les dépendances inverses, apt-cache showpkg <paquet> même si la compréhension de sa sortie demande un peu d'habitude.

Debian Consultant @ DEBAMAX

Commençons par le début, il y a bien eu une mise à jour de sécurité publiée pour gnome-shell : DSA-5501-1.

Cependant, les versions mentionnées dans ta sortie apt sont loin de me convaincre, puisque :

kibi@tokyo:~$ rmadison gir1.2-mutter-11 libmutter-11-0
gir1.2-mutter-11 | 43.6-1~deb12u1 | stable     | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
libmutter-11-0   | 43.6-1~deb12u1 | stable     | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

Donc je ne sais pas d'où viennent les versions 43.4-2 qui sont mentionnées, mais ça me semble incohérent avec une Debian 12 propre.

Vérifie la sortie d'apt-cache policy, notamment pour le paquet gnome-shell ?

Pour wine, même si je n'ai pas joué avec depuis très longtemps, il y a probablement besoin d'activer i386 comme architecture supplémentaire au niveau de dpkg (cf. --add-architecture), afin d'installer paquet1:i386, paquet2:i386, etc.

Debian Consultant @ DEBAMAX

Suggérer d'utiliser un système déprécié, sans donner d'indications précises, ça me semble être une mauvaise idée.

Surtout quand il y a une alternative entre la version historique et la version nft, et que pour effectivement passer de l'une à l'autre il faut redémarrer le système…

Debian Consultant @ DEBAMAX

D'après le code en question, il y a tentative d'ioctl avec l'opération VIDIOC_REQBUFS qui échoue, ce qui se propage à start(). Puisque le cas mmap ne semble pas bien se passer, tu pourrais regarder les options V4L2 mentionnées dans le README du projet v4l2rtspserver (ou dans la sortie de -h), pour essayer d'utiliser une autre interface. Notamment -r qui permet de basculer le réglage par défaut V4l2IoType ioTypeIn = IOTYPE_MMAP; à ioTypeIn = IOTYPE_READWRITE;.

Debian Consultant @ DEBAMAX

Je mets de côté l'éventuelle configuration pare-feu.

Ta machine a deux interfaces différentes avec le même réseau : 192.168.0.0/24.

Si un paquet arrive sur une des IP 192.168.0.29 ou 192.168.0.254, la réponse à destination de l'IP 192.168.0.X va être envoyée… via l'une ou l'autre des interfaces (voir la notion de métrique, visible dans la sortie d'ip route).

Le plus simple est d'utiliser deux réseaux différents. Et seule une des deux IP (celle côté réseau local — enp3s0 — et pas celle du réseau FAI — enp2s0) est à renseigner dans la configuration de tes postes (hors routeur).

Le premier réflexe quand des paquets n'arrivent pas au bon endroit, c'est utiliser tcpdump ou équivalent. Dans le cas présent, tu devrais voir arriver des paquets sur le routeur, les éventuelles réponses et leur destination.

Debian Consultant @ DEBAMAX

Je ne sais pas quelles vérifications tu as faites, mais je ne suis pas d'accord avec tes conclusions.

kibi@anchorage:~$ sudo modinfo rtl8xxxu|grep 2357
alias:          usb:v2357p0109d*dc*dsc*dp*icFFiscFFipFFin*
alias:          usb:v2357p0108d*dc*dsc*dp*icFFiscFFipFFin*

On voit bien 0109 et 0108 mais pas 0107.

Côté drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c (au moins dans stable/linux-6.1.y), il y a bien cette entrée :

{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff),
        .driver_info = (unsigned long)&rtl8192eu_fops},

mais elle est gardée par ceci :

#ifdef CONFIG_RTL8XXXU_UNTESTED

or le packaging du noyau Debian dans la branche bookworm définit ces options de configuration :

debian/config/config:CONFIG_RTL8XXXU=m
debian/config/config:# CONFIG_RTL8XXXU_UNTESTED is not set

Donc non, l'information VID/PID pour ta carte n'est pas dans le module, et c'est normal que charger manuellement le module ne change rien.

C'est également le cas dans la branche master (v6.6-rc1-33-g3669558bdf354 actuellement).

Si tu veux contribuer aux tests, je t'invite à sortir les identifiants de ta carte du #ifdef et à compiler un noyau avec cette modification. Si ta carte fonctionne avec le module ainsi modifié, tu pourras envoyer un patch indiquant les tests effectués, pour une éventuelle activation par défaut (dès lors que CONFIG_RTL8XXXU est activée, quelle que soit l'état de CONFIG_RTL8XXXU_UNTESTED).

Bons tests !

Debian Consultant @ DEBAMAX

Ces temps-ci j'ai tendance à utiliser des volumes logiques (LVM) mais j'ai conservé quelques notes à propos de NBD pour les images QCOW2 :

modprobe nbd
qemu-nbd -c /dev/nbd0 monimage.qcow2
kpartx -asv /dev/nbd0

À partir de là, tu devrais avoir autant d'entrées dans /dev/mapper qu'il y a de partitions dans l'image. Tu peux ensuite utiliser mount pour récupérer la main sur les fichiers à l'intérieur de chacune.

Après démontage :

kpartx -dsv /dev/nbd0
qemu-nbd -d /dev/nbd0

Debian Consultant @ DEBAMAX

Histoire de comparer ce qui est comparable, je regarderais du côté des images Debian live publiées pour 12.1.0 (même si ces dernières sont figées dans le temps, et sont plus « vieilles » que ton système, ça devrait permettre de vérifier si un problème matériel est apparu vs. un problème logiciel).

Si le système se charge correctement, j'en profiterais pour regarder ce qu'il y a dans le système de fichiers racine. Notamment /var/log/apt/*.log pour les mises à jour installées « dernièrement » mais non nécessairement appliquées. Dans ton cas, les paquets linux-image-* et assimilés peuvent avoir été mis à jour il y a plusieurs jours ou semaines, mais sans le redémarrage associé, il arrive de se rendre compte d'éventuelles régressions bien plus tard.

Ces derniers temps, les paquets *-microcode ont été mis à jour. Je n'ai pas le détail en tête (et c'est de toute façon souvent compliqué avec les constructeurs qui communiquent peu de détails techniques), mais ça pourrait valoir le coup de supprimer le paquet, rebuilder l'initramfs, et retenter un démarrage sans. Si le problème disparaît, retenter l'installation de la version précédente, vérifier que ça continue à fonctionner, puis ouvrir un rapport de bogue pour signaler la régression.

Quant aux erreurs ACPI, c'est malheureusement très courant, et ça peut ne pas être plus gênant que cela… À nouveau, en accédant à ton système de fichiers racines depuis un système live, tu dois pouvoir vérifier la présence ou non de ce message dans les logs noyau des démarrages passés.

Bon courage.

Debian Consultant @ DEBAMAX

J'ai été un temps chez AXA avec leur offre MRP, dont la base était un peu élevée (800+ euros en 2015)… parce qu'il y avait une promotion « startup » (je rentrais dans les cases pour des raisons qui m'échappent, étant une SASU avec une volonté claire d'être le seul et unique salarié) rendant le tarif abordable (environ la moitié). En quelques années, ça a pris 50 %, tandis que l'agence ne donnait pas satisfaction sur d'autres points. J'ai basculé chez Hiscox, qui semble bien connaître nos métiers, pour un tarif inférieur et des garanties supérieures.

Je n'ai eu besoin de faire jouer ni l'une ni l'autre à ce jour, donc je ne peux pas en dire beaucoup plus.

Debian Consultant @ DEBAMAX

Sous réserve que ça soit disponible et activé sur les interfaces concernées (LAN et/ou WLAN), il suffit de lancer wakeonlan la:ma:ca:dd:re:ss et la machine revient. Je l'utilise sur des machines complètement éteintes plutôt qu'en sommeil, mais ça ne devrait pas faire de différence.

L'article Wikipedia est très complet. :)

Debian Consultant @ DEBAMAX

Il s'agit d'un PC mais #1035382.

Debian Consultant @ DEBAMAX

Non, il s'agit de supprimer les hooks déployés par le paquet raspi-firmware donc les deux z50-raspi-firmware.

Encore désolé pour la confusion dans la première réponse.

Debian Consultant @ DEBAMAX

Désolé, un des deux chemins n'était pas le bon :

sudo rm /etc/kernel/postinst.d/z50-raspi-firmware

et il va falloir repêcher le fichier que je t'ai fait supprimer par erreur…

Comme il s'agit d'un fichier de configuration, une simple réinstallation du paquet ne suffit pas. Tu peux utiliser ceci :

apt-get download initramfs-tools
dpkg -x initramfs-tools_*.deb temporaire
sudo cp temporaire/etc/kernel/postinst.d/initramfs-tools /etc/kernel/postinst.d/

(Tu peux ensuite enlever le paquet téléchargé et le répertoire où son contenu a été extrait.)

Debian Consultant @ DEBAMAX

J'imagine que tu as installé depuis une image « Live ». Celles-ci installent tous les paquets de type firmware, problème qui sera corrigé dans les images 12.1 la semaine prochaine. Les images d'installation classiques (e.g. netinst) n'ont pas ce problème.

Il me semble que la suppression du paquet raspi-firmware n'est pas triviale (à cause d'autres problèmes…), je pense que tu peux supprimer les deux hooks pour éviter de rencontrer ces problèmes à chaque installation/mise à jour de noyau et paquets liés (e.g. initramfs-tools), avant de demander à dpkg de terminer la configuration des paquets concernés :

sudo rm /etc/initramfs/post-update.d/z50-raspi-firmware
sudo rm /etc/kernel/postinst.d/initramfs-tools
sudo dpkg --configure -a

Debian Consultant @ DEBAMAX

Recherche web : « opengroup sed » → #1

Debian Consultant @ DEBAMAX

Un cas ultra classique est udev, mais il est de toute façon nécessaire qu'il soit capable de tourner sur la version de noyau disponible dans la distribution précédente, pour être capable de faire la mise à niveau de oldstable à stable… (en revanche pas de garantie de pouvoir « sauter » une version). Je ne pense pas que ça soit délirant en attendant d'avoir un retour de l'équipe noyau sur ton rapport de bogue.

Si tu veux chasser le problème, je t'invite à t'appuyer sur snapshot.debian.org qui va te permettre de bisecter grossièrement sans aucune compilation (attention à ne pas remplir ton /boot). Normalement ça permet d'isoler la dernière version upstream qui fonctionne et la première qui ne fonctionne pas. C'est une information très intéressante pour la gestion du rapport de bogue, je t'invite à indiquer les résultats si tu arrives jusque-là.

À ce stade, si tu veux poursuivre : Quand tu as de la chance, c'est la même version upstream, et c'est juste une modification dans le packaging qui explique la différence. Autrement, j'ai tendance à prendre le tag v5.OK.0 et le tag v5.KO.0 pour vérifier, et ensuite lancer le bisect « linéaire » entre ces deux tags (ça évite de partir dans les branches stables linux-5.OK.y et linux-5.KO.y – mais ça peut être nécessaire si les tests faits sur les tags en question ne donnent pas le même résultat que le bisect sur les binaires). Bien évidemment, vu le modèle de développement de Linux, le bisect « linéaire » implique tout de même de voir des versions bien plus vieilles, puisque master est principalement une succession de merges depuis des branches qui ont été préparées sur des versions inférieures.

Debian Consultant @ DEBAMAX

En ayant redémarré sur le noyau fourni dans Debian 12, reportbug est ton ami (cf. https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-bugs.html#s9.2).

Debian Consultant @ DEBAMAX

OK, désolé pour ce point. N'ayant pas croisé ce genre d'unités dans la nature, j'ai regardé si je pouvais trouver un exemple et monter un PoC localement, et je n'ai pas vérifié sa page de manuel étant donné le comportement que tu décrivais et qui semblait s'expliquer par cette absence (perçue).

Debian Consultant @ DEBAMAX

Il n'y a ni condition ni relation déclarées.

L'unité service étant activée pour multi-user.target, elle est bien sûr lancée automatiquement au démarrage. N'étant pas reliée à l'unité path, elle n'est bien sûr pas lancée quand l'unité path est activée.

Ceci semble faire le job — mais je ne vais pas m'amuser à redémarrer mon laptop pour vérifier le comportement au démarrage.

kibi@tokyo:~$ cat /etc/systemd/system/replique_boot.path
[Path]
PathChanged=/boot
Unit=replique_boot.service

[Install]
WantedBy=default.target

kibi@tokyo:~$ cat /etc/systemd/system/replique_boot.service 
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo boot | logger -t test'


kibi@tokyo:~$ sudo systemctl enable --now replique_boot.path && sudo touch /boot/test

Debian Consultant @ DEBAMAX

OK. Je préférais vérifier…

Je commence à ne plus avoir trop d'idées. Tu pourrais essayer d'installer un linux-image depuis unstable, des fois que ça soit une régression dans les noyaux 6.1.y…

Debian Consultant @ DEBAMAX

Je pense qu'il faut absolument lire la doc sur les types de service. Déclarer un Type=simple implique qu'on s'attend à avoir un démon qui tourne. Or ici une commande est exécutée, bash termine, ce que systemd corrige en redémarrant après un délai de 10 secondes, obéissant aux directives Restart*.

J'imagine que se débarrasser de ces directives, basculer sur Type=oneshot devrait faire ce que tu souhaites. À tout le moins, cela devrait être une meilleure base de travail.

Debian Consultant @ DEBAMAX

Oui, ça apparaissait dans le log OK.

Désolé si la dernière demande n'était pas claire, serait-il possible d'avoir le log complet du dernier boot KO, après avoir tenté le chargement manuel de tous les modules ?

Debian Consultant @ DEBAMAX

Que contient le fichier modesetting.conf ?

Que se passe-t-il si tu charges à la main tous les modules drm. Oubliant toute subtilité, ceci devrait convenir :

for mod in $(find /lib/modules/$(uname -r)/kernel/drivers/gpu/drm -type f); do name=$(/usr/sbin/modinfo $mod|awk '/^name:/ {print $2}'); sudo modprobe $name; done

Nouveaux logs noyau appréciés.

Debian Consultant @ DEBAMAX

Il s'agit d'un (seul si je me souviens bien) essai parmi beaucoup d'autres, sans ces options.

Debian Consultant @ DEBAMAX