Suite à mon précédent article, voici une mise à jour sur les différentes possibilités pour faire tourner un serveur headless sur Olinuxino A64, et sur les difficultés que j’ai eues.

Depuis ce précédent article, Olimex a abandonné la distribution d’images basées sur Armbian, pour proposer à la place des images dites « mainline ».

Image mainline d’Olimex

Installation

Il s’agit de Debian Buster, mais avec un kernel très récent, et des patches et outils supplémentaires spécifiques à Olimex. Les dernières images se téléchargent depuis http://images.olimex.com/release/a64/ (ils ne laissent hélas que la dernière en téléchargement)

Il faut copier l’image sur la carte microSD, la mettre dans l’appareil puis démarrer dessus avec le câble de debug (voir mon précédent article).

On s’identifie la première fois avec le login root, et le mot de passe olimex.

Les premiers modèles d’Olinuxino A64 avaient tous la même adresse MAC (en tous cas les premiers que j’avais achetés). Dans ce cas, on peut choisir une autre adresse MAC en ajoutant hwaddress ether xx:xx:xx:xx:xx:xx dans /etc/network/interfaces.d/eth0 (en mettant l’adresse qu’on veut à la place des xx). Ce n’est apparemment plus nécessaire avec les modèles vendus actuellement.

Il y a parfois un problème avec l’interface réseau (qui ne fonctionne pas toujours après un reboot, à cause d’un conflit avec l’affichage). Ca se résout facilement : il faut lancer « sudo olinuxino-display », choisir disable puis rebooter (cf https://www.olimex.com/forum/index.php?msg=29820)

Je conseille ensuite de créer un autre utilisateur (adduser), puis changer le mot de passe de root (passwd), et définir le nouvel utilisateur comme sudoer : usermod -aG sudo nomduuser. Puis on peut se connecter en SSH.

Ensuite j’utilise Ansible pour finir d’initialiser l’appareil : https://gitlab.com/mossroy/ansible-role-init-a64 (il faut d’abord installer le package python3). C’est adapté à mon usage, donc toutes les étapes n’ont pas forcément de sens pour tout le monde, mais j’en conseille quand même certaines qui sont dans mon playbook :

• supprimer le user olimex qui existe par défaut (pour raison de sécurité)
• patcher une librairie Python pour que glances sache afficher les I/Os disque

Difficultés avec Olimex

J’ai eu pas mal de soucis avec ces images et/ou avec les mises à jour fournies par Olimex. Heureusement, ils ont tous été résolus depuis. J’apprécie beaucoup cette entreprise sur plusieurs aspects, mais leur communication et leur gestion des mises à jour logicielles ne sont pas au top.

Je leur reproche surtout des erreurs d’inattention, de ne pas toujours tester suffisamment, et de pas assez se soucier des mises à jour ultérieures pour les images déjà installées.

Leurs images sont configurées avec un repo apt fourni par Olimex (en plus des repos standards de Debian), et il y a eu pas mal de problèmes avec : certificat expiré, activation par erreur d’un autre repo de test en plus du repo normal, fourniture d’une mise à jour de kernel qui amenait une grosse régression.

D’autre part, en termes de communication, ils ne fournissaient pas de notes de version pour leurs différentes versions d’image : difficile de savoir ce qui a changé, ce à quoi il faudrait faire attention. Ils ne répondent pas toujours aux questions sur le forum, ou parfois de manière évasive.

Bref, j’ai fini par pousser mon coup de gueule sur leur forum. Ils ont promis de fournir des notes de version à l’avenir : c’est maintenant le cas, à l’adresse http://images.olimex.com/changelog.txt. Hélas, ils continuent à « fusionner » le changelog de certaines versions : certaines disparaissent du changelog quand elles sont rapidement remplacées par une autre.

J’espère aussi qu’ils vont être plus précautionneux sur les mises à jour fournies via leur repo.

Problème de « timer jump » du CPU Allwinner A64

Une des raisons pour lesquelles il y a eu des difficultés logicielles sur le kernel vient d’un bug matériel sur le CPU Allwinner A64 de cet appareil.

Sur les premières images, ils arrivait que la date/heure « saute » subitement d’une centaine d’année dans le futur. C’est bien un problème matériel du CPU qui en est la cause, et cela affecte tous les appareils utilisant ce CPU (pas uniquement ceux produits par Olimex).

Sur un serveur headless, cela a une conséquence grave : l’appareil perd complètement sa connectivité ethernet, et devient donc inaccessible par le réseau! Il faut donc se brancher dessus avec le câble de debug et corriger la date.

D’autre part, suivant ce que vous faites tourner dessus, ça peut avoir des conséquences encore plus fâcheuses. Notamment, sur une machine où je fais tourner Prometheus, cela corrompt les données : Prometheus étant un outil de collecte de données « time-series », il supporte très mal quand la date change comme ça (concrètement, il n’arrive plus à lire ses données et redémarre en boucle, je n’ai pas trouvé de moyen simple de réparer).

Heureusement, un contournement a été mis en place dans le kernel pour limiter ce phénomène, qui a été intégré dans la version 5.1 (ou 5.3?) du kernel.

Sauf qu’il y a eu une régression là-dessus dans une version 5.8.x du kernel, qui entraînait un gros ralentissement et une surconsommation CPU de l’appareil avec le governor « ondemand » (celui par défaut, qui permet d’ajuster la fréquence du CPU en fonction de la charge de la machine).

Depuis, les images Olimex récentes (avec le kernel 5.10.x) forcent le governor à « performance » : cela contourne apparemment le problème, mais force le CPU à rester à sa fréquence maximale (ce qui consomme et chauffe probablement plus)

Mais le principal est que je n’ai plus du tout de « timer jump », et depuis de nombreux mois.

Statut actuel

Mes serveurs fonctionnent bien, et sont maintenant stables : c’est le principal.

J’ai un peu peur que le governor « performance » pose des problèmes de surchauffe l’été, d’autant que les capteurs de température du CPU ne fonctionnent plus dans les derniers kernels d’Olimex.

Concernant la gestion logicielle d’Olimex, le problème finira par se résoudre tout seul quand le Debian-Installer supportera complètement l’appareil (voir ci-dessous). A ce moment-là, on ne dépendra plus des images et repos Olimex.

D’ici-là, un contournement est de ne pas installer trop rapidement les mises à jour proposées via les repos d’Olimex (notamment sur le kernel) : les tester d’abord quelques temps sur une machine avant de généraliser.

Image fournie par Armbian

Armbian continue de fournir des images pour cet appareil.

J’ai testé Armbian_21.02.1_Lime-a64_buster_current_5.10.12_minimal.img.xz. Le premier boot prend presque 10 minutes pendant lesquels est seulement affiché « Starting kernel… » : no stress, il faut patienter!

Apparemment il agrandit la partition, mais pas le filesystem, et fait des erreurs « no space left on device » quand il essaie de créer le user. Contournement : resize2fs /dev/mmcblk0p1 puis adduser puis usermod -aG sudo nomduuser

python3 est déjà installé mais il faut supprimer des répertoires de cache pour qu’Ansible fonctionne : j’ai dû supprimer tous les fichiers nommés __pycache__ (j’ai utilisé « sudo find / -name __pycache__ -exec rm -rf {} \; » mais il y a probablement moins bourrin)

Le governor est forcé à performance, mais le ondemand reste disponible (évidemment, on retombe sur le problème de consommation CPU si on active le ondemand).

Le démarrage reste très long (autour de 10 minutes). Et surtout il m’a été impossible de redémarrer programmatiquement.

Bref, ça ne m’a pas paru utilisable.

Debian-installer

Debian Bullseye est passé sur le kernel 5.10, qui a le support complet de l’appareil, sur le papier. Y compris le chiffrement AES matériel (depuis la version 5.5).

L’installeur peut être téléchargé sur https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ (il s’agit d’images quotidiennes, car Bullseye n’est pas encore sorti).

J’ai testé la version du 27/04/2021 (et quelques autres avant). L’installation se passe normalement. A la fin, il n’arrive pas à rebooter tout seul donc il faut le débrancher/rebrancher.

Mais ensuite il reste bloqué au démarrage sur « Starting kernel … » : impossible de se logger dessus.

Bref, pour l’instant ça ne fonctionne pas « out of the box ».

J’ai fait un post là-dessus sur le forum d’Olimex : https://www.olimex.com/forum/index.php?topic=8111.0

Essais de contournement

J’ai fini par réussir à faire démarrer mon serveur en faisant ce qui suit. Attention, ce n’est que du bricolage pour investiguer, pas une solution propre/pérenne!

• copier les fichiers /usr/lib/linux-image-5.10.23-olimex/allwinner/sun50i-a64-olinuxino-2Ge8G.dtb et /usr/lib/olinuxino-overlays/sun50i-a64/sun50i-a64-i2c0.dtbo depuis l’image d’Olimex dans le répertoire /dtbs/5.10.0-6-arm64/allwinner de la partition de boot du debian installé
• regénérer le fichier boot.scr sans le « quiet », pour voir les logs de démarrage. Il faut pour cela copier le boot.scr en boot.txt, y enlever la première ligne (qui a du contenu binaire) ainsi que le paramètre de démarrage « quiet », puis lancer la commande « sudo mkimage -A arm64 -O linux -T script -C none -n « My Boot » -d /path/to/boot.txt /path/to/boot.scr »
• interrompre le processus de démarrage de u-boot (en appuyant sur une touche quand on y est invité), et ajouter les variables d’environnement u-boot suivantes :

setenv bootargs earlycon
setenv fdtfile allwinner/sun50i-a64-olinuxino-2Ge8G.dtb
setenv fdtoverlays /dtbs/5.10.0-6-arm64/allwinner/sun50i-a64-i2c0.dtbo
saveenv

Avec ça, la machine démarre. Enfin, elle démarre autour d’une fois sur 2 ou 3… Il doit y avoir un facteur aléatoire, et les plantages semblent toujours liés à des problèmes d’accès à la carte microSD (mmc). J’ai pourtant essayé avec 2 cartes SD différentes.

Je n’ai pas remarqué de problème de timer jump, mais n’ai pas pu tester très longtemps. Le governor par défaut est schedutil. Le reboot ne fonctionne jamais : la machine s’arrête mais ne redémarre pas (il faut la débrancher/rebrancher).

Dans les autres petits soucis, le chiffrement matériel n’est actif que pour l’aes-xts (pas l’aes-cbc, qui fonctionne bien plus lentement d’après un « cryptsetup benchmark »), et l’installation de cryptsetup génère des messages d’erreurs « Unsupported platform ‘Olimex A64-Olinuxino-2Ge8G-IND' » (mais c’est probablement à cause de ma bidouille pas très propre)

Echanges avec l’équipe linux-sunxi

J’ai brièvement discuté de tout ça sur IRC avec des gens de linux-sunxi (qui s’occupent d’ajouter progressivement le support des fonctionnalités des CPUs Allwinner dans le kernel upstream). C’est d’ailleurs eux qui m’ont aidé à faire démarrer l’appareil avec debian-installer.

Ils semblaient découvrir les fichiers dtb/dtbo fournis par Olimex (et leurs contenus), et regrettaient que ces changements n’aient pas été remontés, ou discutés avec eux, par Olimex, dans l’objectif de les intégrer dans le kernel upstream. Même chose pour des patchs supplémentaires liés au timer jump qu’Olimex a appliqués, et qui ne sont pas upstream.

Tout le code d’Olimex est bien public, sur leurs repos github, mais il semblerait manquer un peu de communication entre les 2 équipes.

J’ai proposé ma modeste aide aux personnes de linux-sunxi, puis à Olimex (en organisant par exemple une réunion tous ensemble). Mais ça n’a pas trouvé echo…

Pourtant je suis persuadé que tout le monde aurait à y gagner :

• Olimex n’aurait plus à maintenir ses patchs s’ils sont intégrés upstream, et bénéficierait des compétences des équipes linux-sunxi
• Les utilisateurs auraient le choix entre utiliser les images d’Olimex/Armbian ou installer eux-mêmes leur distribution linux favorite (via le debian-installer par exemple, mais il pourrait s’agir d’autres distributions linux)
• Le résultat bénéficierait à tous les appareils basés sur le même CPU
• Ca permettrait probablement à des distributions spécialisées de supporter officiellement cet appareil, comme LibreElec, plutôt que des compilations non officielles (et non maintenues) d’Olimex ou d’utilisateurs.

Le frein semble organisationnel/humain, et non technique.

Conclusion

Je pensais que, plus de deux ans après avoir acheté mes appareils, tout marcherait nickel et facilement (comme ça avait été le cas avec les Olinuxino A20). Ça a été bien plus compliqué que ça.

Cela dit, tous mes appareils sont maintenant stables (en utilisant l’image d’Olimex), avec les quelques étapes et précautions citées ci-dessus.

J’attends impatiemment que le Debian-installer supporte complètement l’appareil : ça permettra d’avoir une Debian « propre », et plus de stabilité sur les mises à jour.