[Bug]: Crash on Boot / AirportItlwm Issues on Build

[danperks]

Zenbook Pro Duo Variant

i7/i9 UX581LV (10th-gen with RTX 2060)

OpenCore Version

REL-100-2024-05-09

macOS Version

Monterey (macOS 12)

Current Behavior

I'm looking to upgrade to Sonoma on my machine so I can start using the latest XCode. I have quite an old EFI from ages ago (no idea when) which has worked fine for Monteray so far.

As instructed in the repo, I launched the repo in a GH Codespace, and attempted to build the EFI. The build failed on the AirportItlwm kexts, as the version the build looked for (v2.3.0-alpha) appears to have been outright deleted from the repository. Seeing the latest version released was a stable version of the same v2.3.0 version number, I modified the build code to use that repository instead - which may be the cause of my boot issue.

After swapping out the versions, the build was successful and I had a new EFI. I redid my SMBIOS for a model that supports Sonoma and dropped the new EFI in my EFI partition (I dual-boot Windows and MacOS) along side my existing, function EFI.

However, trying to boot it doesn't go well. I chose it in rEFInd (my boot manager of choice), I pick MacOS again from the OpenCore boot manager (which I haven't yet disabled) and I get to the password entry screen. On entering my password, it attempts to load the Kexts and crashes before I get a chance to spot the error.

Interestingly, I am unable to provide a logfile because they come out corrupted and unreadable every time. I have attatched my latest log here but looking at the data, it appears to be useless bytes.

opencore-2024-07-23-223358.txt

If you have any ideas on where my issues may lie, even just to get good logs out, I'd be appreciative.

Expected Behavior

OCBuild should build successfully, and the new EFI should be functional.

Steps To Reproduce

No response

Anything else?

EssentialsList-2024-07-24 00.01.45.zip

[Qonfused]

I've since rewritten OCE-Build to use a newer configuration format, though unfortunately I haven't updated this repository to use the newer version or configuration. It would help for me to set that up as it provides a great deal of validation when building it; I've done it already for the UX481 repo for example.

It may help to delete the build.lock lockfile if there are some unresolvable entries (for the AirportItlwm v2.3.0 alpha builds). Since you're booting Sonoma, you'll need to make sure to use the AirportItlwm build for 14.4+ since there are two versions for Sonoma: https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/blob/6e4c9047fd6f74152667a623c86810e3f6667f5c/src/build.yml#L39-L49 (Note that this is a different format for the new version of OCE-Build; it does show the minkernel/maxkernel values if you choose to include both builds).

I imagine whatever is causing the crash after login would be happening in user-space, so it may be worth starting with disabling Bluetooth kexts and other non-essential kexts (though I'm not sure how disabling IOElectrify and ThunderboltReset affects boot). I'll have to take a closer look to see what needs to be updated for Sonoma specifically.

From experience with Ventura, this can also be an artifact of an old installation -- I wouldn't assume so out of the gate but it might disappear after a few reboots in case it's getting stuck on an old kernel panic/sleep diagnostic report.

[danperks]

Just realised I've pulled a fast one over myself and use the UX481 repo to build the EFI, which was never going to work. Will try the UX581, even with the older OCEBuild (might have to remove the lockfile) and see if I get any further, or at least some logs out (looks like it was failing in preboot, which I'm guessing is why my logs were corrupt).

Will report back soon!

[danperks]

Slight update, I realised how I managed to build the wrong EFI! The codespaces button in your README points to the wrong repo, as I almost just did it again lol. Might get it right the 3rd time

[Qonfused]

I've updated this repo to use the OCE-Build version and configuration format and fixed the GitHub Codespaces link. There weren't any issues detected at build-time, so the hope is that it should work without any changes.

The main changes this repo has compared to the UX481 repo are the thunderbolt kexts/patches, so the hope is that it has the same compatibility out of the box.

[danperks]

I was writing the comment below just as you posted your comment, so I'll add this to follow up.

To answer your statement, no, I don't think the compatibility is the same 😂 I can revert to the older Kexts which I assume would fix it, but then the question comes to whether there are Sonoma compatible versions of the Kexts that do work.

Still not sure on the bluetooth side.

===========

Okay, good new and bad news.

Good news is the new EFI built from the right repo works and boots no problem.

Bad news is, the ports on my Thunderbolt dock don't work (the display connected to it works fine though🤔) and Bluetooth also won't switch on, which meant I couldn't use my mouse at all haha.

Also, remind me whether the Screenpad display is meant to work at all? I can't see it as a display at all, but I feel like I did something a while ago to stop the flickering and just make it black, which may the same now. You may have no clue what I'm talking about, but hopefully your memory is better than mine!

