Monterey Hacintosh on Dell 9020 MT – Trials and Tribulations

This post is meant mostly for me – to log what happened to get me to the my final install guide. But it might have some info that will be useful to someone else who encounters the same issues. If you are just looking for the steps to do an install, skip right to the install guide post. I describe all the hardware decisions in a prior post about hardware, including why I am working with what is an old computer to start with.

With my new hardware ready to go, I started by researching OpenCore. Previously, I had used Chameleon (E520 and E6410) and then Clover (9020, E6430, and E5470) to set up my Hacintoshes but with the aim of having a build that will last as long as possible, OpenCore seems like the best choice. The current MacOS build is Monterey or MacOS 12, as it is also known, and from what I could tell from my research, it seems that OpenCore provides the best platform for Monterey, and presumably what might come after. It seems likely that Apple is going to drop support for Intel entirely at some point and they are already making the experience better for their M1 computers than for the Intel computers. So this may well be the last Hacintosh I’ll be able to build. So for at least however long I can get out of this OS and this build, I figure I might as well make it as stable as possible.

I read through the OpenCore guide. In fact, the first thing the guide tells you to do is read through it, so I did. The guide is amazingly well written in content though I will say it gets a little hard to go through it linearly at some point. Things branch off based on choices and hardware so you sort of have to just stick to a mainline read-through and have a sense of what path your ultimate install will end up taking. Also, when it gets to the Post-Install part, then it switches to a different guide and the path is even less linear so again, just do your best to read what makes sense.

I should also note that while OpenCore is more modern and more complete than Clover, it’s also a bit more hands-on than Clover would have been. If you are starting from scratch in either Clover or OpenCore, there’s some serious work with the DSDT content to create AML files. But with Clover, once those are done, you can just share a bootpack as is whereas with OpenCore, you can’t really share a bootpack – you still need to make modifications in the plist file for your build. Again, this probably is what leads to a better result but it makes it more challenging for the most novice builders. (In my following install guide, I do have a bootpack to share but there are also some steps around how to use it that require some BIOS level hacking and modifying it to include the SMBIOS content.)

My entry point for starting my build was a post at OSXLatitude for the 9020 and Big Sur. The creator of that post starts from a point of assuming the reader knows how to build OpenCore which was another reason I needed to start with the OpenCore guide. So my first attempt would then be effectively doing what the OpenCore guide told me to do supplemented by the 9020/Big Sur post.

I got stuck early on in trying to get the right versions of Python installed and dealing with the correct version of “tk”. Going with the mac version failed on Monterey so it was better to get the “real” Python3 from python.org.

As far as the tools that the OpenCore install guide recommends by “corpnewt”, there is something to be said for simple Python scripts that do only what you need and are super-lightweight. On the other hand, you still need to install developer tools, python3, and pip3 which are not at all lightweight. And you end up with a pile of directories and scripts. There’s a big opportunity for improvement here in creating a single app that does all that you need to do for an OpenCore install. If I ever figure out how to clone myself, I’ll have one of my clones work on that at some point.

Using modGRUBShell to run the setup_var commands was pretty easy. At first I wasn’t thrilled about hacking into the BIOS but the more I thought about it, the more I realized that these are BIOS settings like the ones that you see in the BIOS setup pages – except these settings never were simply never exposed in those setup pages. So this is a way to make the changes to things that don’t show up in the BIOS setup pages but are otherwise similar to the settings that are visible in the BIOS setup pages. And the fact that it reports some sort of warning about each change is apparently just how modGRUBShell works and not really something to worry about.

After getting the installer built and booting, I got an error about the version of MacOS not being supported on my platform. To get a sense as to how close to the edge I’m living here with this old hardware, the recommended Mac system for my Haswell computer is “iMac15,1” but it turns out that Big Sur was the last OS version supported on that hardware so I swapped to “iMac17,1“. It’s pretty easy to imagine that the next release of MacOS will drop support for the iMac17,1 also, in which case, Monterey may well be the last Hacintosh OS I’ll be using. That change resolved the platform error. And it’s always exciting when you get to see the Apple logo after pages of debug messages.

I kept getting burned by DiskUtility where it would not default to showing the Devices. I realized that when you don’t see the opportunity to select the partition scheme, that means you aren’t actually at the device level. DiskUtility starts by only showing the partition contents so you have to switch it in the View menu with “Show All Devices”.

After starting the install, it got stuck in the reboots at the end. Some Googling resulted in my changing the config.plist SecureBootModel from “Default” to “Disabled”. I was then able to complete the install. But as you’ll read a few paragraphs below, I realized that this was not the real solution.

Once the computer was up and running, I followed the instructions to set up the USB ports. I had found that the USB ports weren’t all correct on my computer using the EFI folder from that original post. After lots of plugging and unplugging USB2 and USB3 devices, I created the USBMap.kext file that seemed to work well. Although I didn’t have the Fenvi card set up at this point so I had to take a guess at the internal USB port as being 13. When I did get the Fenvi card installed, it turned out my guess was correct so I didn’t need to redo the USBMap file. Here is the port mapping I figured out with numbering for the front panel and back panel going left to right when the tower is upright with the bottom facing down and the viewer looking at the front or back panel:

MacOS will install with sleep enabled and that should work. However when my computer went to sleep, waking it up would cause a kernel panic. Based on the error info, it seemed that it had to do with the display. I realized I was probably going to need to monkey around with the settings in the config.plist to fix that.

But it was about this point that I tried to get the GUI working for the OpenCore booting and it just wasn’t working. I realized that the bootpack I had started with included OpenCore 0.6.6 which was pretty old so I figured getting the latest version of OpenCore would resolve the GUI issue. But as soon as I did that I got a pile of “OCS” errors on boot complaining about “no scheme”. That turned out to be due to an incompatibility between the config.plist file and the new OpenCore content. So I got the latest config.plist sample and tried copying over the settings from the bootpack 0.6.6 config.plist into it. It did resolve the “OCS” errors but then MacOS wouldn’t boot. It kept getting stuck at “[EB|#LOG:EXITBS:START]” which seems like a pretty basic problem.

Getting frustrated, I went back to OSXLatitude and found somebody who was able to share their EFI for a 9020 that was running OpenCore 0.8.5. I actually spent a fair amount of time comparing the two config.plist files to see what I was doing “wrong”. But in the end, there was just too much different to figure out what resolved my problem. The kexts were pretty much the same but the AML files were different and a large number of settings were different between the two. I still want to know what did the trick but not enough to even put one of my clones on the task. At this point, I’m just happy I’ve got the current version of OpenCore working with the current version of MacOS on my 9020.

I did keep the USBMap.kext I had created. And I ended up merging in some of the content from the prior bootpack. For example, the newer bootpack enabled the patch that worked around not having done the BIOS setup_var steps but since I had done that, I put the modGRUBShell back in to the EFI content and turned off the patch.

Then I set up the GUI and the sound so it would do the Mac sound when it booted. I think that’s a nice touch on a Hacintosh.

I did all of the above with the “boot-flags” set with “-v” but then removed that when I had the EFI partition the way I wanted it.

The OpenCore guide has some info about fixing DRM. I thought it’d be cool to get that working too. But the more I dug into it, the more I realized it just wasn’t for me. The main thing is that the built-in Intel GPU will never work with DRM content. The only way to get it to work is get a new video card from a set list of video cards. And most of them are pretty expensive and take up two card slots (technically I have the two slots open but I’d like the possibility of installing a Firewire card at some point for backward compatibility to some of my older devices). I haven’t done anything that would require DRM in the past and don’t see the likelihood of needing to do it in the future. (I don’t sit in my office at my desk chair to watch Netflix, for example.) I can see if this was a laptop how it would be more important to get it working but I decided to skip that entirely.

All of this time with the new Hacintosh running, it’d periodically burp. At least that’s what the noise sounded like coming from the computer and the two optical drives would have blinking lights. (I didn’t mention in my hardware post that in addition to the optical drive I added the computer came with an optical drive that I left in place – I will probably swap that one for one of the better optical drives from my older 9020 Hacintosh at some point after I switch my daily use to the new one.) The burp would happen seemingly every few minutes. At one point I timed it and it was about 7 minutes but the next time was longer. I eventually traced it to the MacOS trying to put the hard drives to sleep and the optical drives reacting to being told to go to sleep. The fix was to turn off the sleep for hard drives.

As with my prior Hacintosh build, I have found that when running two DVI monitors from the built-in DisplayPorts, I need to have one of the DisplayPorts connected to a passive DVI adapter and the other to an active DVI adapter. When they were both connected via passive adapter, the computer would never boot up. I tried changing many of the settings in the OpenCore config.plist for the GPU section DeviceProperties/PCIRoot(0x0)/Pci(0x2,0x0) and did not succeed. (Maybe the “flags” would have been useful for that but I could never figure out what the appropriate value might be.) I’m a bit disappointed that I couldn’t figure that out but it shouldn’t really matter. (And BTW, the reason for the DVI is that I have a DVI KVM that will be hooked in to my active adapter.) Though I was able to improve the GPU section so that it now has the correct connector information in it.

At least I thought I was all set but I started getting monitor glitching. The display would just blink off and then come back on initially but then it would blink off and on repetitively to the point where it was seizure inducing. Generally, it would not be an issue right after booting up or even after having been booted up for a while but when the screen saver had turned the display off. But not too long after it would start glitching and the longer I went, the worse the glitching got. I had seen this sort of behavior once before but never resolved what was causing it and it had gone away on its own. But this time, it definitely wasn’t going away and was only getting worse. And I started worrying that whatever the computer build was doing to cause this might actually damage my monitor.

My first step in debugging was to see what would happen if I used a DP cable directly between the computer and the monitor, bypassing the DVI KVM and the DVI/DP adapter. It worked perfectly. Which meant that the monitor was fine and MacOS was okay with the monitor but there was something about the setup or the hardware connection that was not correct or compatible.

I again looked into swapping the active and passive adapters but that didn’t work. And then I went back to the settings in the OpenCore config.plist and looked again at the memory settings for the GPU section. I locked in to the idea that the problem was related to how the BIOS was handling the GPU memory and that it needed the right settings for it to work. So I went back to the GPU part of the config.plist and looked more closely at the options. I tried changing the ig-platform-id to a number of different options other than the default of 0300220D (or 0D220003 as the actual ID not the reversed value). I used the WhateverGreen doc as a guide and went through the stuff hidden in the Azul connectors section. I also found the following posts useful while working on this issue: Graphics Stuttering HD4600, Graphical glitches on Haswell HD 4600 laptop, Help with HD 4000 on Big Sur, How to Enable Intel HD and UHD Graphics on macOS, Patching Bus IDs, Intel HD Graphics, How to enable 4k on HD4600 iGPU in OpenCore, and Help with HD 4000 on Big Sur.

And to do this quickly, I tried using OpenShell.efi as described in this post. For me, after booting up and selecting OpenShell.efi, at the prompt, I would do the following:

FS0:
cd EFI/OC
edit config.plist
F4, <type thing to find>, Y | N
F3 to exit, Yes [to save]
ctrl-alt-del [to reboot]

None of the other options I tried were any better, however. Unsurprisingly, the best fit was the one that I started with, the “default” of 0300220D. But I still got the glitching.

I also tried a couple of app installs to see if adding that additional layer would sort of calm things down. I don’t remember all of the apps I tried, but one of them was BetterDisplay. It seemed like it had some nice features but ultimately I didn’t need them and it didn’t solve the monitor glitching.

Eventually, I swapped the monitors connected to the ports and that full resolved the problem. I had started with my Asus PA248 1920×1200 connected through the KVM to the top DisplayPort through the active DVI/DP adapter and the Samsung 204B 1600×1200 connected to the bottom DisplayPort through a passive DVI/DP adapter. But I switched to having my Asus PA248 1920×1200 connected through the KVM to the bottom DisplayPort on the 9020 through a passive DVI/DP adapter and the Samsung 204B 1600×1200 connected to the top DisplayPort through an active DVI/DP adapter. After that swap, all the glitching went away. (Okay, one time, there was a glitch, but just one time.)

Why would that swap have mattered? I don’t really know. It was a desperation move that was simple but I hadn’t done before because it seemed so unlikely to have any impact. But while debugging, I had noticed that in the Display Settings, the display that was connected to the top DP was considered the “iMac” display while the second display had the model information for that display hardware – and presumably, that top port is the one that effectively turns into the “internal” display of an iMac. So it’s possible that MacOS handles the graphics memory better when the top port matches the smaller resolution. Or it’s possible that the active adapter in that port is more important. Or maybe it is that the KVM doesn’t work well with the top port because it is expected to be an integrated display in an iMac. Or maybe the passive adapter works better with the larger resolution monitor. Or maybe there’s a conflict with the framebuffer memory values I used that works fine for one monitor but not for two and this new setup happens to sort of cheat around it. I really wish I knew but the important thing is that has ended up stable.

Okay, so I think that is most of the interesting blog-worthy tales of the trials and tribulations to this install. The above is what resulted in the bootpack that works for me and the set of steps to use it. And with that, it’s time for the Install Guide.