No description
  • Python 49.5%
  • Shell 38%
  • Nix 12.5%
Find a file
Supertaranta 3541d78200 fix: RTC en UTC, sinon l'horloge de dom0 retarde du fuseau
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
2026-08-26 21:48:13 -04:00
examples/qubes-kvm feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
oemdrv feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
.gitignore feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
autopilot.sh feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
flake.nix feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
LICENSE feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
mkoemdrv.sh feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00
qubes-vm.sh fix: RTC en UTC, sinon l'horloge de dom0 retarde du fuseau 2026-08-26 21:48:13 -04:00
README.md fix: RTC en UTC, sinon l'horloge de dom0 retarde du fuseau 2026-08-26 21:48:13 -04:00
vmdrive feat: vmdrive et recette reproductible de Qubes OS en VM KVM 2026-08-26 21:03:10 -04:00

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.9 panique exactement pareil.
  • La panique ioread32 est 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 qemu sur cette machine : les microVM ai-hermes, ai-inference et ai-sandbox y tournent. Utiliser ./qubes-vm.sh stop, qui cible le -name de 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 m produit ,. D'ou --layout fr, qui fait la traduction. Pour taper « mart » en AZERTY il faut frapper semicolon q r t.
  • Le monitor texte ne suffit pas. mouse_move y est accepte sans erreur et reste sans effet. Il faut QMP et input-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.