Cyril Brulebois a écrit 670 commentaires

Cela a été proposé en AG, mais rejeté (ouf), pour entrer dans les bâtiments de la résidence.

Autant remplacer un barillet commun et souffrant (jusqu'à devoir être remplacé) régulièrement par un système de badge devrait effectivement améliorer la vie de tout le monde, et cela a été acté.

Autant remplacer un système d'interphone qui fonctionne déjà par quelque chose s'appuyant sur la téléphonie, cela n'a pas persuadé beaucoup de personnes…

Dans les arguments de vente :

• La sécurité procurée par la vidéo → no comment.
• Il est possible de répondre et d'ouvrir de partout ! → Si on n'est pas chez soi, je ne vois pas trop ce que cela apporte d'autoriser quelqu'un à entrer dans les parties communes… (les boîtes aux lettres étant de toute façon déjà accessibles pour tout dépôt de courrier/colis).
• La facilité de gestion. → C'est quelque chose qui doit intéresser les syndics (et pas du tout les locataires ou propriétaires), il suffit de cliquer dans une interface web pour mettre à jour les noms lors des changements de locataires/propriétaires. Bien entendu, cela signifie qu'on se retrouve avec encore plus de données personnelles (joli combo, noms+adresses+téléphones…) confiées à des boîtes qui vont bien évidemment tout mettre en œuvre pour les protéger et ne pas les monnayer, n'est-ce pas ?
• Cela doit fonctionner avec les lignes fixes et les téléphones-non-ordipoches (vocal uniquement) en appuyant sur une touche pour ouvrir. → C'était la seule « bonne nouvelle » de l'ensemble.
• Trop bien une appli !!! → Si vous vous attendez à 3 pisteurs et 27 permissions dans le rapport d'Exodus Privacy pour l'application mobile, vous êtes dans le mille.

J'ai trouvé toute la problématique oppressante, de la réception de l'ordre du jour de l'AG à sa tenue… Courage à toutes celles et à tous ceux qui vont se voir imposer cela.

Debian Consultant @ DEBAMAX

Le problème se produit-il également si tu décolles les mains du laptop pour tapoter, pour être sûr de ne pas risquer des interactions avec le touchpad ?

(Oui, on est dans la catégorie idée à la schtroumpf, mais bon…)

Debian Consultant @ DEBAMAX

Alors les « patches » n'aident malheureusement pas du tout, puisqu'il y a 3 fichiers, et ça ne dit pas lequel est utilisé dans ton cas.

Les datasheets/block diagrams ne donnent aucune information technique… :(

Au mieux, en farfouillant dans HW info on a un lien vers Atlassian qui ensuite pointe vers une image, dans laquelle on trouve un /boot/cn9130-cf-base.dtb (qui peut être examinée via dtc). Est-ce cela que tu utilises ?

Quoi qu'il en soit, il semble s'agir d'un adaptateur Ethernet double, du coup je continue à ne pas comprendre pourquoi les deux ports ont des modes différents. J'ai réussi à trouver le pinout du Marvell 88E1512 qui semble être embarqué, mais pas la façon dont il est utilisé dans ton produit…

Si je regarde la DTB susmentionnée, on a ceci (je condense à nouveau) :

ethernet@0 {
  eth0 {
    phys = <0x1c 0x00>;
    managed = "in-band-status";
  };

  eth1 {
    phys = <0x1e 0x01>;
    phy = <0x1f>;
    managed = "in-band-status";
    phy-mode = "sgmii";
  };

  eth2 {
    phy = <0x20>;
    phy-mode = "rgmii-id";
    pinctrl-0 = <0x21>;
  };
}

mdio@12a200 {
  ethernet-phy@0 {
    phandle = <0x20>;
  };

  ethernet-phy@1 {
    phandle = <0x1f>;
  };
};

pinctrl {
  cp0-ge-rgmii-pins-0 {
    marvell,pins = "mpp44\0mpp45\0mpp46\0mpp47\0mpp48\0mpp49\0mpp50\0mpp51\0mpp52\0mpp53\0mpp54\0mpp55";
    marvell,function = "ge1";
    phandle = <0x21>;
  };
};

Ce qui ne descend pas mon niveau de perplexité :

• on garde en tête que phandle c'est grossièrement une notion de référence ;
• dans mdio@12a200, les deux sections ethernet-phy@0 et ethernet-phy@1 semblent bien correspondre aux interfaces eth2 et eth1 respectivement (le genre de symétrie que j'attendais) ;
• pourtant l'interface eth2 a un mode différent ;
• et l'interface eth2 passe par un pinctrl plutôt que d'avoir un attribut phys directement.

C'est là que les docs précises d'architecture pourraient permettre de vérifier que tout est branché et déclaré correctement.

Cela étant, je n'y connais rien en matériel, donc une fois ces observations random effectuées, je t'invite à contacter le support pour vérifier si l'interface est effectivement censée fonctionner, et s'il y a une configuration particulière pour celle-ci.

Et pour clore ma probable dernière intervention sur ce fil vu que je suis au bout de ma besace : ça me rappelle les histoires de RTC sur le CM4, de routage configurable de certains pins/gpios, pour lesquels il était question d'utiliser du pin muxing (e.g. i2c-mux-pinctrl). Pour que cela fonctionne il fallait activer certaines options de noyau (e.g. CONFIG_I2C_MUX_PINCTRL). Il pourrait être pertinent d'activer tout ce qui ressemble à du PINCTRL, juste pour être sûr que ça n'est pas un module qui serait trivialement manquant. Ceci dit, je n'ai aucune idée de si on s'attend à avoir une interface qui apparaît et qui arrive à Link is Up si c'est une partie du problème…

Au passage, je note de fuir SolidRun, qui n'a pas fait intégrer ses DTB dans mainline. Ça me rappelle une certaine fondation couleur framboise…

Debian Consultant @ DEBAMAX

OK pour 6.2, même si ton dmesg initial mentionnait une version 5.15…

Tu pourrais préciser où sont les patches constructeur ? Est-ce que les datasheets (avec le pinning/routage interne) sont disponibles ? Note : Je me trompe peut-être lourdement sur cette histoire d'eth1/eth2, mais qui n'a jamais fait une erreur (copier-coller ou autre) dans un fichier DTS…

Debian Consultant @ DEBAMAX

Hello,

Il y a une chose que je trouve surprenante, c'est qu'il y a apparemment une symétrie sur eth1/eth2, au moins en terme de module utilisé (Marvell 88E1510), et je m'attendrais à avoir les mêmes caractéristiques. En revanche, la configuration se fait en inband/sgmii pour eth1 tandis qu'elle se fait en phy/rgmii-id pour eth2 (cf. MII pour les détails).

Si je regarde arch/arm64/boot/dts/marvell/cn9130-db.dtsi dans le code source du noyau Linux, je vois des choses cohérentes par rapport aux spécifications constructeur :

2 x Ethernet RJ45 10/100/1000
1 x SFP+ 10GbE

à savoir (je conserve uniquement le plus pertinent) :

/* SLM-1521-V2, CON9 */
&cp0_eth0 {
        phy-mode = "10gbase-r";
        managed = "in-band-status";
};

/* CON56 */
&cp0_eth1 {
        phy-mode = "rgmii-id";
};

/* CON57 */
&cp0_eth2 {
        phy-mode = "rgmii-id";
};

Cela dit, il y a beaucoup de variantes cn913* !

Il serait bon de savoir quelles sont les caractéristiques exactes de ta machine, quelle est la version exacte du noyau, quelle DTB est utilisée, et si c'est effectivement la bonne.

En tout cas, c'est par là que je commencerais.

(Pourquoi je suggère cela : j'ai déjà vu des Pi CM3 se prendre pour des Pi 3 — ça ne marche pas du tout — et des Pi CM4 se prendre pour des Pi 4B — c'est pire, ça marche presque, sauf qu'il manque des morceaux — parce que le chargeur de démarrage se prenait les pieds dans le tapis et n'utilisait pas la bonne DTB.)

Debian Consultant @ DEBAMAX

OK. À quoi ressemble la sortie de lsusb et lspci ?

Debian Consultant @ DEBAMAX

Hello,

Est-ce qu'il pourrait y avoir un switch logiciel/matériel pour ta webcam ? Une recherche rapide suggère l'existence d'une « HP Camera Privacy Key ».

lshw -c media ne renvoie rien ici alors que j'ai deux webcams (une interne, une externe).

inxi -Gx ne renvoie que la webcam interne.

Tu peux regarder ce qu'il y a au niveau V4L2 avec find /dev/v4l/, indépendamment de tel ou tel outil de diag.

Debian Consultant @ DEBAMAX

Ce genre d'outil n'a pas besoin d'être intelligent. Il doit copier les données octet par octet. S'il corrompt le contenu de l'image, changer les options ou changer d'outil.

Debian Consultant @ DEBAMAX

De nos jours, l'outil standard, je dirais plutôt que c'est ce qui est intégré dans l'environnement de bureau ou bien system-config-printer si on cherche une application générique, plutôt que d'aller taper sur l'interface web du démon…

Debian Consultant @ DEBAMAX

Difficile de donner une réponse indépendante de la distribution, mais ceci devrait donner des pistes :

grep -Ril emoji /etc/fonts

Sur Debian 11 :

• /etc/fonts/conf.d/45-generic.conf: <description>Set substitutions for emoji/math fonts</description>
• /etc/fonts/conf.d/60-generic.conf: <description>Set preferable fonts for emoji/math fonts</description>

Debian Consultant @ DEBAMAX

fc-list :charset=1f431

Debian Consultant @ DEBAMAX

Tu peux regarder dans /sys/firmware/efi/efivars/ si tu as des entrées dump* ? Ça pourrait être une histoire de variables EFI saturées, et supprimer ces fichiers pourrait libérer de la place. Note : Je n'ai jamais été confronté à ce genre de souci, tu as peut-être envie de te renseigner par toi-même. ;)

Good luck!

Debian Consultant @ DEBAMAX

À en croire cet article, Debian gère Secure Boot depuis Debian Installer Buster RC 1, soit depuis bientôt 4 ans.

Tu pourrais donner l'appel efibootmgr complet pour ta tentative d'ajout (et la sortie de -v pour comparer avec l'entrée ubuntu). Tu pourrais également vérifier s'il y a des protections activées côté firmware, qui interdiraient peut-être les modifications. (En fonction des machines, on peut avoir besoin de positionner un mot de passe administrateur au niveau du firmware pour avoir le droit d'activer/désactiver Secure Boot, ça peut avoir des effets de bord, j'imagine…)

Debian Consultant @ DEBAMAX

Il existe un contournement classique pour les firmwares bogués.

Tu peux jouer avec efibootmgr -v pour vérifier la configuration courante, voire ajouter une entrée à la main.

Au passage, pourquoi désactiver Secure Boot ?

Debian Consultant @ DEBAMAX

Pas du tout d'accord avec le constat initial.

La version installée par Debian est la version cohérente avec la façon dont la machine a été démarrée pendant l'installation, donc grub-pc en mode BIOS (Legacy, CSM, etc.) et grub-efi-$arch en mode EFI (avec en bonus shim pour Secure Boot).

Debian Consultant @ DEBAMAX

Une recherche (beaucoup trop rapide) suggère que ce code est utilisé :

# This deliberately doesn't include /etc/default/grub.d/*.cfg, since we're
# only sourcing this configuration file in order to prompt for values to
# write back to /etc/default/grub.
if [ -e /etc/default/grub ]; then
  . /etc/default/grub
fi

if [ "${GRUB_CMDLINE_LINUX+set}" = set ]; then
  db_set grub2/linux_cmdline "$GRUB_CMDLINE_LINUX"
fi
if [ "${GRUB_CMDLINE_LINUX_DEFAULT+set}" = set ]; then
  db_set grub2/linux_cmdline_default "$GRUB_CMDLINE_LINUX_DEFAULT"
fi

Une bonne occasion de réviser la syntaxe shell ${foo+bar} ! ;)

Debian Consultant @ DEBAMAX

Espace entre le fichier à copier et sa destination :

sudo cp téléchargements/70-persistent-usb-gps.rules /etc/udev/rules.d/

Le message d'erreur t'indique qu'il manque le deuxième paramètre (la destination = le fichier/répertoire cible).

Debian Consultant @ DEBAMAX

Hello,

Dans les grandes lignes, l'ayant fait une fois, mais il y a longtemps :

1. ne pas se précipiter ;
2. NTFS stocke une copie du bloc de métadonnées en fin de disque ;
3. testdisk (déjà mentionné dans un autre commentaire) permet de restaurer ledit bloc à partir de la copie.

Extrait de https://www.cgsecurity.org/wiki/TestDisk :

Recover NTFS boot sector from its backup

Pour ma part j'avais commencé par dumper l'intégralité du disque dans un fichier image sur une autre machine, créé une copie sur ladite machine, puis travaillé sur la copie jusqu'à obtenir des résultats corrects. Si la copie est endommagée, il est possible de repartir du fichier image. Et tout cela évite de toucher aux données « live » sur le disque physique.

Bonne chance.

Debian Consultant @ DEBAMAX

Si tu veux le fin mot de l'histoire, tu peux comparer les versions d'udev (systemd) entre les différents systèmes, cela pourrait te donner des pistes.

Un exemple parmi d'autres (parcours rapide de mon historique Firefox) : https://github.com/systemd/systemd/issues/8221 (ici il s'agit d'une différence sur le traitement d'événements mais le résultat est le même, dans deux versions différentes, le même fichier de règle se met à ne plus faire ce qu'il faisait…).

Debian Consultant @ DEBAMAX

Si tu matches sur ENV{ID_SERIAL_SHORT}=="XXXX" au lieu de ATTRS{serial}=="XXXX" ?

On voit bien ATTRS{serial}=="00051229" apparaître dans ton dump, mais sur le grand-parent uniquement, du coup je ne suis pas sûr que la combinaison donnée dans la règle udev attrape quoi que ce soit ?

Debian Consultant @ DEBAMAX

Tout à fait. Je ne cherchais pas à prétendre que le boîtier DTI était censé tout faire, mais à prévenir que l'installation peut laisser à penser que tout est câblé/prêt à l'emploi, alors qu'il peut y avoir une seule paire connectée.

Debian Consultant @ DEBAMAX

Déjà vécu dans un logement aux normes récentes (à l'époque) : un circuit qui permet d'alimenter en téléphone les 4 prises Ethernet disposées dans l'appartement. La box ADSL peut être connectée partout → youpi.

En revanche, seuls deux des huit fils de chaque prise étaient connectés, donc le réseau autre que téléphonique était KO. Relier les 6 autres fils de chaque prise n'aurait pas suffi, puisque tout arrivait au même endroit… il aurait fallu intercaler un switch → vraiment pas youpi.

Note utilisateur : 1/10.

Debian Consultant @ DEBAMAX

Effectivement, chaîner quelques commandes de base, c'est plus rapide que mes bêtises dans différents langages. Avec une variante de ta méthode :

 1  5 27 shell

Debian Consultant @ DEBAMAX

Je laisse de côté le -1 trivial (ligne et caractère) en enlevant le caractère retour à la ligne… :)

Variante awk :

 1  3 49 awk

Debian Consultant @ DEBAMAX

C'est l'ensemble sous la forme perl -e 'la-magie', qui est appelé via ./soluce < les-données.

Pour la peine, je relance d'un :

 1  2 59 soluce2

Debian Consultant @ DEBAMAX