Cyril Brulebois a écrit 690 commentaires

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

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