Cyril Brulebois a écrit 670 commentaires

Étant donné que compilation et édition de liens sont découplées ici, il faut penser à indiquer testLib.o sur la dernière ligne.

Alternativement, ceci fait le job en une passe :

gcc useTestLib.c -o useTestLib -ltestLib -L.
LD_LIBRARY_PATH=$(pwd) ./useTestLib

Debian Consultant @ DEBAMAX

Ça en fait deux. ;p

(Une) version Perl : perl -ne 'print "$1\n" if /EPSON .* id=(\d+)/'

Debian Consultant @ DEBAMAX

Les deux domaines que j'ai migrés jusqu'à présent (un .fr et un .com) l'ont effectivement été en payant une année, qui s'est ajoutée à la date d'expiration précédente (sur une migration Gandi → Infomaniak). Je me garderais bien d'en tirer une quelconque conclusion définitive cependant, c'est mon tout premier changement…

Debian Consultant @ DEBAMAX

Si tu gardes Gandi comme registrar, j'imagine que c'est (aussi) pour conserver la partie DNS chez eux aussi, donc pas de bascule vers un DNS externe nécessaire pour juste avoir les mails ailleurs, non ?

Dans les choses qu'il faut s'attendre à paramétrer, il y a bien sûr le(s) enregistrements MX (Mail eXchangers), les éventuels champs pour SPF/DKIM/DMARC, mais la partie NS ne devrait pas bouger si tu continues à gérer la zone chez Gandi.

Debian Consultant @ DEBAMAX

Avertissement : Je ne connais rien à Manjaro.

Cependant, deux cas probables selon moi :

• Secure Boot est activé, et il y a un problème avec l'utilisation d'une clé de signature « MOK » (Machine Owner Key) pour signer les modules compilés localement.
• Indépendamment du premier point, il peut y avoir un problème de compilation locale des modules.

Dans le second cas :

• Les modules pourraient ne pas avoir été compilés du tout, soit parce que leur code n'est pas compatible avec la version du noyau, soit parce que le système d'automatisation n'a pas fait son boulot. Je m'attendrais à ENOENT plutôt qu'à ENOEXEC si les modules étaient complètement absents, mais j'ai déjà vu des cas d'erreur en espace utilisateur où il pouvait y avoir confusion entre ces deux codes d'erreur.
• Le système de compilation pourrait ne pas avoir (re)compilé les modules pour une nouvelle version de noyau, ce qui pourrait donner une tentative d'utiliser des vieux modules avec un nouveau noyau… ce qui est souvent une très mauvaise idée si on n'a pas de garantie de compatibilité binaire.

Pistes :

• Vérification de l'existence ou non des modules.
• Comparaison de leur date de modification vs. date d'installation du noyau.
• Surveillance de la sortie de dmesg.
• Tentative de chargement manuel des modules via modprobe (et point précédent).

Debian Consultant @ DEBAMAX

Je ne suis pas sûr de comprendre la contrainte sur le navigateur qui ne fait que GET et POST. Pour faire du REST (complet) depuis un navigateur, des greffons comme RESTED existent, et offrent toute la panoplie ?

Debian Consultant @ DEBAMAX

Merci pour tes efforts de reformatage mais attention :

• ${symbol} (permutation des deux premiers caractères) ;
• ${LENGHT} (manque le dollar) — dont ça n'est pas l'orthographe au passage.

Je ne comprends pas le problème de gzgtrhe :

1. Que signifie « ne passe pas » ?
2. Le code en dehors de la fonction utilise tr --delete, le code dans la fonction utilise tr --delete --complement.

Alors oui, si on passe en paramètre [:space:], on demande à supprimer tout ce qui n'est pas espace, et il reste des espaces. Et retour au premier point.

Debian Consultant @ DEBAMAX

Certains paquets peuvent être marqués comme étant Multi-Arch: allowed, Multi-Arch: foreign ou Multi-Arch: same, ce qui permet en fonction des cas d'installer libfoo42:amd64 et libfoo42:arm64 sur un même système en même temps, tandis que dans d'autres cas, c'est l'un ou l'autre. Si tu compares abiword et le plugin, tu verras que le premier n'a pas ce champ, tandis que le second a Multi-Arch: same, d'où l'indication supplémentaire concernant l'architecture. On parle alors d'arch-qualified package name.

