Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[RÉSOLU] Ventura 13.6 sur Unraid KVM / AMD Ryzen — guide complet du boot au premier écran

Featured Replies

Plateforme :** Unraid + KVM/QEMU (pc-q35-9.2) + CPU AMD Ryzen 7 + Macinabox / KVM-Opencore v21 Symptômes de départ : logo Apple → retour au picker OpenCore, ou blocage silencieux sans aucun message, ou EXITBS:START


Contexte

AMD Ryzen sur KVM cumule plusieurs problèmes indépendants qui, combinés, rendent le boot de Ventura particulièrement difficile à diagnostiquer. Ce post documente chaque problème rencontré, sa cause racine, et la correction appliquée — dans l'ordre chronologique du debug.


Problème 1 — Le CPU AMD fait planter XNU au démarrage

Symptôme

La VM affiche le logo Apple, parfois une barre de progression partielle, puis revient au picker OpenCore sans aucun message d'erreur. En mode verbose (-v), on peut voir l'amorce du boot XNU puis un arrêt brutal.

Cause

macOS vérifie à l'initialisation que le CPU est un Intel compatible via l'instruction CPUID. Un Ryzen en host-passthrough brut expose un CPU AMD dont la signature CPUID ne correspond à aucune famille Intel reconnue par XNU. macOS refuse alors de continuer.

Correction — Override CPU dans qemu:commandline

Dans le XML libvirt, on garde host-passthrough pour la compatibilité KVM, mais on le surcharge via -cpu dans qemu:commandline pour présenter un CPU Intel à macOS :

<cpu mode='host-passthrough' check='none' migratable='on'>
  <topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/>
  <cache mode='passthrough'/>
  <feature policy='require' name='topoext'/>
</cpu>
<qemu:commandline>
  <qemu:arg value='-device'/>
  <qemu:arg value='************************'/>
  <qemu:arg value='-smbios'/>
  <qemu:arg value='type=2'/>
  <qemu:arg value='-cpu'/>
  <qemu:arg value='Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2'/>
</qemu:commandline>

Le -cpu dans qemu:commandline écrase le host-passthrough défini dans <cpu> : c'est le comportement de QEMU quand on passe -cpu en argument direct. macOS voit un Skylake-Server GenuineIntel au lieu d'un Ryzen.

Pourquoi Skylake-Server spécifiquement ? Il expose les bons flags SSE/AVX pour Ventura, est reconnu par la table CPUFAMILY d'XNU, et est supporté par les patches kernel AMD (voir plus bas).


Problème 2 — Ventura 13.x refuse de booter sans AVX2 (CryptexFixup)

Symptôme

Même avec l'override CPU Intel, Ventura 13.x panique très tôt au démarrage. L'erreur, visible en verbose, est liée à Cryptex — le système de mise à jour encapsulée d'Apple.

Cause

Ventura utilise un mécanisme appelé Cryptex pour livrer les mises à jour OS. Il existe deux variantes de l'image Cryptex : une optimisée AVX2 et une non-AVX2. Au démarrage, macOS détecte la présence du flag AVX2 dans le CPUID et choisit la variante correspondante. Sur un hack/VM, si vous activez AVX2 dans le CPU présenté à macOS mais que la variante AVX2 de la Cryptex est absente ou incohérente, vous obtenez un kernel panic.

Correction — Ne PAS activer +avx2, utiliser CryptexFixup.kext

La ligne -cpu ne doit pas contenir +avx2 :

Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2

Sans +avx2, macOS sélectionne la variante non-AVX2 de la Cryptex. CryptexFixup.kext (de Lilu) complète ce mécanisme en patchant _apfs_filevault_allowed pour autoriser le boot avec la variante non-AVX2 :

<!-- Dans config.plist, Kernel > Add -->
<dict>
  <key>BundlePath</key>
  <string>CryptexFixup.kext</string>
  <key>Comment</key>
  <string>Support for non-AVX2 CPUs in Ventura/Sonoma</string>
  <key>Enabled</key>
  <true/>
  <key>MinKernel</key>
  <string>22.1.0</string>
  <key>MaxKernel</key>
  <string>23.99.99</string>
</dict>

Un patch kernel Force FileVault vient compléter CryptexFixup (du projet OCLP) :

Base    : _apfs_filevault_allowed
Find    : (vide)
Replace : uAEAAADD  (mov eax, 1 ; ret)

Problème 3 — Les patches kernel AMD obligatoires