On the USB side, I'm guessing it has something to do with the swap of USBPorts.kext and USBInjectAll.kext in my old config to the new USBToolBox.kext and UTBMap.kext, which you can see here:

No clue on the bluetooth, as the relevant Kexts are just newer versions (I assume) of what I already had in the working config.

[Qonfused]

At the very least being able to boot into the OS makes it significantly easier to debug. I was perhaps a bit premature in hoping for OOB compatibility, though they should generally both boot fine.

The Bluetooth issue might just be a byproduct of a USB mapping issue. It may be worth trying to map your USB ports on Windows with the USBToolbox Tool to replace the UTBMap kext in the repo. To be honest, I'm not sure the USBPorts approach still works on the last few versions of macOS.

I'm not sure what it maps to on your keyboard, but I'm pretty sure the 'toggle screenpad' button should still power off the screenpad. I've actually since gotten the whole screenpad device to work in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1987709248 back in March, but there isn't a fix for it yet (though there is a hacky workaround in that issue).

[danperks]

I'll give USBToolbox Tool a go in a few mins.

On the screenpad issue, it isn't showing up as a display anywhere in the system (inc Hackintool). Not sure if it's meant to while toggled off with the hw button, but the key on my device to toggle the screen does nothing. In addition to the toggle key doing nothing, my pause key tries to up the brightness, so my guess is the keyboard isn't correctly mapped?

Any suggestion on how I could test/fix that?

Hackintool connectors in case they mean anything to you regarding the screens:

[danperks]

So, USBToolbox seemed to sort it all out!

My USB-C dock devices are working, bluetooth is working and the Screenpad keys are working, although the screen still only shows a black screen - the keys only let me change the brightness or completely toggle the backlight.

Looking at the issue you linked, it appears the screenpad "works" but only by toggling the screen a bunch on boot while sometimes causes it to work once it's on? Correct me if I'm wrong on that. I might spend a few reboots attempting to try and replicate your findings but, if you want to close this issue as my problems are sorted and move to their for discussions, I'm happy to do so :)

UPDATE: Another issue, probably Kexts again, is audio. I have no internal audio coming out the laptop, nor does the monitor's audio show as an option. With this one, I'm not sure the audio ever worked on the internal speakers with any EFI I've used, but did work via the monitor before. Luckily I have a HomePod in the room as a backup for now! Any idea's would be appreciated.

[Qonfused]

Yeah, I was randomly toggling the connector power in a hotel room and it somehow worked after that. I've been able to reproduce it a few times since but it's hard to replicate the same timings. It doesn't persist between reboots or after sleep, but from what I've been able to tell, whatever the cause is for that issue can be fixed in software.

At the very least I can test and see how the device is initialized while it's working; the timing of the last connector toggle is what actually matters (if you notice the double paint of the wallpaper; when it fails, you'll see a single paint of the wallpaper before static or a black screen). I figure it must bypass some kind of device initialization for the iGPU (or perhaps it relaxes some constraints for the screenpad in some capacity).

If I can find a fix for the UX481, it'll be something you'll want to test on the UX581.

[Qonfused]

