OpenCore USB installer arrives at "forbidden" circle (with "dirty" log text superimposed)

[JordanOrlando]

RehabMan's repository is for Clover, initially, but elements can be reused in OpenCore. The quoted plist is not a complete config.plist anyway, it is meant to be used by copying relevant segments into the actual config.plist.

@Feartech confirmed what I suspected: ACPI renames are missing—and also in your Clover installation.
@UtterDisbelief says X79 has no native USB 3 controller (XHC) but only USB 2 (EHC); and also confirmed that ACPI renames are missing. This means that all our discussions on XhciPortLimit have been futile.

There is no EHC or XHC in your DSDT, but using the MacPro6,1 SMBIOS introduces a SSDT which defines EHC1 and XHC1 as used by the hardware of the actual "trashcan" MacPro (all SMBIOSes do that sort of thing), and these interfere with the mapping of ports from your board.

Here is your Clover EFI with the two relevant patches added in the config.plist. You can check and see what I did with any plist viewer or text editor. If you're willing to try with your Sierra installation (boot from a USB thumb drive, don't mess with the EFI of your working hard drive), this might improve the USB listing by Hackintool.

I have reviewed the ACPI dump. Based on it, you may need SSDT-IMEI after all but I think that SSDT-UNC is of no use, your board appears not to have the unused uncore bridges seen in X99/C610 chipsets (these commonly define four processors even when there is only one socket… and OS X doesn't like it). Checked the motherboard specifications (13 USB 2 ports from X79; USB 3 from an ASMedia controller—these should work out of the box). I have added the two ACPI rename patches, the IMEI device-id injection from the desktop SandyBridge guide because WEG complains about it, and checked the quirks recommended by the SandyBridge-E HEDT guide.
The situation of the MSR patches is confusing: The HEDT guide ticks AppleCpuPmCfgLock (old style for MSR 0xE2) and AppleXcpmExtraMsrs (MSR 0x1AA, present on LGA2011 CPUs); the desktop guide ticks both old-style AppleCpuPmCfgLock and new-style AppleXcpmCfgLock for the same MSR 0xE2. In doubt, I have set all three quirks.
PlateformInfo has been copied from your unredacted (oups!) Clover EFI since you said you use it for both systems. Ultimately, you should have a different serial number for each hackintosh.
This is what I would try to boot from at this stage. Since there is no XhciPortLmit quirk (thanks @UtterDisbelief !), Catalina or Big Sur should make no difference, and neither should the choice of USB port (but you may always try one from the ASM chip and one USB 2 from the chipset). If you try, please let us know if it works, and if not take pictures of the kernel messages.

I tried to use your version of the OpenCore EFI directory.

There's a conflict: you have the entry for "XHCI-unsupported.kext" in config.plist but the actual kext isn't there (which means an immediate error is generated — see first photo below). (Obviously I'm not complaining! It's just an oversight, and you're doing all this hard work for a total stranger, for which I'm grateful.)

I wasn't sure whether "XHCI-unsupported.kext" was supposed to be there or not, so I tried both ways — for half the trials, I added "XHCI-unsupported.kext" and for the other half I removed the entry in config.plist.

I tried both of these ways with my "Install macOS Catalina" USB and then one of these ways (with "XHCI-unsupported.kext" removed) with another USB stick I'd formatted with "Install macOS High Sierra" (just in case the problem is with the Apple portion of the USB sticks). I used each of the 12 USB ports for each configuration. Every single time, the logging froze at what seemed to be an arbitrary point, stopping in mid-line (with a prompt) and freezing there.

I photographed all the freezes — all the photos are attached below. I kept track of which photo corresponds to which configuration (EFI version/USB port — I was cycling through all 12 USB ports in order), but honestly there doesn't seem to be any rhyme or reason to why it's stopping...as you can see, it stops midway through the same lines or different lines in the log, seemingly arbitrarily.

I'm sorry I can't provide more precise information.

 

[etorix]

Sorry to read that…

I indeed made too many late changes when preparing these EFIs. The initial intent was to add patches… but then it dawned on me that @UtterDisbelief was right and there was no XHCI controller (USB 3) to unlock, so the final intent was to remove Xhci-unsupported.
Some of my best breakthroughs came after thinking at the issue overnight and I guess I should have used the same approach to my previous post: Leave it as a draft for the night and re-read the next morning rather than rush to finish the two EFIs in the afternoon.

Messages about TSC means you do need CpuTscSync.kext or VoodooTSCSync.kext after all.
A brutal halt in the middle of a line shortly after [pci initialisation begins] means you do need "npci=0x2000" as a boot-argument after all.
So there is some progress in defining what is required for your X79 system. I think it is safer to start with the minimum and increase the number of kexts/quirks/boot-args as required. Sorry to have wasted so much of your time trying unhelpful permutations.

What puzzles me are messages about the RTC clock. They weren't there before, right? And the RTC in the SSDT looked fine.
With some luck, it is a side effect of (lack of) TSC sync or conflicts in the PCI configuration (npci=0x2000)—and you might actually be close to booting. If this does not go away by putting back CpuTscSync.kext and npci=0x2000, I have no clue right now.

I'll be off the forum a few days while travelling for holidays. Maybe I'll get an idea when I arrive.

 

[JordanOrlando]

Sorry to read that…

I indeed made too many late changes when preparing these EFIs. The initial intent was to add patches… but then it dawned on me that @UtterDisbelief was right and there was no XHCI controller (USB 3) to unlock, so the final intent was to remove Xhci-unsupported.
Some of my best breakthroughs came after thinking at the issue overnight and I guess I should have used the same approach to my previous post: Leave it as a draft for the night and re-read the next morning rather than rush to finish the two EFIs in the afternoon.

Messages about TSC means you do need CpuTscSync.kext or VoodooTSCSync.kext after all.
A brutal halt in the middle of a line shortly after [pci initialisation begins] means you do need "npci=0x2000" as a boot-argument after all.
So there is some progress in defining what is required for your X79 system. I think it is safer to start with the minimum and increase the number of kexts/quirks/boot-args as required. Sorry to have wasted so much of your time trying unhelpful permutations.

What puzzles me are messages about the RTC clock. They weren't there before, right? And the RTC in the SSDT looked fine.
With some luck, it is a side effect of (lack of) TSC sync or conflicts in the PCI configuration (npci=0x2000)—and you might actually be close to booting. If this does not go away by putting back CpuTscSync.kext and npci=0x2000, I have no clue right now.

I'll be off the forum a few days while travelling for holidays. Maybe I'll get an idea when I arrive.

Thank you very much. I've adjusted your EFI and now it almost works — I certainly get much further than I ever did before. Now, I get all the way to a solemn pause and then a uniform gray screen...and then it stops.

From what I can see of the flurry of onscreen logging, it's getting all the way to launching Darwin; recognizing all my drives; loading USB and other subsystems, etc. However there are one or two warnings (some specifiying named kexts) that I don't understand.

I've shot a 60fps movie of the logging, which I'm extracting frames from that I'll string together into an easy-to-read series of framegrabs.

Thank you all again for your tireless efforts...I'm really grateful for the attention and assistance.

 

[JordanOrlando]

Sorry to read that…

I indeed made too many late changes when preparing these EFIs. The initial intent was to add patches… but then it dawned on me that @UtterDisbelief was right and there was no XHCI controller (USB 3) to unlock, so the final intent was to remove Xhci-unsupported.
Some of my best breakthroughs came after thinking at the issue overnight and I guess I should have used the same approach to my previous post: Leave it as a draft for the night and re-read the next morning rather than rush to finish the two EFIs in the afternoon.

Messages about TSC means you do need CpuTscSync.kext or VoodooTSCSync.kext after all.
A brutal halt in the middle of a line shortly after [pci initialisation begins] means you do need "npci=0x2000" as a boot-argument after all.
So there is some progress in defining what is required for your X79 system. I think it is safer to start with the minimum and increase the number of kexts/quirks/boot-args as required. Sorry to have wasted so much of your time trying unhelpful permutations.

What puzzles me are messages about the RTC clock. They weren't there before, right? And the RTC in the SSDT looked fine.
With some luck, it is a side effect of (lack of) TSC sync or conflicts in the PCI configuration (npci=0x2000)—and you might actually be close to booting. If this does not go away by putting back CpuTscSync.kext and npci=0x2000, I have no clue right now.

I'll be off the forum a few days while travelling for holidays. Maybe I'll get an idea when I arrive.

OK, I actually managed to retrieve the complete onscreen log, from after the OpenCore handoff and the boot selector right up until it goes to black and then to gray, and freezes. As I wrote above, I shot a 60fps movie — I extracted frames and matched them up into a single composite image (and quadruple-checked to make sure that I had the entire log with no omissions) — it's attached below.

As I wrote above, thank you all again for your tireless efforts...I'm really grateful for the attention and assistance.

 

[P1LGRIM]

I extracted frames and matched them up into a single composite image

Good work, well done

Typical of misconfigured graphics.

If possible you should disable the Serial port(s) (SuperIO) in the BIOS settings, they sometimes conflict with graphics drivers.

 

[Feartech]

OK, I actually managed to retrieve the complete onscreen log, from after the OpenCore handoff and the boot selector right up until it goes to black and then to gray, and freezes. As I wrote above, I shot a 60fps movie — I extracted frames and matched them up into a single composite image (and quadruple-checked to make sure that I had the entire log with no omissions) — it's attached below.

As I wrote above, thank you all again for your tireless efforts...I'm really grateful for the attention and assistance.

disable your serial port in your bios

 

[JordanOrlando]

Good work, well done

Thank you! It wasn't easy — I'm running Sierra, which can't deal with 60fps HEIF video, so I had to pull the frames on my phone.

Typical of misconfigured graphics.

If possible you should disable the Serial port(s) (SuperIO) in the BIOS settings, they sometimes conflict with graphics drivers.

disable your serial port in your bios

I'll try it! Thank you.

This is what amazes me about all of you guys. How on earth could you possibly discern that, from that big glut of data? Where are you seeing it? (You don't have to go to any trouble; I'm just curious.)

Also: there are many other warnings and errors throughout the log. Should I just ignore them? (Lots of "failed to initialize" or "such and such has this device ID; you should change it to this one.") Not showstoppers?

I'll post another copy of the above image of the log, where I highlight the ones I'm puzzled by — maybe you kind people can be persuaded to take the time and explain what they mean and whether they can be ignored (or postponed to post-install).

Thank you all again.

 

[P1LGRIM]

How on earth could you possibly discern that, from that big glut of data? Where are you seeing it?

 

[JordanOrlando]

View attachment 527087

I see it but I don't understand. (Obviously I don't need to understand in order to fix it.)

Thank you.

 

[JordanOrlando]

View attachment 527087

I went into BIOS and turned off the serial port. No difference — the boot went through what appeared to be the same logging and then got to the black screen and then the gray screen, and froze.

Thanks in advance for anyone's help or advice. As I said a few days ago, I'm in over my head and remain unsure that I can ever get this to work.