OpenCore KVM-Opencore v21 inclut 5 patches kernel essentiels pour AMD sur Ventura :

Patch 1 & 2 — algrey/thenickdude : force CPUFAMILY_INTEL_PENRYN

macOS détermine la famille CPU via la fonction cpuid_set_cpufamily dans XNU. Même avec un CPUID Intel en entrée, XNU calcule une famille qui peut ne pas correspondre à CPUFAMILY_INTEL_PENRYN (la seule famille garantie compatible avec tous les chemins de code macOS). Ces patches forcent le retour de Penryn :

  • Patch 1 : pour macOS 10.13–11.2 (MinKernel 17.0.0, MaxKernel 20.3.99)

  • Patch 2 : pour macOS 11.3+ jusqu'à Sonoma (MinKernel 20.4.0, MaxKernel 23.99.99) — version thenickdude

Patches 3 & 4 — SurPlus v1 : PRNG non-monotonic (Big Sur 11.3–11.4 seulement)

Patchent _early_random et _register_and_init_prng pour Big Sur 11.3–11.4. Actifs sur MinKernel 20.4.0 / MaxKernel 21.1.0, inactifs sur Ventura mais doivent être présents dans le config.

Patch 5 — FileVault / CryptexFixup (décrit ci-dessus)


Problème 4 — Le crash silencieux : panic non-monotonic time sur AMD

Symptôme

Le plus difficile à diagnostiquer. La VM s'arrête brutalement sans aucune sortie visible. Même en mode verbose, rien ne s'affiche après un certain stade. La VM redémarre automatiquement (watchdog). On croit à un problème de configuration alors que le kernel a paniqué silencieusement.

Méthode de debug — Serial log vers fichier

La clé pour voir ce qui se passe : rediriger la sortie série (console noyau) vers un fichier sur l'hôte Unraid. Dans le XML :

<serial type='file'>
  <source path='/tmp/ventura_serial.log' append='on'/>
  <target type='isa-serial' port='0'>
    <model name='isa-serial'/>
  </target>
</serial>
<console type='file'>
  <source path='/tmp/ventura_serial.log' append='on'/>
  <target type='serial' port='0'/>
</console>

Et dans les boot-args OpenCore (NVRAM) :

boot-args = keepsyms=1 debug=0x100 -v serial=3

serial=3 active la sortie sur le port série. On peut ensuite surveiller en temps réel :

tail -f /tmp/ventura_serial.log | tr -cd '[:print:]\n\t'

Ce qu'on voit dans le log

panic(cpu 3 caller 0xffffff800f8b3c2a): "non-monotonic time: prev...

Ou plus subtilement, la VM cesse de produire des messages alors que le boot était en cours.

Cause

Les CPU AMD Ryzen sous KVM ont un comportement du TSC (Time Stamp Counter) qui peut produire des valeurs non-monotoniques vues depuis les différents cœurs. XNU (le noyau macOS) considère cela comme un état impossible et appelle panic() dans les fonctions de scheduling :

  • thread_quantum_expire

  • thread_unblock

  • thread_invoke

  • thread_dispatch

Correction — 2 patches kernel Visual (non-monotonic time)

Ces deux patches, publiés par "Visual" sur les forums Hackintosh, neutralisent les vérifications de temps monotone dans XNU pour macOS 12.0+ (MinKernel 21.0.0) :

Patch 6 — thread_quantum_expire / thread_unblock / thread_invoke (3 occurrences)

<dict>
  <key>Comment</key>
  <string>Visual | thread_quantum_expire, thread_unblock, thread_invoke | Remove non-monotonic time panic | 12.0+</string>
  <key>Count</key>
  <integer>3</integer>
  <key>Enabled</key>
  <true/>
  <key>Find</key>
  <data>SAAAAAIAAEgAAFgAAAAPAAAAAAA=</data>
  <key>Identifier</key>
  <string>kernel</string>
  <key>Mask</key>
  <data>/wAAD/////8AAP8AAAD/AAAAAAA=</data>
  <key>MaxKernel</key>
  <string>25.99.99</string>
  <key>MinKernel</key>
  <string>21.0.0</string>
  <key>Replace</key>
  <data>AAAAAAAAAAAAAAAAAABmkGaQZpA=</data>
  <key>ReplaceMask</key>
  <data>AAAAAAAAAAAAAAAAAAD///////8=</data>
</dict>

Patch 7 — thread_invoke / thread_dispatch (2 occurrences)

