EXP C10 — Armbian : la configuration devient reproductible
EXP C10 — Armbian : la configuration devient reproductible
Après plusieurs épisodes avec Raspberry Pi OS Bookworm, nous avions fini par obtenir un serveur d’impression fonctionnel. La Canon LBP-810 imprimait, CUPS fonctionnait, Avahi annonçait le service et les clients Windows et Kubuntu pouvaient envoyer leurs travaux.
Mais il restait un problème important : la stabilité du réseau Wi-Fi.
Nous avions observé avec Bookworm des pertes de connectivité intermittentes, avec des séquences de déconnexion et de réassociation. Malgré différents contrôles, nous n’avions pas réussi à identifier avec certitude le composant responsable.
Plutôt que de continuer à modifier une installation déjà complexe, nous avons donc changé de méthode :
conserver exactement le même Raspberry Pi Zero 2 W, mais changer complètement de système.
Changer de terrain sans changer de matériel.
En cherchant une distribution adaptée au Raspberry Pi Zero 2 W, nous avons découvert qu’Armbian proposait explicitement des images pour cette carte.
Plusieurs possibilités étaient disponibles, notamment :
- Armbian Debian 13 Minimal
- Armbian Ubuntu 26.04 Minimal
Nous avons choisi de commencer par :
Armbian Ubuntu 26.04 Minimal / CLI
Le choix n’était pas destiné à démontrer qu’Ubuntu était « meilleur » que Debian ou que Bookworm était mauvais. Nous voulions simplement introduire suffisamment de différences pour obtenir une comparaison réellement intéressante.
Et surtout, nous voulions conserver la même expérience matérielle :
Same Raspberry Pi Zero 2 W Same power supply Same Wi-Fi network Same printer Same local environment Only the system changes.
Dans notre installation, nous avons alors changé plusieurs éléments à la fois : architecture, noyau et pile réseau. C’est important pour interpréter correctement les résultats : nous ne pouvons pas attribuer à un composant unique la différence observée.
Premier objectif : le Wi-Fi avant toute chose.
Nous avons volontairement résisté à la tentation d’installer immédiatement CUPS, Avahi et CAPT.
Le premier test devait être beaucoup plus simple :
Armbian ↓ Wi-Fi ↓ SSH ↓ stability
Pas de modification du réseau. Pas de réglage expérimental supplémentaire. Pas de ping continu destiné à maintenir artificiellement l’activité réseau.
Nous voulions simplement voir comment la Pi se comportait lorsqu’elle était laissée tranquille.
Le premier démarrage.
La Raspberry Pi Zero 2 W a démarré avec :
Armbian 26.8.3 Ubuntu 26.04 aarch64
Le Wi-Fi était immédiatement opérationnel :
wlan0 192.168.1.40/24
Un changement d’architecture apparaissait immédiatement par rapport à notre installation Bookworm :
Bookworm → armv7l Armbian → aarch64
Dans notre installation Armbian, la gestion du réseau reposait également sur systemd-networkd.
Nous avions donc changé plusieurs variables. Mais pour une expérience comparative, c’était précisément ce que nous voulions observer.
Et maintenant… on attend.
Le moment le plus intéressant a été celui où nous avons décidé de ne plus toucher à rien.
Armbian + Wi-Fi + time
Le temps était devenu notre véritable instrument de mesure.
Avec Bookworm, nous avions constaté des pertes de connectivité après certaines périodes d’inactivité. Avec Armbian, nous avons donc laissé le Raspberry fonctionner dans des conditions normales, sans ping permanent et sans modification destinée à « aider » le réseau.
Le résultat a été rapidement encourageant.
À 20:36, la Pi était toujours joignable alors que nous l’avions installée dans la matinée. Le serveur n’avait pas été maintenu artificiellement par un ping continu, aucun tweak supplémentaire n’avait été appliqué et aucun redémarrage n’avait été nécessaire.
Mais un serveur d’impression doit imprimer.
Une meilleure stabilité réseau n’aurait pas suffi. Nous devions maintenant reconstruire exactement le service qui nous intéressait depuis le début :
Armbian ↓ CUPS ↓ Avahi ↓ CAPT 0.1 ↓ /dev/usb/lp0 ↓ Canon LBP-810
Cette fois, le chemin était beaucoup plus simple à reconstruire puisque nous connaissions déjà tous les éléments nécessaires.
Nous avons retrouvé notre pilote CAPT 0.1, son PPD Canon et la configuration CUPS qui avait déjà permis de faire fonctionner la LBP-810.
La configuration retenue a notamment conservé :
Canon LBP-810 Foomatic/capt (recommended) device-uri=file:///dev/null
Le serveur a alors retrouvé sa chaîne d’impression complète :
Windows / Kubuntu
↓
IPP
↓
Armbian Ubuntu 26.04
↓
CUPS
↓
Foomatic
↓
CAPT
↓
/dev/usb/lp0
↓
Canon LBP-810La Canon imprime à nouveau.
La première page est sortie proprement, avec les bonnes dimensions.
Nous avions donc à nouveau validé toute la chaîne :
Armbian Ubuntu 26.04
↓
systemd-networkd / Wi-Fi
↓
CUPS
↓
Foomatic + CAPT 0.1
↓
file:///dev/null
↓
/dev/usb/lp0
↓
Canon LBP-810
↓
🖨️ impression réelleWindows a fonctionné via IPP et la file IPP existante de Kubuntu a continué à fonctionner. Le client reste donc relativement générique : toute la complexité spécifique à cette vieille Canon reste concentrée sur le Raspberry Pi.
Le test le plus important : laisser vivre le serveur.
Une fois les impressions validées, nous avons à nouveau arrêté les tests artificiels.
No continuous ping. No tweak. No unnecessary reboot. Simply: Wi-Fi + CUPS + Avahi + CAPT + Canon.
L’observation s’est alors prolongée.
La différence par rapport à Bookworm devenait de plus en plus intéressante :
Bookworm → Wi-Fi drops → disconnections → supplicant-timeout Armbian Ubuntu 26.04 → stable Wi-Fi → CUPS operational → Windows printing → Kubuntu printing
Il faut cependant conserver une conclusion techniquement honnête.
Nous ne pouvons pas démontrer que NetworkManager, le noyau ou un autre composant précis était seul responsable des problèmes rencontrés avec Bookworm. Plusieurs variables ont changé entre les deux installations.
En revanche, nous pouvons dire quelque chose de beaucoup plus solide :
sur le même Raspberry Pi Zero 2 W, dans le même environnement physique et réseau, Armbian a fourni une stabilité Wi-Fi nettement meilleure dans notre expérience.
Le moment où l’expérience change de nature.
Jusqu’ici, nous cherchions à faire fonctionner la Canon.
Maintenant, nous avions obtenu quelque chose de plus intéressant :
une configuration fonctionnelle que nous pouvions conserver comme référence.
Le serveur tournait sous :
Armbian 26.8.3 Ubuntu 26.04 kernel 6.18.44 aarch64 systemd-networkd wpa_supplicant CUPS Avahi CAPT 0.1 Canon LBP-810 IPP Windows IPP Kubuntu
Nous pouvions donc passer à l’étape suivante :
working
↓
stable
↓
backed up
↓
reproduciblePréparer l’image de référence.
À ce stade, nous ne voulions plus simplement conserver une configuration fonctionnelle : nous voulions pouvoir en capturer l’état exact.
Nous avons donc arrêté proprement le Raspberry Pi et récupéré sa micro-SD sous Kubuntu/Linux.
Pour réaliser l’image complète du support, nous avons utilisé USBImager 1.0.10.
L’objectif était de travailler sur le disque entier, et non de copier séparément les partitions :
micro-SD ↓ raw image of the full disk ↓ Zstandard compression ↓ archive file
La lecture a été effectuée avec vérification activée. Nous disposions ainsi d’une image complète pouvant ensuite être utilisée pour une véritable expérience de restauration.
À ce stade, nous avions enfin tous les éléments nécessaires pour tenter quelque chose de plus exigeant :
ne plus seulement sauvegarder le serveur, mais vérifier que cette sauvegarde permet réellement de le reconstruire.
État final de l’expérience :
| Élément | État |
|---|---|
| Raspberry Pi Zero 2 W | 🟢 |
| Armbian Ubuntu 26.04 | 🟢 |
| aarch64 | 🟢 |
| Wi-Fi | 🟢 |
| systemd-networkd | 🟢 |
| CUPS | 🟢 |
| Avahi | 🟢 |
| CAPT 0.1 | 🟢 |
| Canon LBP-810 | 🟢 |
| Windows / IPP | 🟢 |
| Kubuntu / IPP | 🟢 |
| Impression réelle | 🟢 |
| Image de référence | 🟢 |
| Restauration vérifiée | 🟡 |
La vraie réussite :
Au début de cette série, l’objectif était simplement de répondre à une question :
Est-il encore possible de faire fonctionner une Canon LBP-810 sur un réseau moderne ?
Nous avons finalement obtenu beaucoup plus.
Nous avons construit un véritable serveur d’impression autour d’un Raspberry Pi Zero 2 W, avec CUPS, Avahi et le vieux pilote CAPT, puis nous avons permis à Windows et Kubuntu d’imprimer dessus par IPP.
Nous avons ensuite rencontré un problème de stabilité Wi-Fi, changé de plateforme sans changer de matériel et découvert qu’Armbian fournissait une base beaucoup plus convaincante pour notre serveur.
Enfin, nous avons capturé cette configuration sous forme d’une image complète réalisée sous Linux, avec USBImager.
Le projet est donc passé de :
« Works on my machine. »
↓
« Works reliably. »
↓
« We can save this exact state. »
↓
« We still need to prove that we can rebuild it. »Conclusion :
L’expérience Armbian est réussie.
Depuis son installation, le Raspberry Pi Zero 2 W fonctionne dans son environnement réel de serveur d’impression. Il n’a pas eu besoin d’un ping permanent pour rester opérationnel et nous avons obtenu les validations nécessaires pour Windows, Kubuntu et la Canon LBP-810.
Surtout, nous avons maintenant une image complète de référence réalisée sous Linux, avec laquelle nous pouvons tenter une restauration réelle.
Le serveur fonctionne. Nous savons désormais quel état nous voulons préserver.
Mais une sauvegarde n’est pas encore une preuve de reproductibilité.
À suivre …
(11) — Restaurer le Gold Master : peut-on reconstruire le serveur ?
Une image de sauvegarde est utile.
Une image restaurée avec succès est encore plus intéressante.
Nous allons donc prendre une autre micro-SD et tenter de reconstruire le serveur à partir de notre image de référence.
Reference image
↓
new micro-SD
↓
restore
↓
boot
↓
Wi-Fi
↓
CUPS + Avahi + CAPT
↓
Canon LBP-810
↓
Windows / Kubuntu
↓
printingParce qu’il existe une différence fondamentale entre avoir une sauvegarde et être capable de reconstruire son serveur.
AxehGo & DebIA — Independent Research & Experiments in Linux, AI and Statistical Computing
// discussion
No comments