tahoe message error

laurent

Member
AMD OS X Member
Oct 30, 2020
131
13
18
52
France
CPU:
Amd Fx8350 Amd ryzen 7 5700x
Hello, I updated from Sequoia to Tahoe and it worked.
But I tried to do a clean install with the same EFI and I got this message:
MSI B450 Tomahawk Max
Ryzen 7 5700x
OpenCore 1.05
Symbios MacPro 7.1
amd rx5500xt
 

Attachments

  • 20250810121637.jpg
    20250810121637.jpg
    2.5 MB · Views: 28
  • EFI.zip
    EFI.zip
    8.7 MB · Views: 6
Last edited:
Can I ask why you have so many USB ports disabled in your USBMap.kext?

Highlighted ports are disabled by using the # at the front of the 'port' or 'usb-port-number' entry.

You have 10 of 14 disabled under the PTXH controller, as shown below.
Screenshot 2025-08-10 at 18.09.16.png PTXH Ports

You have 6 of 8 ports disabled under the XHC0 controller, again as shown below.
Screenshot 2025-08-10 at 18.09.49.png XHC0 ports

What are the chances you are using a port for your Tahoe USB installer that is being dropped when the Bios hands over to the OS installer? I would say very high, as you only have 6 x ports active in your USBMap.kext out of a possible 22 x ports.

The easiest way to see this is that only 6 x ports have been provided with Comment (nickname) entries, describing the type of port related to the entry.

Remove the # from the 'port' and 'usb-port-number' entries and this should enable all the USB ports in your setup.

You need to remember that you are not limited to a maximum of 15 x ports, each USB controller can active 15 x ports.

To manually edit the USBMap.kext/Contents/Info.plist do the following:
  1. Right-click on the USBMap.kext and select 'Show Package Contents'.
  2. Finder will show the Contents folder, open this and you will see the Info.plist.
  3. Open this with ProperTree and made the edits necessary.
I have assumed the UsbConnector entries are correct and that these don't require any editing.

The rest of your OC EFI looks a bit spartan but functional.

You should really be using Custom SSDT's for your setup, generated using Corpnewt's SSDTTime and your system DSDT.aml. Even if you are only using the bare minimum.

HfsPlus.efi is the better HFS+ driver, based on this replacing OpenHfsPlus.efi with HfsPlus.efi would make sense.

I have made most of the changes listed above, not the SSDT change. Although I have replaced the generic DESKTOP SSDT with an AMD specific SSDT.
I have also cleaned up your config.plist, removing any unused and unnecessary entries from the plist, so it is easier to read and navigate.

Try this revised EFI, see if this gets you any further.
 

Attachments

  • Like
Reactions: laurent
Puis-je vous demander pourquoi vous avez autant de ports USB désactivés dans votre USBMap.kext ?

Les ports mis en surbrillance sont désactivés en utilisant le # devant l'entrée « port » ou « numéro de port USB ».

Vous avez 10 des 14 désactivés sous le contrôleur PTXH, comme indiqué ci-dessous.
View attachment 17750 Ports PTXH

Vous avez 6 des 8 ports désactivés sous le contrôleur XHC0, comme indiqué ci-dessous.
View attachment 17751 Ports XHC0

Quelle est la probabilité que vous utilisiez un port pour l'installateur USB de votre Tahoe qui soit abandonné lorsque le BIOS passe le relais à l'installateur du système d'exploitation ? Je dirais que c'est très élevé, car vous n'avez que 6 ports actifs dans votre fichier USBMap.kext sur 22 possibles.

La façon la plus simple de voir cela est que seuls 6 ports ont été fournis avec des entrées de commentaire (surnom), décrivant le type de port lié à l'entrée.

Supprimez le # des entrées « port » et « usb-port-number » et cela devrait activer tous les ports USB de votre configuration.

Vous devez vous rappeler que vous n'êtes pas limité à un maximum de 15 ports, chaque contrôleur USB peut activer 15 ports.

