Boot & init

Au démarrage, l'OS charge le noyau depuis la partition FAT32, monte la racine ext4 puis lance les services leukOS via des scripts d'init SysV (BusyBox).

Séquence de démarrage

Les scripts sont exécutés dans l'ordre de leur préfixe numérique :

Ordre	Script	Rôle
1	S89wireguard	Monte le tunnel WireGuard si wg0.conf est configuré.
2	S90leukos-node	Démarre le daemon du node (automate local).
3	S91leukos-ui	Démarre l'IHM Qt sur le framebuffer.
4	S92leukos-hub	Démarre le service domotic local (si l'image l'inclut).

Le tunnel WireGuard est initialisé en amont si configuré, puis le node démarre avant l'IHM et avant le hub pour garantir la disponibilité du contrôle matériel.

Firmware du nano-ordinateur

• config.txt — configure les overlays matériels (écran, I2C, SPI…), la résolution et les options du firmware.
• cmdline.txt — passe les arguments au noyau (console, racine, etc.).

IHM sur framebuffer

L'IHM Qt s'affiche sans serveur graphique, directement sur le framebuffer :

QT_QPA_PLATFORM=linuxfb

Résolution cible 800 × 480.

Robustesse au premier démarrage

Le script nodes/os/board/leukos/rpi3plus/rootfs-overlay/etc/init.d/S91leukos-ui attend que le framebuffer soit réellement prêt (/dev/fb0 + virtual_size valide), puis attend un marqueur créé par l'application après sa première frame. Un processus Qt encore vivant mais bloqué sur un écran noir n'est donc plus déclaré sain après cinq secondes.

Le même comportement est aligné sur les variantes de nano-ordinateur rpi, rpi4 et rpi5.

• Délai de la première frame : LEUKOS_UI_READY_TIMEOUT_SEC (défaut : 180).
• Variable d'ajustement : LEUKOS_UI_START_ROUNDS (défaut : 2).
• Le fallback linuxfb_plain, redondant sur l'image actuelle, ne s'active que si LEUKOS_UI_ENABLE_PLAIN_LINUXFB_FALLBACK=1.
• Entre les tours, le script relance udevadm trigger (graphics/input) puis udevadm settle.
• Objectif : éviter un écran noir au premier boot lié à une course de disponibilité des périphériques.
• linuxfb gère seul les périphériques evdev : le script ne recharge plus evdevtouch comme plugin générique, ce qui évite la double prise exclusive du tactile.

Watchdog de relance contrôlé

Le démarrage applique aussi des garde-fous supplémentaires :

• Verrou de démarrage (/var/run/leukos-ui-start.lock) pour éviter les courses entre relances.
• Nettoyage des PID et verrous stale avant tentative de lancement.
• Boucles de relance bornées (LEUKOS_UI_MAX_RETRY_BURST, défaut 12) avec pause de refroidissement (LEUKOS_UI_RETRY_COOLDOWN_SEC, défaut 30).
• Pas de relance infinie si la signature d'erreur est permanente (ex: erreur QML Cannot assign to non-existent property, module Qt manquant, QQmlApplicationEngine failed).

Résolution selon la taille d'écran

Le lancement linuxfb adapte aussi la taille de rendu à la taille détectée du panneau :

• 5 pouces : 800x480 (ou 480x800 si framebuffer déjà en portrait).
• 7 pouces : 1024x600.
• Taille inconnue : conservation de la résolution du framebuffer fournie par le firmware.

Cette logique est alignée sur les overlays de nano-ordinateur rpi, rpi3plus, rpi4 et rpi5.

• Le rollback vers leukos-ui.bak.latest est volontairement inactif par défaut ; il faut définir LEUKOS_UI_AUTO_ROLLBACK=1 sur une installation qui gère explicitement cette sauvegarde.

Racine SSD sur nano-ordinateur 3 B+

La racine SSD reste sélectionnée avec root=/dev/sda2, avec rootwait et un délai initial de huit secondes. Cette configuration correspond au dernier état matériel connu comme amorçable sur le nano-ordinateur 3 B+ utilisé pour les essais.

Réseau

wpa_supplicant.conf (dans l'overlay) préconfigure le Wi-Fi (country=FR). Adaptez le SSID et la clé avant de flasher, ou reconfigurez après le premier démarrage.

Stockage des données

Sur la cible, les données persistantes vivent sous /var/lib/leukos :

Fichier	Contenu
/var/lib/leukos/node.db	État des relais, compteurs, et synchro desired/reported (sync_state).
/var/lib/leukos/hub.db	Données du service domotic local (si activé sur le node).
/var/lib/leukos/auth.db	Auth locale du service domotic (si activé).

La supervision centralisée de parc utilise un stockage séparé côté central :

• PostgreSQL pour auth + inventaire nodes,
• Elasticsearch pour logs nodes, exposé via l'API logs Python (central-mercure).

Broker MQTT

Mosquitto est lancé au démarrage et fournit le bus 127.0.0.1:1883 consommé par le daemon et le bridge du hub.