-
Notifications
You must be signed in to change notification settings - Fork 627
Fix sticking at KernelCache validating on Tahoe #126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
WhateverGreen/kern_rad.cpp
Outdated
| // 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) { |
There was a problem hiding this comment.
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.
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.
|
Now it works perfectly on macOS Tahoe, supporting installer/recovery mode/OTA. |
|
It turns out that it works very stably on macOS Tahoe and has been tested a lot. The following is the feedback from a small number of users. |
|
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")) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
ioregdump? Ideally bothIODeviceTreeandIOServiceplanes.
Unfortunately, ioreg only recorded BootKernelExtensions.kc. And there is no other obvious difference except BaseSystemKernelExtendes.kc.
There was a problem hiding this comment.
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 ^^
There was a problem hiding this comment.
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
|
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😂 |
|
Hmm, that is problematic, SSH also does not work? |
Yes, the entire system crashed directly. |
|
Also, your recovery dump does not include IODeviceTree plane, thus e.g. |
|
here |
|
From this I see several candidates for OTA test:
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 |
|
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 |
Fix "WEG Causes Boot Hang in macOS Tahoe Installer (Auqa Session issue), Works After Installation" acidanthera/bugtracker#2509