Pour modifier manuellement le fichier USBMap.kext/Contents/Info.plist, procédez comme suit :
  1. Faites un clic droit sur USBMap.kext et sélectionnez « Afficher le contenu du package ».
  2. Le Finder affichera le dossier Contenu, ouvrez-le et vous verrez le fichier Info.plist.
  3. Ouvrez-le avec ProperTree et effectuez les modifications nécessaires.
J'ai supposé que les entrées UsbConnector étaient correctes et qu'elles ne nécessitaient aucune modification.

Le reste de votre OC EFI semble un peu spartiate mais fonctionnel.

Vous devriez vraiment utiliser des SSDT personnalisés pour votre configuration, générés à l'aide de SSDTTime de Corpnewt et du fichier DSDT.aml de votre système. Même si vous n'utilisez que le strict minimum.

HfsPlus.efi est le meilleur pilote HFS+, sur cette base, remplacer OpenHfsPlus.efi par HfsPlus.efi serait logique.

J'ai effectué la plupart des modifications mentionnées ci-dessus, mais pas le SSDT. J'ai cependant remplacé le SSDT générique DESKTOP par un SSDT spécifique à AMD.
J'ai également nettoyé votre config.plist, en supprimant toutes les entrées inutilisées et inutiles du plist, afin qu'il soit plus facile à lire et à parcourir.

Essayez cet EFI révisé, voyez si cela vous apporte plus loin.
Hello and thank you.

Actually, I accidentally deleted the inactive USB ports.

With the EFI you provided, the system works better,
but I still have the problem of freezing during the clean installation.

However, I found a strange solution: I'm using OpenCore 1.02, and it works. I can install Tahoe, which is also in beta 6, except that the Internet isn't recognized.
So then I updated to OpenCore 1.05, and it's all fine.

I'm still looking for the difference in settings between the two versions of OpenCore.

I don't use a USB flash drive for the installation.
I partition the SSD or NVMe hard drive in macOS Extended.
One partition contains the installer.app.
And once the installation is complete, I delete the installation partition.
 
To be honest, there hasn't been much change in the recent OpenCore releases, not in respect of dealing with Hackintosh or config.plist issues. Most changes are either related to real Macs, Virtual Machines or background tasks that are hidden from user input/observation. Most people update OC just to stay current, not because of a specific need. A new version of macOS usually requires a specific version of OC, so it includes any background settings that required updating for the new OS.

I don't use a USB flash drive for the installation.
I partition the SSD or NVMe hard drive in macOS Extended.
One partition contains the installer.app.
And once the installation is complete, I delete the installation partition.
That is one way to install macOS. You aren't the first to use this method and I doubt you will be the last. I'm sure it negates the need to find the correct sized USB pen drive, which for Tahoe is 32GB.

I have a SATA SSD in a USB3 enclosure that contains the most recent installers for macOS from Mountain Lion up to and including Monterey. I haven't updated the disk recently, so it is now due three more installers. I might change this to a Type-C M.2 enclosure and use one of my spare/old 256GB NVMe drives, to see if this speeds up the installation process.

I have another old SATA SSD in a USB2 enclosure that contains 'Clones' of macOS from Snow Leopard 10.6.8 up to and including High Sierra 10.13.6. Which I always forget about! When I do remember it, I use it to reinstall the old version of macOS I want on to a spare disk using Carbon Copy Cloner. All I need to do after the clone has been restored is add the correct EFI folder to the disk.
 
  • Like
Reactions: laurent
  • Like
Reactions: laurent
Hello, I want to create a custom DSDT for my MSI B450 Tomahawk Max motherboard.
I wanted to know if HackinTool on Mac is reliable for exporting a DSDT, or do I have to do it on Windows with SDTTime?
Thanks.
 
Hackintool's Dump ACPI option is fine to use.

I am not sure why you think you need a custom DSDT.aml table for your B450 system. The Dortania guide explicitly states not to use a custom/patched DSDT.aml table. You should be using custom SSDT's &/or patches in the config.plist to deal with any issues.

What exactly do you want to patch?
 
  • Like
Reactions: laurent
L'option Dump ACPI de Hackintool peut être utilisée sans problème.

