Contrôle — installation 64 bits, point de reprise exact (05/09/2026)

Contrôle du 05/09/2026 sur l’installation Tiny Core 64 bits (suite du diagnostic 32 bits du 03/09). Fil changé à cette étape (trop de captures d’écran) — reprise prévue directement ici.

Vérifié et confirmé correct

• CorePure64-17.1.iso existe bien à l’emplacement indiqué sur le vrai dépôt Tiny Core (26 294 272 octets, ~26 Mo) — bon choix d’image, rien à changer
• Réglages VM cohérents : RAM 4096 Mo, EFI désactivé, disque 32 Go, réseau en mode Bridged, installation via tc-install en Frugal/ext4
• Diagnostic ninja/lib64 solide : ld-linux-x86-64.so.2 attendu par convention dans /lib64, réellement présent dans /lib sur ce système minimal — cause bien identifiée, correction par lien symbolique appropriée

Point exact où la session s’est arrêtée (à reprendre en priorité)

La commande de correction avait été lancée :

sudo sed -i '/ln -sf/i mkdir -p /lib64' /opt/bootlocal.sh

mais son résultat n’avait pas encore été vérifié. Première chose à faire à la reprise :

cat /opt/bootlocal.sh

Confirmer que la ligne mkdir -p /lib64 apparaît bien AVANT la ligne ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2 — c’était la vraie faille de la première tentative (ln -sf ne crée pas de dossier parent tout seul).

Puis, dans l’ordre :

1. sudo /opt/bootlocal.sh (test manuel)
2. ninja --version (doit répondre 1.13.2, pas "not found")
3. filetool.sh -b
4. Un vrai redémarrage à froid (Fermer → Démarrer depuis VirtualBox, jamais reboot interne) pour valider que ninja et le lien /lib64 persistent réellement cette fois
5. Si validé : retransfert des fichiers MIRA + du modèle déjà téléchargé (phi-4-mini.Q4_K_M.gguf, pas à retélécharger)
6. Test de chargement du modèle en Python interactif, puis premier vrai lancement de moteur_ia.py

Rien d’autre à changer dans le plan — la suite prévue dans le récapitulatif du 05/09 reste valable telle quelle.