Debian Consultant @ DEBAMAX

Merci de m'avoir épargné un peu de rédaction. :-)

En complément, il ne s'agit pas d'un éventuel problème de traduction dans Dolphin, la couche en dessous, KIO, remonte bien une information de création, via un champ UDS_CREATION_TIME qui peut être positionné via une triple condition dans file_unix.cpp : st_birthtime ou __st_birthtime sur les différents BSD, ou statx sur Linux.

Pour les champs traditionnels, il n'y a qu'atime et mtime qui sont tracés (UDS_MODIFICATION_TIME et UDS_ACCESS_TIME).

Au passage, les deux tests sur ce champ été mis en commentaire : un et deux…

Debian Consultant @ DEBAMAX

Une machine x86 peut globalement être démarrée de deux façons :

• à l'ancienne, en mode BIOS (également appelé CSM de nos jours), avec un GRUB qui se met en début de disque (MBR) ;
• plus récent, en mode UEFI (avec ou sans Secure Boot), avec un GRUB qui met des morceaux dans une partition ESP (EFI System Partition) et un pointeur dans le firmware UEFI, vers le fichier en question (avec une éventuelle indirection shim pour Secure Boot).

Dans le premier cas, rien à faire si ton BIOS est configuré pour regarder le disque.

Dans le second cas, en fonction du firmware UEFI, de sa configuration et des éventuels problèmes d'implémentation, l'enregistrement du pointeur vers l'ESP peut ne pas fonctionner du tout, ou pas correctement. Avec un firmware verrouillé, cela peut être encore plus compliqué. Forcer un démarrage du système d'installation en mode BIOS facilite une installation du système en mode BIOS. En fonction du système d'installation, cela peut être possible de forcer une installation BIOS même s'il est démarré en mode UEFI.

Dans le monde Debian, cela se traduit par l'installation de paquets grub-pc dans le premier cas et par l'installation de paquets grub-efi-amd64* dans le second cas. J'imagine que la ventilation des paquets est assez similaire dans le monde Ubuntu.

Exemple de « pointeur » vers l'ESP sur mon laptop :

kibi@tokyo:~$ efibootmgr -v|grep debian
Boot0000* debian    HD(1,GPT,947341f0-347f-4e4d-ab9d-687837bde6b1,0x800,0x100000)/File(\EFI\debian\shimx64.efi)

Ici on voit une première partie identifiant le disque, le type de table de partitions, etc. puis une seconde partie qui est un chemin à l'intérieur de la partition ESP (FAT), avec l'indirection shim (qui passe ensuite la main à GRUB).

Debian Consultant @ DEBAMAX

Si c'était le cas, nous n'aurions pas la seconde photo, sur laquelle un disque dur est mentionné…

Debian Consultant @ DEBAMAX

Le port est déjà utilisé par un autre service, ce qui déclenche une erreur.

C'est le même genre de problèmes qu'on peut avoir en installant deux serveurs web comme apache2 et nginx qui par défaut écoutent tous les deux sur le port TCP 80.

Debian Consultant @ DEBAMAX

J'ai de très vagues souvenirs de limitations possibles en fonction de la connectique (qualité du câble et/ou type de connexion, HDMI vs. DP vs. DVI vs. VGA, etc.).

Debian Consultant @ DEBAMAX

Voir également strace(1).

Debian Consultant @ DEBAMAX

Content que des résultats cohérents apparaissent enfin.

Cela ne répondra pas nécessairement à toutes les questions, mais tu devrais avoir des traces des différentes opérations apt (qu'elles aient été déclenchées par des opérations manuelles ou automatiques) dans /var/log/apt/{term,history}.log (et versions logrotatées). Tu ne devrais pas y voir la partie téléchargement (et URL…) mais au moins l'enchaînement des opérations de mises à jour, suppressions, etc.

Debian Consultant @ DEBAMAX

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