Dépannage

1. Cliquez sur Informations complémentaires, puis Exécuter quand même. L'écran signifie que l'installateur n'est pas encore signé, pas qu'il est dangereux.
2. Pour être sûr de ce que vous lancez : comparez le SHA-256 du fichier avec celui publié à côté de la version (Get-FileHash .\Solon_x.y.z_x64-setup.exe dans PowerShell). La page d'accueil l'affiche aussi.
3. Certains antivirus mettent en quarantaine les installateurs non signés : restaurez le fichier et ajoutez une exception avant de le relancer.

Une signature via la SignPath Foundation a été demandée ; les versions seront signées dès l'acceptation du projet, et cet écran disparaîtra.

1. Redémarrez d'abord. L'installateur active Hyper-V et la Plateforme de machine virtuelle s'ils étaient éteints ; ils ne fonctionnent qu'après un redémarrage. La plupart des échecs du premier démarrage s'arrêtent là.
2. Code VIRTUALIZATION_DISABLED_IN_FIRMWARE : activez la virtualisation matérielle dans le BIOS/UEFI (Intel VT-x, AMD-V ou SVM, en général sous Advanced, CPU ou Security), enregistrez, redémarrez.
3. Windows Famille est pris en charge depuis 0.1.12 : l'installateur active la Plateforme de machine virtuelle et demande un redémarrage. Il faut Windows 10 22H2 ou 11, toutes éditions.
4. Code HYPERVISOR_NOT_RUNNING : un vieux VirtualBox ou VMware, ou un réglage bcdedit, a éteint l'hyperviseur Windows. Retirez-les ou mettez-les à jour (VirtualBox ≥ 6.1, VMware ≥ 15.5), puis en PowerShell administrateur : bcdedit /set hypervisorlaunchtype auto et redémarrez.
5. Toujours bloqué : Réglages → Diagnostic → Exporter un diagnostic, et ouvrez un rapport avec le zip (voir plus bas).

1. Un autre programme (une autre pile, IIS, un serveur de développement, Docker Desktop) écoute déjà sur ce port. Solon nomme le port et propose le suivant libre : cliquez sur Utiliser 8081 au lieu de 8080 dans la galerie, ou dans l'onglet Compose du projet changez le port hôte (le nombre de gauche dans "8080:80") puis Save and Up.
2. Vous n'avez peut-être pas besoin de publier un port : chaque conteneur répond sur https://<nom>.solon.local, port ou pas. Commentez les lignes ports: et utilisez cette adresse.
3. Deux exemplaires de la même pile (deux WordPress, deux Odoo) se heurtent toujours sur le même port : donnez un autre port hôte au second, ou retirez les ports et utilisez les deux adresses solon.local.

1. C'est normal pour un programme qui fait son travail et se termine : hello-world affiche son message et sort en un dixième de seconde. Solon ouvre ses journaux et indique « terminé aussitôt avec le code 0 » ; le message est dans l'onglet Logs.
2. Un serveur qui sort avec un code non nul est un vrai échec : lisez les dernières lignes de ses journaux (onglet Logs, ou docker logs <nom>). Les causes habituelles : une variable d'environnement manquante, un chemin de volume faux, un port que le conteneur lui-même ne peut pas ouvrir.
3. Un conteneur que Solon a endormi (icône lune) n'est pas arrêté : la requête suivante le réveille. Utilisez Keep awake sur sa page s'il exécute des tâches planifiées.

1. VPN d'entreprise. Certains clients VPN (AnyConnect, GlobalProtect, Zscaler) bloquent le trafic des cartes virtuelles. Déconnectez le VPN et réessayez ; si ça marche, indiquez-le dans votre rapport pour qu'un contournement soit trouvé.
2. L'adresse. Un conteneur n'a une adresse que pendant qu'il tourne ; le nom est celui du conteneur (web.solon.local) ou service.projet.solon.local pour Compose. Ouvrez http://nimportequoi.solon.local : la page liste toutes les adresses disponibles.
3. Le certificat. Les navigateurs et .NET reconnaissent les certificats locaux. curl.exe sur Windows a besoin de --ssl-no-revoke, comme avec mkcert.
4. Des liens en http://. WordPress, Nextcloud et compagnie construisent leurs liens à partir de la requête : Solon transmet X-Forwarded-Proto: https, que les images officielles respectent. Pour un WordPress déjà installé en http, changez l'adresse du site dans Réglages → Général.
5. Le fichier hosts. Solon écrit les noms dans C:\Windows\System32\drivers\etc\hosts entre # solon-begin et # solon-end. Un produit de sécurité qui protège ce fichier bloque les adresses : autorisez Solon ou ajoutez les noms à la main.

1. Solon garde tout dans un seul fichier, %ProgramData%\Solon\data.vhdx, qui grossit avec les images, conteneurs et volumes et ne se réduit qu'après un nettoyage.
2. Réglages → Disque → Récupérer l'espace : supprime les images qu'aucun conteneur n'utilise et le cache de construction, puis rend l'espace libéré à Windows. Les conteneurs et les volumes ne sont jamais touchés.
3. Toujours gros ? Images → « Inutilisées seulement » montre ce qui reste ; Volumes → « Inutilisés seulement » montre les volumes qu'aucun conteneur ne référence (des données que vous voulez peut-être garder : vérifiez avant de supprimer).

1. Solon et Docker Desktop cohabitent. Le moteur auquel la commande docker s'adresse dépend du docker.exe trouvé en premier dans votre PATH ; celui de Solon est dans son dossier d'installation. docker context ls montre le contexte courant.
2. Erreurs « unauthorized » de Docker Hub : le CLI docker de Windows réutilise des identifiants stockés par Docker Desktop, parfois périmés. docker logout puis docker login règle le problème.
3. WSL n'est pas utilisé par Solon et n'a besoin ni d'être installé ni d'être retiré.