Le temps passe vite en informatique, et la durée de vie des produits ou du matériel encore plus.
J’avais acheté mon Odroid-HC2 et installé OMV V5 en 2020. Quatre ans plus tard, si tout fonctionne encore, je recevais quotidiennement des mails m’informant que la mise à jour système avait échouée :
CRON-APT RUN [/etc/cron-apt/config]: Tue Mar 5 07:05:30 CET 2024
CRON-APT SLEEP: 2353, Tue Mar 5 07:44:43 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get update -o quiet=2
E: The repository 'http://apt.armbian.com buster Release' does not have a Release file.
En regardant tout ça de plus près, je me suis rendu compte que plus rien n’était supporté : ni le matériel, ni l’OS, pas plus que la version d’OpenMediaVault ! Il était temps de faire quelque chose…
Obsolescence
Je vois que le dépot armbian pour Buster (soit Debian 10) n’existe effectivement plus. Une petite vérification côté Debian me montre que la version Buster ne sera plus supporté le 20 juin 2024. Les équipes d’armbian ont donc juste un peu d’avance, sans doute parce que leurs ressources sont limitées.
Rien d’alarmant, je pourrais rester en l’état (tant que ça marche…), mais ce n’est jamais une très bonne solution, je fais donc un peu de recherches complémentaires. Et je m’aperçois qu’OMV5 est également passé en End Of Life depuis juin 2022.
Côté matériel, ce n’est pas mieux : ma carte Odroid-HC2 est elle aussi passée en « Obsoleted Product », et il n’y a plus d’images de fournies pour Debian v11 ou même v12… La page armbian n’affiche même plus de modèles Odroid pour une architecture armhf ! Je vous le dis, le temps passe vite et en 4 ans, plus rien n’est supporté ! 😮
Ma seule option est alors de faire une mise à jour d’OMV5 vers OMV6 pour passer à Debian 11.
Suppression des mails
Mais dans un premier temps, comme cela me fatiguait de recevoir un mail d’erreur tous les matins, j’ai commencé par mettre en commentaire le lien pointant sur le dépôt en question dans le fichier /etc/apt/sources.list.d/armbian.list :
$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop
Cela a fonctionné, mais j’ai alors reçu un autre mail quotidien concernant le dépôt de plugins :
CRON-APT RUN [/etc/cron-apt/config]: Sun Mar 17 07:37:59 CET 2024
CRON-APT SLEEP: 1502, Sun Mar 17 08:03:01 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get update -o quiet=2
E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/usul buster Release' does not have a Release file.
Et donc même façon de résoudre le problème, je commente la ligne dans /etc/apt/sources.list.d/omvextras.list :
$ cat /etc/apt/sources.list.d/omvextras.list
# deb https://dl.bintray.com/openmediavault-plugin-developers/usul buster main
Mise à jour OMV6
Bon, je savais que tout cela devait être temporaire, et je me décide pour faire une mise à jour d’OMV5 vers OMV6.
Prudent, je commence par faire une image de ma carte microSD avec Clonezilla histoire de pouvoir revenir en arrière si la mise à jour plante, car je ne souhaite pas me retrouver bloqué sans serveur Plex, Nextcloud ou Qbittorrent…
Puis je lance la commande suivante pour m’assurer que tout est à jour :
$ sudo omv-upgrade
Huit paquets sont d’ailleurs mis à jour, parfait. J’enchaîne avec la véritable commande de mise à jour vers OMV6 et Debian 11. En fait les deux sont liés, chaque version d’OMV est associée à une version de Debian, et le script de mise à jour en tient compte bien sûr.
$ sudo omv-release-upgrade
La fenêtre suivante s’affiche :
Je valide, et la mise à jour démarre. Cela prend du temps, mais à la fin le système redémarre et je découvre la nouvelle interface d’OMV6, dont un écran de connexion inspiré de Matrix du plus bel effet :
Sauf que je m’aperçois que tout ce qui concerne les plugins a été totalement revu et profondément modifié. Et de ce fait, je n’ai aucun plugin d’installé, et bien sûr aucun de mes conteneurs Docker ne fonctionne.
Je commence à regarder tout ça, à chercher un tuto sur internet, et puis je me dis que dans ces conditions, autant en profiter pour passer à OMV7. Il sera toujours temps de refaire la configuration des plugins ensuite, et j’aurai une version très récente d’Openmediavault, puisque cette version date du 03 mars 2024.
Aussitôt dit aussitôt fait, un coup de omv-upgrade suivi d’un omv-release-upgrade et me voilà en OMV7 sous Debian 12 Bookworm. 😎
Configuration
Je me retrouve donc au même point qu’avec OMV6 : aucun plugin d’installé. Il faut commencer par installer les OMV Extras en téléchargeant un script comme indiqué sur cette page :
$ sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash
Pour ma part, j’ai du d’abord télécharger le fichier, puis l’exécuter, le « pipe » sur bash ne fonctionnait pas. Donc cette commande :
$ sudo wget https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install
Puis je renomme le fichier en installomvextra.sh et lance le script, qui extrait un fichier openmediavault-omvextrasorg_latest_all7.deb puis procède à l’installation.
Voilà, nos plugins sont désormais disponibles, et pour Docker, il faut installer openmediavault-compose dans Système-Extensions :
À ce stade, j’ai un beau menu dans Services-Compose qui me remplit d’espoir : Docker a l’air beaucoup mieux intégré à l’interface d’OMV, on y retrouve directement les containers par exemple, mais pas que :
Mais quand je vais dans Conteneur, si je vois bien mes conteneurs (c’est déjà ça), il sont tous à l’arrêt et refusent de démarrer. Il faut d’abord aller dans Shared Folders, vérifier que tout est correct et corriger ce qui ne l’est pas.
Puis aller dans Compose – Paramètres vérifier les deux entrées suivantes qui correspondent aux données des containers créés (Compose Files), et à l’emplacement de Docker (j’avais déplacé Docker sur le disque externe du NAS, voir cet article).
Une fois tout ceci vérifié, j’essaie à nouveau de démarrer un container, et nouvel échec ! Le message d’erreur n’est pas évident, si ce n’est que le container ne peut être démarré, et un beau « function not implemented » :
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown in /usr/share/openmediavault/engined/rpc/compose.inc:1080
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(622): OMVRpcServiceCompose->{closure}()
#1 /usr/share/openmediavault/engined/rpc/compose.inc(1068): OMV\Rpc\ServiceAbstract->execBgProc()
#2 [internal function]: OMVRpcServiceCompose->doContainerCommand()
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(122): call_user_func_array()
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
#5 /usr/sbin/omv-engined(535): OMV\Rpc\Rpc::call()
#6 {main}
Le Kernel
Je fais alors une recherche sur internet, et je dois dire que je suis assez chanceux, car je tombe immédiatement sur cette page, qui indique que le problème vient d’une version de kernel trop ancienne.
Je vérifie sur ma machine et effectivement, mon kernel ne semble pas à niveau :
$ uname -a
Linux odroidhc2 4.14.222-odroidxu4 #1 SMP PREEMPT Mon Nov 22 12:13:27 UTC 2021 armv7l GNU/Linux
$
$ sudo docker info
...
Kernel Version: 4.14.222-odroidxu4
...
$
Mon premier réflexe est d’aller voir le fichier que j’avais modifié manuellement pour éviter le premier mail : il est toujours en l’état avec le ligne pour Buster commentée, j’y ajoute la ligne qui correspond à ma nouvelle version de Debian :
$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop
deb http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop
$
Puis je lance une mise à jour, et je vois que 3 paquets vont être mis à jour : armbian-config armbian-firmware base-files. Mais cela ne change pas la version du kernel, et ne résout pas mon problème.
Pour identifier le kernel à installer, la commande suivante permet de les afficher :
$ sudo apt-cache search linux-image | grep odroid
linux-image-current-odroidxu4 - Armbian Linux current kernel image 6.1.79-current-odroidxu4
linux-image-edge-odroidxu4 - Armbian Linux edge kernel image 6.1.77-edge-odroidxu4
linux-image-legacy-odroidxu4 - Linux kernel, version 4.14.222-odroidxu4
Et j’ai déjà vu lors de l’installation de la première image que ma carte odroid-hc2 utilise la même image que celle d’un odroid-xu4 : voir cet article sur le changement du motd ! 😉 . À priori, il faudrait prendre le « current ». Mais bon j’ai quand même quelques interrogations, je n’ai jamais fait cette opération, et évidemment il n’y a pas le droit à l’erreur…
Mais internet va me fournir une solution alternative, avec un outil armbian dédié pour configurer les cartes ARM, et qu’il suffit d’installer :
$ sudo apt-get install armbian-config
Il ne reste plus qu’à le lancer en mode sudo, puis de choisir System, et enfin de sélectionner Switch to other kernels :
Il ne reste plus qu’à laisser l’outil récupérer les versions disponibles, et choisir parmi celles qu’il vous propose : et l’outil me propose bien la même version de kernel que la commande apt, cela me rassure. Je valide, et le nouveau kernel est installé avant que le système ne redémarre :
Après le redémarrage, je vérifie et cette fois mon kernel est passé en version 6 :
$ uname -a
Linux odroidhc2 6.1.79-current-odroidxu4 #3 SMP PREEMPT Thu Feb 8 13:10:24 UTC 2024 armv7l GNU/Linux
Voici venu le moment décisif : je retourne dans Services - Compose - Conteneurs pour démarrer un container Docker, et YES ! il démarre sans aucun problème… 😛
Conclusion
La mise à jour d’OMV s’est tout de même très bien passée, puisque j’ai quand même fait un saut de 2 versions majeures où la gestion des plugins a été complètement revues et modifiée, tout en incluant une mise à jour de l’OS (Debian 10 à Debian 12).
Ce n’était donc pas une mince affaire, et finalement, je n’ai eu que quelques paramètres à vérifier côté purement OMV. Pour la version de Kernel, c’était un peu plus compliqué à priori, mais l’utilitaire fourni par armbian a parfaitement rempli sa fonction et résolu mon problème en quelques minutes.
Voilà, il me reste à découvrir un peu mieux cette nouvelle version d’OMV. À priori, je n’aurai sans doute plus besoin de la page Portainer pour gérer mes conteneurs, tout semble gérable à partir de l’interface d’OMV7. Et je suis normalement tranquille pour quelques années de support ! 😎