État d’avancement — Tiny Core persistant + llama-cpp-python compilé (28/08/2026)

[Mario Da Conceicao]

État d’avancement complet du 28/08/2026 — installation de Tiny Core en persistant sur le disque dur virtuel, compilation réussie de llama-cpp-python, confirmé après un vrai redémarrage. Session la plus longue et la plus difficile du projet, mais résultat solide.

Ce qui fonctionne, confirmé après reboot

• Tiny Core 17.1 installé pour de bon sur le disque dur virtuel (/dev/sda1, ext4, via tc-install.sh en mode Frugal/Whole Disk)
• Python 3.9.21 fonctionnel et persistant
• llama-cpp-python 0.3.35 compilé et fonctionnel, adapté au processeur 32 bits (i486/i686, sans AVX/FMA)

Miroir de paquets fiable (à utiliser, celui par défaut échoue souvent en 404)

sudo sh -c "echo http://distro.ibiblio.org/tinycorelinux/16.x/x86/tcz/ > /opt/tcemirror"

Méthode de secours si tce-load échoue malgré tout (404 sur le .md5.txt) :

wget http://distro.ibiblio.org/tinycorelinux/16.x/x86/tcz/NOM.tcz
wget http://distro.ibiblio.org/tinycorelinux/16.x/x86/tcz/NOM.tcz.md5.txt
tce-load -i NOM.tcz

Liste complète des paquets nécessaires (dans cet ordre logique de dépendances)

Xvesa, compiletc, expat2, python3.9, python3.9-pip, tk8.6, gcc, gcc_libs, gmp, isl, mpc, mpfr, openssl, binutils, flex, zstd, libzstd, pkg-config, python3.9-dev, linux-6.12_api_headers, libffi, sqlite3, glibc_base-dev.

Attention : le nom exact est expat2.tcz (pas expat.tcz) sur ce dépôt.

Problèmes rencontrés et solutions (dans l’ordre où ils sont apparus)

• onboot.lst introuvable → le vrai TCEDIR est /mnt/sda1/tce (pas /opt/.tce) une fois installé sur disque
• SSL indisponible dans pip (ImportError _ssl) → cause réelle : libatomic.so.1 manquant → installer gcc_libs.tcz
• gcc absent malgré compiletc "already installed" → installer gcc.tcz manuellement
• cc1: libisl.so.23 manquant → isl.tcz
• cc1: libmpc.so.3 manquant → mpc.tcz
• cc1: libmpfr.so.6 manquant → mpfr.tcz
• cc1: libzstd.so.1 manquant → la lib est dans libzstd.tcz (pas zstd.tcz, qui ne contient que les binaires)
• ld introuvable → binutils.tcz
• ld: Scrt1.o / crti.o introuvables → glibc_base-dev.tcz
• meson: ar introuvable/cassé → libfl.so.2 manquant → flex.tcz
• meson: pkg-config introuvable → pkg-config.tcz + python3.9-dev.tcz (pour Python.h)
• Compilation numpy: fatal error linux/errno.h introuvable → linux-6.12_api_headers.tcz (paquet requis trouvé via wget .../compiletc.tcz.dep)
• gcc: erreur inlining _mm256_fmadd_ps → processeur 32 bits incompatible avec les optimisations AVX/FMA par défaut de llama.cpp → voir commande finale ci-dessous
• Import llama_cpp: libffi.so.7 manquant → libffi.tcz
• Import llama_cpp: undefined symbol __atomic_fetch_add_8 dans libggml-base.so → ajouter -latomic au linker (voir commande finale)
• Import llama_cpp (diskcache→sqlite3): libsqlite3.so.0 manquant → sqlite3.tcz

La commande finale qui a permis la compilation réussie

CMAKE_ARGS="-DGGML_NATIVE=OFF -DGGML_CPU_ALL_VARIANTS=OFF -DGGML_AVX=OFF -DGGML_AVX2=OFF -DGGML_FMA=OFF -DGGML_BMI2=OFF -DGGML_F16C=OFF -DGGML_SSE42=OFF -DCMAKE_EXE_LINKER_FLAGS=-latomic -DCMAKE_SHARED_LINKER_FLAGS=-latomic" pip3.9 install llama-cpp-python --no-cache-dir --force-reinstall

Le vrai piège de persistance (résolu)

/opt/.tce_dir doit pointer vers /mnt/sda1/tce (pas /opt/.tce) une fois installé sur disque, sinon les extensions listées dans onboot.lst ne se rechargent jamais au démarrage malgré filetool.sh -b réussi. Vérifier /etc/sysconfig/tcedir pointe bien vers /mnt/sda1/tce/.

Ce qui reste à faire

1. Nettoyer une ligne corrompue dans onboot.lst : "linuc-6.12_hesders.tcz" mal orthographiée, doublon à supprimer
2. Recopier les fichiers de MIRA (chat_ia.py, moteur_ia.py, etc.) — perdus lors du passage de la base temporaire vers le disque persistant, à refaire une dernière fois sur la nouvelle base stable
3. Télécharger le vrai modèle Phi-4 Mini
4. Premier test réel : MIRA répond à une question

Méthode prévue pour le passage final sur la vraie clé USB

Pas besoin de refaire toute la procédure : le disque virtuel de la VM (OS-MIRE-Test.vdi) sera converti en image brute (.img) via VBoxManage, puis écrit sur la vraie clé avec Rufus ou balenaEtcher — une seule opération de clonage une fois que tout est validé dans la VM.

[Auteur]

Messages