La théorie initiale d’un ancien dossier AppData obsolète était plausible, mais la publication finale la rend insuffisante. Les applications qui avaient déjà été supprimées ignoraient le formulaire de configuration et tentaient de réutiliser des chemins de montage inexistants, ce qui produisait des erreurs Docker telles que bind source path does not exist. Une réponse de la communauté suggérait de supprimer ou de renommer l’ancien dossier AppData afin que ZimaOS traite l’application comme une nouvelle installation.
L’auteur de la publication a ensuite indiqué que cette méthode avait fonctionné une fois, mais qu’elle n’était plus efficace. Plus important encore, les nouvelles applications installées pour la première fois ont elles aussi commencé à ignorer le formulaire de configuration et à rester bloquées à 100 %, tandis que l’installation d’applications via YAML fonctionnait toujours. Cela oriente davantage les soupçons vers le chemin historique de l’interface et de la configuration de l’App Store lui-même, plutôt que vers un seul répertoire d’application défectueux.
L’erreur Docker était réelle, mais secondaire
L’échec visible ressemblait à ceci :
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]Docker rejetait correctement un montage de type bind dont le répertoire source sur l’hôte n’existait pas. La question restée sans réponse était de savoir pourquoi l’App Store générait ou réutilisait ce chemin sans afficher le formulaire de configuration qui permet normalement à l’utilisateur de le choisir ou de le créer.
L’ancien AppData était une hypothèse de la communauté
gelbuilding a suggéré de supprimer ou de renommer /DATA/AppData/<app-name> afin que le magasin traite l’installation comme une nouvelle installation. Un autre membre de la communauté a indiqué avoir utilisé la même méthode.
Il ne s’agissait pas d’un diagnostic du personnel d’IceWhale, et le test effectué ultérieurement par l’auteur de la publication a montré que cette méthode ne suffisait pas à résoudre le problème général.
Le fait que les nouvelles applications ignorent également le formulaire modifie le diagnostic
Une fois constaté que de nouvelles applications, sans ancien AppData local, ignoraient elles aussi la configuration, la suppression répétée des anciens dossiers devenait une mauvaise approche de dépannage. L’utilisateur a explicitement indiqué que le redémarrage, la suppression du dossier et la réinstallation produisaient toujours le même résultat.
Le bon fonctionnement de l’installation YAML était un indice important
L’utilisateur a indiqué que les applications pouvaient toujours être installées depuis YAML. Cela suggère que Docker n’était pas complètement défaillant et oriente davantage le problème historique vers le flux de définition, de configuration ou d’affichage des applications du magasin.
ZimaOS 1.7 a repensé l’architecture de l’App Store
ZimaOS 1.7.0 a introduit l’App Store 2.0, avec une interface de découverte et de gestion repensée ainsi que la modification et l’analyse natives des fichiers YAML. ZimaOS 1.7.1 a ensuite ajouté d’autres correctifs liés à Docker, à AppData, à l’interface Web et à YAML.
Consultez la référence actuelle de l’App Store 2.0.
Ordre actuel des vérifications
- mettre à jour vers la version stable actuelle de ZimaOS ;
- tester une application officielle et simple qui n’a jamais été installée ;
- relever le chemin exact du montage hôte manquant ;
- vérifier si le dossier existe et à quel stockage il appartient ;
- vérifier si l’installation YAML réussit avec le même chemin prévu ;
- recueillir les journaux de l’App Store et des conteneurs si le formulaire de configuration échoue toujours.
Ne supprimez pas aveuglément AppData pour les applications avec état
Un dossier AppData peut contenir des bases de données, des configurations, des clés, des bibliothèques et des données utilisateur. Le renommer est plus sûr que le supprimer pendant les tests, et les données importantes doivent d’abord être sauvegardées.
FAQ sur l’absence du formulaire de configuration
La suppression de l’ancien AppData a-t-elle définitivement résolu le problème initial ?
Non. L’auteur de la publication a indiqué que cela avait fonctionné une fois, puis que la méthode avait cessé d’être efficace.
Les nouvelles applications ont-elles également été touchées ?
Oui. La publication source finale indique que les nouvelles applications ignoraient elles aussi le formulaire de configuration et restaient bloquées.
L’installation YAML fonctionnait-elle toujours ?
Oui. C’était l’un des indices les plus importants indiquant que le problème historique était lié au parcours de l’App Store, plutôt qu’à une indisponibilité complète de Docker.
