Skip to content

Conversation

@laobamac
Copy link

Fix "WEG Causes Boot Hang in macOS Tahoe Installer (Auqa Session issue), Works After Installation" acidanthera/bugtracker#2509

// This step is unnecessary and will cause macOS Tahoe recovery mode to freeze when booting.
// Committed by laobamac
if (getKernelVersion() >= KernelVersion::Tahoe) {
if (kextRadeonServiceManager.loadIndex != index) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ifNeedOverrideConnector is only ever called when index == kextRadeonSupport.loadIndex. Does this not have the affect of removing all connector patches in all Tahoe versions?

Removed references to AMDRadeonServiceManager and updated connector override logic.
@laobamac
Copy link
Author

ifNeedOverrideConnector is only ever called when index == kextRadeonSupport.loadIndex. Does this not have the affect of removing all connector patches in all Tahoe versions?

Yes, because RadeonServiceManager will load normally when macOS starts normally.


We can change it to a simpler way, see the latest commit.

Added check for 'com.apple.recoveryosd' service in isNormalSys function.
Added fileExistsAtPath function to check for file existence and updated isNormalSys logic to handle new conditions.
@laobamac
Copy link
Author

laobamac commented Nov 1, 2025

Now it works perfectly on macOS Tahoe, supporting installer/recovery mode/OTA.

@pyquick
Copy link

pyquick commented Nov 2, 2025

Yes, it could work well on Tahoe&rec

// Because in the second stage of the OTA (when the macOS Installer finishes booting and the volume
// label returns to Macintosh HD), it still uses BaseSystemKernelExtensions.kc, but Lilu mistakenly determines
// it as a normal boot. This causes it to still freeze during the KC verification stage.
if (fileExistsAtPath("/System/Library/KernelCollections/BaseSystemKernelExtensions.kc")) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we want this to be fixed on Lilu side.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we want this to be fixed on Lilu side.

As of now, only this patch has encountered issues on macOS Tahoe. Perhaps modifying WhateverGreen is already simple enough, there is no need to modify Lilu temporarily

if (kextRadeonSupport.loadIndex == index) {
processConnectorOverrides(patcher, address, size, true);
// The abnormal start-up system does not cover the connector on Tahoe.
if (ifNeedOverrideConnector(patcher, index, address, size) != false) {
Copy link
Collaborator

@vit9696 vit9696 Nov 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After we fix Lilu to correctly detect normal mode I believe the change here should look as follows:

if (getKernelVersion() < KernelVersion::Tahoe
  || checkKernelArgument("-radconnector")
  || lilu.getRunMode() == LiluAPI::RunningNormal) {
  processConnectorOverrides(patcher, address, size, true);
  DBGLOG("rad", "processing override connector");
} else {
  DBGLOG("rad", "skipping override connector");
}

No other changes should be necessary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After we fix Lilu to correctly detect normal mode I believe the change here should look as follows:

if (getKernelVersion() < KernelVersion::Tahoe || checkKernelArgument("-radconnector") || lilu.getRunMode() == LiluAPI::RunningNormal) {
  processConnectorOverrides(patcher, address, size, true);
  DBGLOG("rad", "processing override connector");
} else {
  DBGLOG("rad", "skipping override connector");
}

No other changes should be necessary.

I understand, do you mean to put the method that recognizes BaseSystemKernelExtendes.kc into Lilu's getRunMode?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we could go this way if no better is found. Please make sure we guard it with macOS 26, so that we definitely do not regress on older operating systems. Ideally we want a lighter approach.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we could go this way if no better is found. Please make sure we guard it with macOS 26, so that we definitely do not regress on older operating systems. Ideally we want a lighter approach.

But when Lilu.kext checks the running status, the root file system may not have been loaded yet, and using vfs_lookup at this time will cause a panic.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I think we should find some other approach. Do you have an ioreg dump? Ideally both IODeviceTree and IOService planes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I think we should find some other approach. Do you have an ioreg dump? Ideally both IODeviceTree and IOService planes.

Unfortunately, ioreg only recorded BootKernelExtensions.kc. And there is no other obvious difference except BaseSystemKernelExtendes.kc.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, could you upload one for me to think about it as well? If it contains private data, you could also e-mail me to vit9696 at pm dot me ^^

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, could you upload one for me to think about it as well? If it contains private data, you could also e-mail me to vit9696 at pm dot me ^^

OK, Wait for me a moment, I will restart into Recovery and save one

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

The system in the second stage of OTA is unable to capture IOReg. But in fact, we just want to know how to implement the OTA phase😂

@vit9696
Copy link
Collaborator

vit9696 commented Nov 2, 2025

Hmm, that is problematic, SSH also does not work?

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

Hmm, that is problematic, SSH also does not work?

Yes, the entire system crashed directly.
It's not ruled out that it's a problem with my machine, maybe you can also try OTA.

@vit9696
Copy link
Collaborator

vit9696 commented Nov 2, 2025

Also, your recovery dump does not include IODeviceTree plane, thus e.g. chosen is missing. The command should be ioreg -l -p IODeviceTree.

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

rec2.txt.zip

here

@vit9696
Copy link
Collaborator

vit9696 commented Nov 2, 2025

From this I see several candidates for OTA test:

  • We could try to check whether IODeviceTree:/chosen/booter-name contains bootbase.efi or boot.efi.
  • We could try to check for IODeviceTree:/chosen/root-snapshot-name presence.
  • We could try to check whether IODeviceTree:/chosen/boot-file contains boot\System\Library\KernelCollections\BootKernelExtensions.kc or something else.

Ideally we need an IOReg dump from OTA v2 stage though, hard to be sure otherwise.

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

From this I see several candidates for OTA test:

  • We could try to check whether IODeviceTree:/chosen/booter-name contains bootbase.efi or boot.efi.
  • We could try to check for IODeviceTree:/chosen/root-snapshot-name presence.
  • We could try to check whether IODeviceTree:/chosen/boot-file contains boot\System\Library\KernelCollections\BootKernelExtensions.kc
    or something else.

Ideally we need an IOReg dump from OTA v2 stage though, hard to be sure otherwise.

These are all unavailable, I have already tried them here. Because the second phase of OTA has already used boot.efi and BootSystemExtendes.kc, BaseSystemKernelExtendes.kc will only be loaded just before initializing the user interface.

This is my attempt from last month, and my thoughts are the same as yours. But it is not available.kern_extra.zip

@laobamac
Copy link
Author

laobamac commented Nov 2, 2025

My friend, I will come back tomorrow to see this issue. It's already 2:10 in the morning in China, I'll go rest first.

bye

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants