- Python 49.5%
- Shell 38%
- Nix 12.5%
QEMU etait lance avec `-rtc base=localtime` alors que le kickstart declare `timezone --utc`. Le decalage du fuseau etait donc applique deux fois : dom0 affichait 17h46 pour 21h47 reelles en Martinique. Constate au premier demarrage du bureau Qubes, apres installation complete. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015w5PaPdkM45epEwpc61AsY |
||
|---|---|---|
| examples/qubes-kvm | ||
| oemdrv | ||
| .gitignore | ||
| autopilot.sh | ||
| flake.nix | ||
| LICENSE | ||
| mkoemdrv.sh | ||
| qubes-vm.sh | ||
| README.md | ||
| vmdrive | ||
Qubes OS en VM KVM sur Supertaranta — recette reproductible
Rejouer l'installation de bout en bout :
./qubes-vm.sh all # telecharge, verifie, cree le disque, installe
./autopilot.sh # (dans un autre terminal) franchit l'avertissement IOMMU
Il ne restera que deux choses a taper dans la fenetre : la phrase secrete de chiffrement et le compte utilisateur. Rien d'autre.
Ensuite, pour demarrer la VM installee :
./qubes-vm.sh run
Pourquoi ces reglages
Chaque ligne ci-dessous corrige une panne reellement constatee le 26/08/2026. Ce ne sont pas des preferences : les enlever casse l'installation.
| Reglage | Sans lui |
|---|---|
-smp 1 |
Xen gele sur installing Xen timer for CPU 1, puis dom0 panique dans ioread32 et la VM reboote en boucle. |
qxl-vga |
X ne demarre pas, Anaconda propose « Start VNC / Use text mode ». |
aucune console=hvc0 |
Anaconda detecte une console serie et bascule en mode texte, meme avec QXL. |
usb-tablet sans usb-kbd |
Ajouter un clavier USB coupe le clavier dans X (le VT switch continue de marcher, ce qui trompe). |
-qmp |
Le mouse_move du monitor texte est sans effet ; seul input-send-event (QMP) fait bouger le pointeur. |
-rtc base=utc |
Avec base=localtime, l'horloge de dom0 retarde du fuseau : QEMU presente l'heure locale, et le kickstart declare le RTC en UTC — la soustraction est faite deux fois (constate : 17h46 affichees pour 21h47 reelles en Martinique). |
Fausses pistes, deja eliminees — ne pas y revenir
- L'IOMMU emule (
-device amd-iommu) n'est pas la cause du panic : il survient avec et sans. QEMU emule bien un AMD-Vi, mais trop incompletement pour le pilote de Xen. - Le noyau n'est pas en cause : l'entree GRUB
kernel-latest 7.0.9panique exactement pareil. - La panique
ioread32est un symptome, pas la cause. Elle n'a ete comprise qu'en branchant une console serie sur la ligne GRUB, qui a montre le vrai point de blocage (le demarrage du 2e CPU).
Pieges de manipulation
- Ne jamais valider le dialogue IOMMU avec Entree : le focus par defaut est sur « Quitter », et l'installateur redemarre la machine. Cliquer.
- Ne jamais faire
pkill -f qemusur cette machine : les microVMai-hermes,ai-inferenceetai-sandboxy tournent. Utiliser./qubes-vm.sh stop, qui cible le-namede la VM. - Un
pkill -f <motif>tue aussi le shell qui le lance si le motif apparait dans sa propre ligne de commande (arrive deux fois pendant la mise au point). - L'interface met 3 a 5 minutes a apparaitre avec 1 vCPU. Ce n'est pas un blocage.
- Un seul miroir plafonne (kernel.org : 136 Ko/s, soit 4 h). aria2 en 16 segments sur 4 miroirs monte a ~5 Mo/s, soit ~25 min.
Limite structurelle : le reseau
L'installateur affiche « Materiel non pris en charge detecte — Missing
features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping ». Ce n'est pas un reglage
qui manque, c'est la nature de l'exercice : sans IOMMU exploitable, Xen ne
peut pas passer une carte reseau en PCI passthrough, donc sys-net n'a
aucune carte a recevoir.
Cette VM sert a decouvrir et evaluer l'interface de Qubes. Elle ne sert pas a s'en servir en reseau, et aucun reglage cote QEMU n'y changera rien.
vmdrive — piloter une VM QEMU de l'exterieur
vmdrive voit l'ecran d'une VM et y agit, sans aucun agent installe dans la
VM : tout passe par le socket QMP de QEMU. Utile pour automatiser un
installateur, ou pour qu'un agent puisse constater l'etat d'une VM.
export VMDRIVE_QMP=./qmp.sock
./vmdrive shot ecran.png # capture (PNG produit par QEMU lui-meme)
./vmdrive size # resolution courante
./vmdrive click 728 515 # clic aux coordonnees ecran
./vmdrive key ret tab esc # touches brutes (qcodes QEMU)
./vmdrive type "du texte" # frappe, avec --layout fr ou us
./vmdrive wait --timeout 120 # attend que l'ecran change
Deux subtilites qui font perdre du temps :
- Un qcode designe une touche physique, pas un caractere. Si la VM est en
AZERTY, envoyer le qcode
mproduit,. D'ou--layout fr, qui fait la traduction. Pour taper « mart » en AZERTY il faut frappersemicolon q r t. - Le monitor texte ne suffit pas.
mouse_movey est accepte sans erreur et reste sans effet. Il faut QMP etinput-send-event.
Fichiers
qubes-vm.sh recette complete (fetch / verify / create / install / run / stop)
oemdrv/ks.cfg kickstart : langue, clavier, fuseau Martinique, disque chiffre
mkoemdrv.sh reconstruit oemdrv.iso (label OEMDRV) apres modification du ks
autopilot.sh franchit l'avertissement IOMMU tout seul
vmdrive pilotage QMP (capture, clic, frappe)
Verification de l'ISO
./qubes-vm.sh verify refuse d'aller plus loin si l'empreinte de la Qubes
Master Signing Key n'est pas 427F11FD0FAA4B080123F01CDDFA1A3E36879494.
Elle verifie ensuite que la cle de release 4.3 est signee par elle, puis la
signature de l'ISO. Le SHA-256 seul ne prouve rien : il vient du meme miroir.