<dict>
  <key>Comment</key>
  <string>Visual | thread_invoke, thread_dispatch | Remove non-monotonic time panic | 12.0+</string>
  <key>Count</key>
  <integer>2</integer>
  <key>Enabled</key>
  <true/>
  <key>Find</key>
  <data>SAAAgAQAAA8AAAAAAA==</data>
  <key>Identifier</key>
  <string>kernel</string>
  <key>Mask</key>
  <data>SAAA8P////8AAAAAAA==</data>
  <key>MaxKernel</key>
  <string>25.99.99</string>
  <key>MinKernel</key>
  <string>21.0.0</string>
  <key>Replace</key>
  <data>AAAAAAAAAGaQZpBmkA==</data>
  <key>ReplaceMask</key>
  <data>AAAAAAAAAP///////w==</data>
</dict>

Ces deux patches sont absents du KVM-Opencore v21 de base et doivent être ajoutés manuellement dans le config.plist (monter l'image .img de l'EFI, éditer EFI/OC/config.plist).


Configuration OpenCore complète — points critiques

Booter > Quirks

Quirk

Valeur

Raison

SetupVirtualMap

False

CRITIQUE sur KVM — macOS n'a pas besoin du remapping de la virtual map UEFI en environnement VM

RebuildAppleMemoryMap

False

Cause des panics sur AMD KVM si activé

SyncRuntimePermissions

False

Incompatible avec l'environnement KVM AMD

AvoidRuntimeDefrag

True

Nécessaire

ProvideCustomSlide

True

Nécessaire

EnableSafeModeSlide

True

Nécessaire

Kernel > Quirks

Quirk

Valeur

ProvideCurrentCpuInfo

True — fournit les informations CPU correctes à macOS, requis sur AMD

DisableLinkeditJettison

True

ForceSecureBootScheme

True

Kernel > Emulate

<key>Cpuid1Data</key>
<data>VAYFAAAAAAAAAAAAAAAAAA==</data>
<key>Cpuid1Mask</key>
<data>////AAAAAAAAAAAAAAAAAA==</data>
<key>DummyPowerManagement</key>
<true/>

Force un CPUID compatible Intel pour les couches OS qui lisent directement le registre (au-delà du patch cpuid_set_cpufamily).

Misc > Security

<key>SecureBootModel</key>
<string>Disabled</string>

Obligatoire en VM KVM (pas d'Apple T2/SEP).

NVRAM

boot-args : keepsyms=1 debug=0x100 -v serial=3
csr-active-config : 0x26 0x0f (SIP partiellement désactivé)

PlatformInfo

SMBIOS iMacPro1,1 — le profil machine qui correspond le mieux à la configuration Intel Xeon / KVM VM. Nécessite des MLB/SerialNumber valides générés avec GenSMBIOS.

Kexts actifs

Kext

Rôle

Lilu

Moteur de patches — requis par tous les autres

CryptexFixup

Support non-AVX2 pour Ventura/Sonoma

WhateverGreen

Patches GPU

AppleALC

Audio

MCEReporterDisabler

Désactive AppleMCEReporter qui panique sur CPU non-Apple

USBPorts

Mapping USB

AGPMInjector

Gestion GPU power

BrcmFirmwareData + BrcmPatchRAM3 + BlueToolFixup

Bluetooth (si carte BCM)

MCEReporterDisabler est souvent oublié — sans lui, macOS panique sur multi-socket ou CPU non reconnu.


Récapitulatif — Ordre de résolution des problèmes

1. Boot → retour picker          → Override CPU Skylake-Server sans AVX2
2. Panic Cryptex                 → CryptexFixup.kext + patch FileVault
3. Panic cpuid_set_cpufamily     → Patches algrey/thenickdude
4. Crash silencieux sans log     → Activer serial log + boot-args serial=3
5. Panic non-monotonic time      → Patches Visual (patch 6 & 7)
6. Panic au boot (divers)        → SetupVirtualMap=False + RebuildAppleMemoryMap=False

Ce qui fonctionne au final

Avec l'ensemble de ces corrections :

  • OpenCore picker s'affiche correctement

  • Sélection du disque installeur → barre de progression complète

  • Boot jusqu'au Language Chooser / Setup Assistant sans kernel panic

  • Système stable, pas de reboot en boucle

La VM cible : Ryzen 7 (8 cœurs / 16 threads) présentés en 4c/2t à macOS, 8 Go RAM, stockage SATA raw, machine type Q35 9.2, OVMF pure-EFI.


Liens utiles

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.