Cyril Brulebois a écrit 605 commentaires

Idéalement, poster le paragraphe de l'entrée GRUB démarrée, voir /boot/grub/grub.cfg complet pendant qu'on y est. Et vérifier le contenu de l'initramfs pour le noyau cible (cf. lsinitramfs). Il doit y avoir plein de modules drm/* dedans, et ça doit être chargé automatiquement au démarrage. Vérifier enfin les éventuelles blagues sur les chargements de module via /etc/mod*.

Debian Consultant @ DEBAMAX

Première étape, comprendre ce que fait initrd=/install/gtk/initrd.gz sur la ligne de commande du noyau, l'enlever, et réessayer avec un initramfs qui n'est pas celui d'une image d'installation.

Debian Consultant @ DEBAMAX

C'est dur de t'aider si tu regardes les logs noyau pour toi…

Debian Consultant @ DEBAMAX

J'imagine que si tu es resté sur la version Debian 11 du paquet firmware-amd-graphics, ça pourrait expliquer ce genre de choses.

Si oui, lire les notes de publication (non-free-firmware etc.).

Si non, regarder les logs du noyau.

Debian Consultant @ DEBAMAX

Je cherche donc un moyen d'identifier son point d'entrée. Je n'ai accès qu'aux logs apache…

La réponse me semble dans la question.

En dehors des URL louches pour essayer d'accéder à des fichiers qui ne devraient pas être accessibles et/ou déclencher des actions non souhaitables, une technique classique est de téléverser un fichier (a.k.a une payload) contenant des saletés pour ensuite la faire exécuter.

Tout cela laisse généralement des traces dans les fichiers de log du serveur web.

Debian Consultant @ DEBAMAX

Je ne suis pas certain de ce que tu entends par « je ne crée qu'un port équivalent au port config ». J'imagine que ça peut signifier créer un lien symbolique sous /dev pour ce port en question ?

Quoi qu'il en soit, c'est une problématique très classique dans la gestion des modems et des équipements type liaison série. Dans le premier cas, il y a des ports de gestion/commandes AT, des ports de données, etc. La règle (udev) numéro 1, c'est de regarder ce que font les autres règles (/lib/udev/rules.d/*.rules me dépanne 75 % du temps).

Si tu cherches principalement à peupler /dev, tu peux discriminer entre les ports via le numéro d'interface. Exemple :

SUBSYSTEMS=="usb", ENV{.LOCAL_ifNum}="$attr{bInterfaceNumber}"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ACTION=="add", \
        ATTRS{idVendor}=="<foo id>", ATTRS{idProduct}=="<bar id>", ATTRS{product}=="Foo Bar Config port", \
        ENV{.LOCAL_ifNum}=="00", SYMLINK+="foo-bar-config%s{devpath}", GROUP="if-you-need-it", MODE="0666"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ACTION=="add", \
        ATTRS{idVendor}=="<foo id>", ATTRS{idProduct}=="<bar id>", ATTRS{product}=="Foo Bar Data port", \
        ENV{.LOCAL_ifNum}=="01", SYMLINK+="foo-bar-data%s{devpath}", GROUP="if-you-need-it", MODE="0666"

Après bien sûr, on peut faire des choses plus avancées :

• ajouter des métadonnées via l'environnement pour faire des recherches faciles depuis udevadm ou les API udev : ENV{VARIABLE1}="valeur1" (on peut en mettre plusieurs).
• taguer un port (ou plusieurs) avec systemd et ajouter une référence vers une unité systemd pour qu'elle donne lieu au lancement automatique d'une unité : TAG+="systemd", ENV{SYSTEMD_WANTS}="unit-for-foo-bar@foo-bar-config-%s{devpath}.service". Une des subtilités ici est de savoir si on veut une unité par port ou une par device. Dans le second cas, une fois les liens symboliques en place, c'est plutôt facile de passer d'un port à un autre… C'est ce que j'ai privilégié sur un projet client, cela signifie une seule unité à surveiller, et pas d'interaction entre deux unités « sœurs » à gérer.

Attention à la gestion du hotplug : en fonction du matériel, on peut avoir besoin d'accepter d'autres valeurs qu'add pour ACTION (par exemple add|change|move|bind, vu pour des modems).

Debian Consultant @ DEBAMAX

Présent.

Étant donné les choix techniques et politiques de la fondation Raspberry, ne pas utiliser Raspberry OS me semble être un but en soi.

C'était également assez instructif de commencer à donner un coup de main sur Pirogue Tool Suite, et de voir à quel point leur système de création d'image est fragile. Heureusement que nous n'avons pas mis tous nos œufs dans le même panier et que nous avons opté pour un dépôt additionnel (« PPA ») à ajouter à un système Raspberry OS… ou Debian.

Et toute personne utilisant Debian par ailleurs n'a qu'un seul écosystème à suivre (en terme de publications, planifications de mises à jour, qu'elles soient majeures ou de sécurité, etc.).

--
Cyril, pas du tout biaisé.

Debian Consultant @ DEBAMAX

Tout à fait, c'est l'expérience utilisateur qui importe.

Côté construction, nous ne sommes clairement pas à quelques images près. Il suffit de regarder le nombre d'ISO générées, et la volumétrie totale :

138G    12.0.0
74G     12.0.0-live

Côté CPU, ça va :

CPU(s):                          88
Model name:                      Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz

Quant au temps de construction combiné (images d'installation + images live), nous sommes sous les six heures depuis quelques années…

(Plutôt 5 heures pour Bullseye, et désormais 3.5 heures pour Bookworm. Il y a plusieurs différences : la fin de unofficial/non-free est une petite partie, la fin de multi-arch une autre, la fin des images live pour i386 étant la principale.)

--
Cyril avec sa casquette « images team » (aka debian-cd) pour changer un peu de sa casquette « installer team » (aka debian-boot).

Debian Consultant @ DEBAMAX

ifupdown coche tes cases…

Debian Consultant @ DEBAMAX

Je me suis équipé il y a deux ans de l'écran suivant : AOC Moniteur U2790PQU 68 cm (27 pouces), pour 333 € HT.

Il sort jusqu'à 3840x2160 et j'en suis très content.

Je l'utilise en écran unique (celui de mon portable est en veille quand je suis docké), sous GNOME, avec un léger grossissement (Scaling Factor dans GNOME Tweaks).

Les raccourcis Super + ←, Super + →, Super + ↑ et Super + ↓ permettent respectivement de caler une fenêtre à gauche, à droite, en plein écran, ou restaurer les dimensions initiales. J'ai très souvent deux applications côte à côte, le plus souvent terminal et éditeur. Avec sur certains bureaux des applications plein écran (Firefox et LibreOffice, les rares fois où j'ai un peu de bureautique à faire).

Debian Consultant @ DEBAMAX

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