Open sdwannfv opened 1 year ago
I've never seen anything like this. It happens so deep in system code that it probably isn't due to a bug in HookCase.
Please provide as much information as possible about what you were doing when this kernel panic happened. Were you trying to load a hook library? If so please post its source code, and let me know which process you were loading it into?
The stack trace indicates the OS was working with compressed files, and checking the amount of free space on some drive. How much free space do you have on your boot drive?
Is your Mac by any chance a Hackintosh? :-)
not Hackintosh, but my macos system is on external udisk, maybe it cause this, i will put more message if i can reproduce it
I've finally figured out these kernel panics. You're using the OpenCore Legacy Patcher. For now at least, HookCase is incompatible with it.
I just used OCLP myself to install macOS Ventura 13.3.1 on a machine that Apple says doesn't support Ventura -- a "mid-2015 MacBook Pro", model id MacBookPro11,5. I get exactly the same kernel panics. I haven't (yet) found a workaround.
Actually, I'm no longer sure you're using the OpenCore Legacy Patcher. Your MacBook Pro (model id MacBookPro15,2) supports macOS 12 natively, so you don't have any need for OCLP.
Instead you have kernel boot-args (chunklist-security-epoch=0 -chunklist-no-rev2-dev
) that are associated with lots of kernel panics, most of which have nothing to do with HookCase. Do you know where these boot-args come from? I haven't (yet) been able to find out on my own. They're not set on the Mac where I'm using OCLP, and they don't appear to be related to it.
To see the other kernel panics, do a search on "chunklist-security-epoch=0".
Here are a couple that are symbolicated:
https://openzfsonosx.org/forum/viewtopic.php?f=26&t=3669 https://github.com/OpenIntelWireless/IntelBluetoothFirmware/issues/335
I've found a reference to those puzzling kernel boot-args, in source code for macOS 12's xnu kernel. They seem to belong to Apple's boot.efi
. I still don't know what they mean, but it's pretty clear they're Apple-native. Though it's possible they were set by third-party software -- for example OpenCore.
/*
* Boot argument for disabling trust in rev2 development key(s)
* Set by boot.efi
*/
#define CHUNKLIST_NO_REV2_DEV "-chunklist-no-rev2-dev"
/*
* Boot argument for disabling trust in rev1 chunklists
* Set by boot.efi
*/
#define CHUNKLIST_NO_REV1 "-chunklist-no-rev1"
/*
* Boot argument for obtaining current security epoch
* Set by boot.efi
*/
#define CHUNKLIST_SECURITY_EPOCH "chunklist-security-epoch"
#define CHUNKLIST_MIN_SECURITY_EPOCH 0
I'm recategorizing this yet again. I no longer believe you're using OCLP, though I can't help but think there's something nonstandard about your setup (which might explain your "chunklist" kernel boot args).
I'm about to release a new version of HookCase that works with OCLP. I found I needed use a kernel_stack_pages=16
boot arg. If you see this panic again, you should try that. Please also try the new version, once I release it.
I've just released HookCase 7.3. Please try it out. If you really are using OCLP, see Using the OpenCore Legacy Patcher for detailed instructions on how to set kernel_stack_pages
.
It turns out that "chunklist-security-epoch=0" and similar boot args are unrelated to this bug. I now always see them on macOS 11 and 12 -- whenever I've booted from real SSDs (internal or external). The only time I don't see them is when I'm running these versions of macOS in a virtual machine (where I've booted from virtual hardware).
Previously I used nvram boot-args
to detect my kernel boot args. But it reports only the ones you've set explicitly (using sudo nvram boot-args=[whatever]
). To see your actual boot args run sysctl kern.bootargs
.
They seem to have disappeared with macOS 13. I don't know why.