Audio for the internal speakers is controlled through the layout-id for AppleALC (to be honest, I'm not sure if this has worked before for the UX581): https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/blob/cc33ded1d09bb337bc4b6c4d129469337f1c9b5d/src/config.yml#L291-L310 I had thought this was the correct layout id for the device's codec (assuming it had worked the same for the UX582 and UX581), though you'll probably have to figure out which audio codec your device has to deduce which layout-id to use: https://dortania.github.io/OpenCore-Post-Install/universal/audio.html

At the very least you can fix HDMI/DP audio with a connector patch: https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/51 ^ Note that this is actually set for the internal display, which for whatever reason controls the audio outputs for the rest of the laptop's displays.

I'd also recommend adding the agpd=vit9696 boot arg in case there is some kind of AGDP conflict that is also suppressing audio: https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/blob/cc33ded1d09bb337bc4b6c4d129469337f1c9b5d/src/config.yml#L337-L343

[danperks]

Connector patch worked like a treat, readded my monitor to the audio list with working sound. Will try the boot arg to see if that sorts the actual internal audio. The boot arg you recommended is already set.

[Qonfused]

I'll have to create another issue to sort out internal audio; I believe it works correctly on the Coffee Lake UX581GV model though I no longer have a unit to verify.

I realize the USB mapping issue wasn't actually solved in #3; I only have the USB map for the UX581GV. @danperks Would you be able to upload the USBMap.kext you generated with USBToolBox? Technically your model (the UX581LV) shares the same USB mapping as the UX582, though it's easier for me to work with a known working mapping to update the build.

[danperks]

Thought I'd replied earlier but maybe good I didn't as I have some developments.

1. Happy to share my USB config but I do have 1 dead USB - probably better than the default no working one, but not perfect as it'll likely kill the left USB for anyone else who uses it.

2. So, I've successfully just updated to Sonoma. I did have to disable the SecureBootModal option in my EFI before it would install. Without that, it would all look like it was installing but would eventually boot in the old OS version.

3. Now I've installed, my WiFi and my Bluetooth seem to have broken. Wi-Fi won't even turn on, and Bluetooth refuses to pair or connect to any devices (specifically my mouse) at the moment.

I'm using the latest version of the relevant Kexts as far as I'm aware, and my guess is the USB mapping wouldn't vary between MacOS versions? I've also cleared NVRAM and rebooted a few times.

Any suggestions would be great, thanks again for all the help so far!

[Qonfused]

Disabling SecureBootModel when first booting into the installer is relatively normal; it may also be required for macOS Sequoia on hacks going forward.

The USB mapping created through USBToolBox is independent of the macOS version or SMBIOS, so it should work the same across all versions. Also your USB mapping would only affect Bluetooth, and both WiFi and Bluetooth not working points more to AirportItlwm as the culprit.

I believe the current state of AirportItlwm on Sonoma (14.4+) may leave iServices non-functional, though (nominally) AX200/AX210 WiFi should still work. To be able to debug it, I'd recommend using HeliPort or manually collecting airportd/kernel logs as outlined here.

It may also help to boot into Windows and then reboot and boot into macOS through OpenCore. This is a warm-reboot, which hopefully would eliminate any isolated issues with firmware uploading to the WiFi card (also applicable to Thunderbolt).

[danperks]

Managed to pull another blinder on this one. Tried to pull logs using Heliport but it said it could find any data. So then I checked what Kexts were loaded, turned out non of the AirportItlwm were loaded. Not sure how, but they never got added to my config. Added them in, copying the min/max kernel from your build.yml file in this repo, reboot, and everything work (including iServices!)

Unless you think it's worth it, I won't bother with my half-done UTBMap.kext file, as the left USB would not be mapped.

Thanks for all the help with all these issues, I've learnt a bunch about the world of Hackintosh's and can now get on to learning some Swift and some iOS app design! <3

Happy for you to close the issue if you have nothing else to add, just may be worth adding the SecureBootModel toggle to the README if it's not there already regarding updating, as it fails silently without that.

[Qonfused]

Tried to pull logs using Heliport but it said it could find any data. So then I checked what Kexts were loaded, turned out non of the AirportItlwm were loaded.

Was this built with the old version of OCE-Build? I did update this repo to use the new version in https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/commit/cc33ded1d09bb337bc4b6c4d129469337f1c9b5d. Though the AirportItlwm kexts use the same SHA1 commit hash to mark the revision, they have different binary hashes:

https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/blob/1525c7afc96bf0af26dafc82cb7457c1ad94091e/src/build.lock#L114-L161

Happy for you to close the issue if you have nothing else to add, just may be worth adding the SecureBootModel toggle to the README if it's not there already regarding updating, as it fails silently without that.

Before Ventura 13.5 I used to leave it disabled by default; I can do so again to prevent that from coming up. The current Apple Secure Boot policy is equivalent to medium startup security. It doesn't provide much security benefit unless combined with ApCEID to offer the full security level.

[danperks]

It's quite possible I used the old OCE-Build version but couldn't guarantee either way.

Have just noticed that I can't seem to wake up MacOS once it turns the screen off. Plugged into power so not just a battery thing.

Interesting, the toggle for the bottom display still works, so it's not like it's frozen up or anything, just won't wake the screens up from sleep. Feel like I had this issue on previous versions too, as I had it set to never sleep.

[Qonfused]

It may be that only the FN+Lock and screenpad controls are properly reset after wake https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/blob/876f6ab983ad3e1496e5285dc579d29ac94a1b68/src/ACPI/SSDT-XWAK.dsl#L19-L40

There isn't any handling for the primary display after wake, which iirc is a problem for the UX582 as well. You can try adding the igfxonln=1 boot arg (or force-online | Data | <01000000> device property) to try and force the display to reinitialize.

[Qonfused]

Actually, it is already added under iGPU properties: https://github.com/Qonfused/ASUS-ZenBook-Pro-Duo-15-UX581-Hackintosh/blob/876f6ab983ad3e1496e5285dc579d29ac94a1b68/src/config.yml#L267

There is probably some kind of device/driver conflict within macOS that is causing this behavior, as the firmware-level reset works for the screenpad and keyboard. My main suspect would be ThunderBolt, though sleep can also get stuck because of an unmapped PCI device: https://dortania.github.io/OpenCore-Post-Install/universal/sleep.html