Cyril Brulebois a écrit 670 commentaires

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

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