hackingaway, were you able to get this working? After many hours of struggling, I successfully completed the install last night. I thought I'd share my process for anyone who's having trouble, and also for feedback and input by anyone who knows more about this than I do (which is not very much).
I'm still having a lot of trouble with the post-install, particularly the graphics and possibly the USB, and I haven't been able to get tony's solution to work for me – but that's a story for another board.
BIOS Configuration
- <F2> or <DEL> to enter BIOS
- <F3> to set Optimized Defaults
- Advanced > CPU Configuration > Intel Virtualization Technology: Disabled
(Not sure about this step. I came across references to disable VT-d – e.g., Lifehacker – but I'm not sure if this is the same thing. In any case, my system would occasionally freeze without notice, both during install and after, until I disabled this setting.)
- Advanced > CPU Configuration > CFG Lock: Disabled 1
DSDT Patching: Possibly Unnecessary?
Not to question tony's authority, but this is where I wonder if maybe I could have saved myself a heap of trouble. My first time around, I didn't disable Intel VT. The UniBeast USB booted fine, installation started up without a hitch, and then it froze when the screen read about 7 minutes remaining (not a hung installation, but unresponsive to keyboard/mouse input as well). That's when I stumbled on this thread and wound my way down the twisty,
-til-sunrise path of DSDT patching.
After patching the DSDT, the installation completed okay, but I experienced another spontaneous freeze post-install. That's when I disabled Intel VT and the freezing went away. I am preparing to retry the installation without FakePCIID and the patched DSDT, but if anyone else wants to chime in with some insight, I'd be happy to hear it.
---EDIT---
Okay, shouldn't have questioned Tony. Disabling Intel VT alone did not resolve install-time hangs; DSDT patching / graphics id spoofing was likely what made install possible, though the issue is still far from fixed.
---/EDIT---
DSDT Patching: The Process
I copied the specified kexts from FakePCIID to the install USB (/System/Library/Extensions),
2 which took about five seconds. Patching the DSDT, as a first-timer, was a bit more of a challenge.
For anyone who, like me last night, knows nothing about DSDTs, the gist is that it's information supplied by the BIOS that helps the OS interface with on-board hardware. On systems where the hardware is not made for the software, or vice versa (
e.g., Hackintoshes and some Linux boxes), DSDTs may need to be modified to help the OS figure out how to use the hardware. Fortunately, this can be done without overwriting the motherboard's built-in DSDT; just place the modified DSDT in the right place on your hard drive, and Mac OS will look there before consulting the one supplied by the BIOS.
The trouble is that the DSDT (and other ACPI tables) provided by your BIOS are compiled into machine language – that is, not human-readable. In order to apply patches, they must first be decompiled into human-readable code, then edited, then re-compiled back into machine language for the OS to use.
What the Guides Told Me to Do [Ubuntu LiveUSB Method]:
- Pull the native DSDT from the machine:
Code:
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
- Decompile the DSDT from machine language (.aml) to a .dsl file
- Apply the patch with the utility of your choice
MaciASL seems to be the most widely endorsed around here; DSDTEditor is a GUI tool written in Java, meaning it's cross-platform.
- Re-compile the .dsl back into a machine-language .aml
DSDTEditor Demo (YouTube)
- Place your new DSDT.aml file in /Extra to override the onboard DSDT.
But I kept getting the following warning message at
Step 2:
Code:
iASL Warning: There were 11 external control methods found during
disassembly, but only 0 was resolved (11 unresolved). Additional ACPI
tables may be required to properly disassemble the code. The resulting
disassembler output file may not compile because the disassembler did not
know how many arguments to assign to the unresolved method.
What Worked (Sort Of):
Sure enough, when attempting to re-compile (
Step 4), iasl / DSDTEditor would throw errors. I eventually discovered that supplying
SSDTs to iasl at decompile time resolved some (but not all) of the issues:
Code:
sudo cat /sys/firmware/acpi/tables/SSDT1 > ssdt1.aml && \
sudo cat /sys/firmware/acpi/tables/SSDT2 > ssdt2.aml && \
sudo cat /sys/firmware/acpi/tables/SSDT3 > ssdt3.aml && \
sudo cat /sys/firmware/acpi/tables/SSDT4 > ssdt4.aml && \
sudo cat /sys/firmware/acpi/tables/SSDT5 > ssdt5.aml && \
sudo cat /sys/firmware/acpi/tables/SSDT6 > ssdt6.aml && \
sudo iasl -e ssdt*.aml -da dsdt.aml
Now, the warning message read:
Code:
iASL Warning: There were 10 external control methods found during
disassembly, but only 6 were resolved (4 unresolved)...
Returning to
Step 3 above, I applied
the patch provided by the-darkvoid in tony's link above.
Code:
into method label _DSM parent_adr 0x00020000 remove_entry;
into device name_adr 0x00020000 insert
begin
Method (_DSM, 4, NotSerialized)n
{n
If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }n
Return (Package()n
{n
"device-id", Buffer() { 0x12, 0x04, 0x00, 0x00 },n
"AAPL,ig-platform-id", Buffer() { 0x06, 0x00, 0x26, 0x0a },n
"hda-gfx", Buffer() { "onboard-1" },n
"model", Buffer() { "Intel HD 4600" },n
})n
}n
end;
(tony mentions ig-platform-id "0x
a260006" in the post above, which appears as "0x
06 0x
00 0x
26 0x
0a" in the-darkvoid's patch. This part had me very confused for at least a couple hours, but I'm pretty sure, as you can see by my handy-dandy color-coding, that these are the same number in two different formats with the byte-order reversed. I still have no idea what that means or why, though.)
(I also haven't figured out why, in the two DSDT patches provided by the-darkvoid, one has "n" at the end of each line in the 'begin/end' block while the other has "\n" instead. In most of the DSDT patches I see on github, it's \n, so I went through and replaced "n" with "\n" before running this patch. I also changed the name on the "Model" line to "Intel HD 4400", and have no idea whether that's okay.
)
But now I was getting an unrelated error on compile!
This patch by RehabMan did the trick. (There appears to be reference elsewhere that
this MDBG error is common, and that it's unproblematic to remove the offending code.)
Here's the DST (both compiled and de-compiled), if anyone's interested. Definitely more for review, testing, and feedback than production use.
View attachment dsdt-bxi5h-patched.zip
Onto
Step 4: After the SSDT fix, the DSDT compiles without a hitch. (Well. It compiles without about 30 warnings, but no errors!)
Step 5: dsdt.aml is moved to the /Extra/ folder of the UniBeast install USB.
Boot UniBeast & Install
Hopefully, this step requires no further explanation.
Conclusion
So that's what worked for me. Kind of. Like I said, there are a lot of wrinkles to iron out post-install, most notably the graphics, which the DSDT patch does not seem to have really fixed. The mouse is also skipping and lagging, especially when there's another USB device connected. I'm still hoping to figure out if I could actually skip some of the more laborious steps I took, and whether I'm even doing DSDT patching right in the first place.
This machine was on the recommended build sheet! I went into this expecting it to be way easier than it has turned out to be. If anyone has any insight, I'd really, really appreciate it.