Je ne comprends pas pourquoi vous pensez avoir besoin d'une table DSDT.aml personnalisée pour votre système B450. Le guide Dortania indique explicitement de ne pas utiliser de table DSDT.aml personnalisée/corrigée. Il est préférable d'utiliser des tables SSDT personnalisées et/ou des correctifs dans le fichier config.plist pour résoudre les problèmes éventuels.

Que voulez-vous corriger exactement
What I mean by this is that from my DSDT file created by
HackinTool, I create custom SSDTs for my motherboard for better compatibility. Is this the correct procedure? For example, an SSDT-EC an SSDT-USBX ?
 
  • Like
Reactions: laurent

Attachments

  • Capture d’écran 2025-08-18 à 18.16.14.png
    Capture d’écran 2025-08-18 à 18.16.14.png
    991.7 KB · Views: 14
  • Capture d’écran 2025-08-18 à 18.23.19.png
    Capture d’écran 2025-08-18 à 18.23.19.png
    221.9 KB · Views: 7
  • Capture d’écran 2025-08-18 à 18.33.30.png
    Capture d’écran 2025-08-18 à 18.33.30.png
    1.2 MB · Views: 7
  • Capture d’écran 2025-08-18 à 18.34.14.png
    Capture d’écran 2025-08-18 à 18.34.14.png
    1,017.5 KB · Views: 4
  • Capture d’écran 2025-08-18 à 18.34.51.png
    Capture d’écran 2025-08-18 à 18.34.51.png
    1.2 MB · Views: 9
Last edited:
For an AMD system like yours, B450 Motherboard, those three SSDT's and the associated HPET ACPI patches would be the minimum I would use.

SSDT-XOSI.aml and its associated patch, would be one that I would also use. Option #A in SSDTTime.

SSDT-SBUS-MCHC.aml is another I would generate using Option #C

Depending on your discrete GPU's setup, I would also check that an SSDT-Bridge.aml table wasn't required.
  • You would do this by looking in Hackintool's > PCIe tab and see if the IOReg Name for the GPU and HDAU devices have an entry named 'pcie-bridge' in the name.
  • If these or any others have the 'pcie-bridge' entry in their names then your system will need to generate a custom SSDT or two for those devices.
  • As the 'pcie-bridge' entry means a part of the IOReg Name is missing in macOS and the device won't be enabled correctly.
Using the system DSDT.aml and SSDTTime's option #9, plus the Device Path from the GPU or other device when requested will help generate the SSDT-Bridge.aml table.

If your system requires more than one SSDT-Bridge.aml table talk to me, as this complicates things a little.

On my B550 & B550m systems I use these SSDT's.
Screenshot 2025-08-18 at 21.06.13.png 1 X SSDT-Bridge.aml table

While on my X570 system I use these SSDT's.

Screenshot 2025-08-18 at 21.06.44.png 3 x SSDT-Bridge tables, BRG0, BRG1 & BRG2, for SATA, GPU and another device.

Obviously you don't need the AQUANTIA or CPUR tables in your setup. As those are required for the B550 board and a 10G NIC.
 
  • Like
Reactions: laurent
For an AMD system like yours, B450 Motherboard, those three SSDT's and the associated HPET ACPI patches would be the minimum I would use.

SSDT-XOSI.aml and its associated patch, would be one that I would also use. Option #A in SSDTTime.

SSDT-SBUS-MCHC.aml is another I would generate using Option #C

Depending on your discrete GPU's setup, I would also check that an SSDT-Bridge.aml table wasn't required.
  • You would do this by looking in Hackintool's > PCIe tab and see if the IOReg Name for the GPU and HDAU devices have an entry named 'pcie-bridge' in the name.
  • If these or any others have the 'pcie-bridge' entry in their names then your system will need to generate a custom SSDT or two for those devices.
  • As the 'pcie-bridge' entry means a part of the IOReg Name is missing in macOS and the device won't be enabled correctly.
Using the system DSDT.aml and SSDTTime's option #9, plus the Device Path from the GPU or other device when requested will help generate the SSDT-Bridge.aml table.

If your system requires more than one SSDT-Bridge.aml table talk to me, as this complicates things a little.

On my B550 & B550m systems I use these SSDT's.
View attachment 17842 1 X SSDT-Bridge.aml table

While on my X570 system I use these SSDT's.

View attachment 17843 3 x SSDT-Bridge tables, BRG0, BRG1 & BRG2, for SATA, GPU and another device.

Obviously you don't need the AQUANTIA or CPUR tables in your setup. As those are required for the B550 board and a 10G NIC.
Hello, I generated the ssdt that you suggested to me.
I don't know if I did the right thing?
As for the SSDT Brige, I have a little trouble.
 

Attachments

  • Capture d’écran 2025-08-19 à 12.33.54.png
    Capture d’écran 2025-08-19 à 12.33.54.png
    98.4 KB · Views: 8
  • Capture d’écran 2025-08-19 à 12.38.04.png
    Capture d’écran 2025-08-19 à 12.38.04.png
    167.9 KB · Views: 7
  • Capture d’écran 2025-08-19 à 12.38.59.png
    Capture d’écran 2025-08-19 à 12.38.59.png
    828.7 KB · Views: 7
  • Capture d’écran 2025-08-19 à 12.44.09.png
    Capture d’écran 2025-08-19 à 12.44.09.png
    86.1 KB · Views: 10
Your Navi 14 dGPU requires more than one bridge, that is not uncommon. There are also 4 x devices associated with your dGPU, as highlighted in the screenshot below, again not uncommon.

Capture d’écran 2025-08-19 à 12.38.59.png

What did SSDTTime generate when you provided the Device Path from the Display Controller?
Did the SSDT-Bridge.aml contain 2 x BRGx entries?

Is the First screenshot in post #12 from before the SSDT-SBUS-MCHC.aml is added to your setup, or after?
 
  • Like
Reactions: laurent
Your Navi 14 dGPU requires more than one bridge, that is not uncommon. There are also 4 x devices associated with your dGPU, as highlighted in the screenshot below, again not uncommon.

View attachment 17860

What did SSDTTime generate when you provided the Device Path from the Display Controller?
Did the SSDT-Bridge.aml contain 2 x BRGx entries?

Is the First screenshot in post #12 from before the SSDT-SBUS-MCHC.aml is added to your setup, or after?
I didn't provide a device path because I didn't know what to put
 
I thought that might be the case. Do you know what to put now?

You can right-click on the dGPU entry in Hackintool's PCIe tab which will give you a choice to copy the IOReg Name or Device Path. Select Device Path. This can then be pasted in to SSDTTime when the Device Path is required.

The one Device Path will work for all four GPU related devices.
 
  • Like
Reactions: laurent
I added the path
 

Attachments

  • Capture d’écran 2025-08-19 à 18.20.37.png
    Capture d’écran 2025-08-19 à 18.20.37.png
    299.7 KB · Views: 7
  • Capture d’écran 2025-08-19 à 18.18.57.png
    Capture d’écran 2025-08-19 à 18.18.57.png
    821.7 KB · Views: 7
Its only added one fix - PXSX - to the GPU device IOReg Names.

You need a second one, as 3 of the 4 GPU devices previously highlighted still contain a 'pci-bridge' entry in their IOReg Name.

Post a copy of your SSDT-Bridge.aml table and I will see what I can do to fix this issue.

It can take time to get them set and to work correctly, so some trial and error is required.

What you would notice is if you were to use the 'Export' icon (right hand icon) below the main window on the PCIe tab, is that any device that contains a 'pci-bridge' entry in their name fails to show up in the exported files. What this means is that macOS is not fully engaging with the device.
 
  • Like
Reactions: laurent
I thought there was something wrong with him.
Maybe I should have added them one by one?
in any case thank you for your patience
 

Attachments

  • SSDT-Bridge.aml.zip
    SSDT-Bridge.aml.zip
    563 bytes · Views: 1
  • Capture d’écran 2025-08-19 à 19.04.27.png
    Capture d’écran 2025-08-19 à 19.04.27.png
    616.1 KB · Views: 6
Last edited:
Try this revised SSDT-Bridge.aml table. It contains 2 x bridge elements, which should work with your setup.

Screenshot 2025-08-19 at 19.21.47.png BRG0 & PXSX are the renames used for the pci-bridge elements.
 

Attachments

  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.