fix: ce que l installateur pose atteint enfin le système qui tourne

[NLygitadm]

Trois remontées de testeurs le 09/09/2026. Même famille : le choix est bien enregistré, mais personne ne le rejoue là où il compte.

1. La rotation du playfield — Flo

Réglage écran ok pendant l'installation mais après reboot sur le dd ça n'a pas suivi

pincabos-screen-hotplug est la seule unité qui applique playfield_rotation depuis screens.json :

xrandr --output "$output" --mode "$mode" --pos "$pos" --rotate "${rotate:-normal}"

Elle n'était démarrée que par une règle udev :

ACTION=="change", SUBSYSTEM=="drm", RUN+="systemctl start pincabos-screen-hotplug.service"

Son .service n'avait pas de section [Install] : aucune cible ne la démarrait. Au démarrage, écrans déjà branchés, les connecteurs sont énumérés en add — l'événement change ne vient jamais. La rotation choisie dans l'assistant n'était donc jamais appliquée après le reboot.

L'ordre était déjà prévu pour le boot (After=pincabos-screen-topology-boot, posé en 4.32 quand le verrou du hotplug bloquait le frontend). Il ne manquait que le déclenchement.

2. Le ZeDMD — Flo

J'ai fait la config IP de mon zedmd pendant l'installation mais il n'est pas actif sous vpinfe

L'installateur appliquait la configuration depuis le chroot du média :

chroot "$TARGET" runuser -u pinball -- /opt/pincabos/tools/pincabos-zedmd apply || true

Pas de réseau final, pas de périphérique, et un || true qui avalait l'échec. Un ZeDMD en Wi-Fi ne pouvait pas y répondre.

On ne pose plus que le drapeau. pincabos-dmd-installer.service rejoue au premier démarrage et conserve le drapeau tant que l'application échoue : il retente aux démarrages suivants.

3. Aucune table ne démarre — Patrick

mv: cannot move '/home/pinball/.local/share/VPinballX/10.8'
    to '/home/pinball/.pincabos/vpx': Permission denied
code de sortie : 1

Renommer un dossier demande le droit d'écriture sur le parent. Sur une installation neuve il appartenait à root : le mv échouait, set -Eeuo pipefail tuait le lanceur, VPX ne démarrait jamais.

Et le journal du lanceur ne montrait rien d'anormal :

21:55:25  LEGACY [▶] Lancement Original direct.
21:55:25  RETOUR [=] frontend VPinFE reactive

Deux corrections :

• le chown de l'installateur couvre maintenant /home/pinball — il s'arrêtait à /opt (#277) ;
• la migration des préférences ne peut plus tuer le lanceur : quand elle échoue, on continue avec l'ancien dossier, en le disant.

Et le lanceur parle enfin. Seul le code 139 (SIGSEGV → repli OpenGL) était traité ; tout autre échec repartait en silence. Un retour non nul en moins de cinq secondes est désormais journalisé avec son code. C'est exactement ce qui manquait pour diagnostiquer.

Au passage

test_dof_port_famille (livré en #279) faisait m.glob.glob = ... — ce qui remplace glob.glob dans tout le processus, pas seulement dans le module testé. Deux tests sans rapport échouaient à retardement en recevant des listes vides. Corrigé avec un SimpleNamespace, et le piège est expliqué dans le code pour la prochaine fois.

Tests

test_installation_atteint.py, 13 tests. test_installer_dmd a correctement échoué quand j'ai retiré l'application dans le chroot — il l'épinglait ; il est mis à jour.

723 tests, tout au vert.

🤖 Generated with Claude Code