For now, I will just write up these steps and share here. For future reference, I've now written it up here https://jaitechwriteups.blogspot.com/2025/10/boot-custom-macos-kernel-on-macos-apple.html It's been a very long time since I've done this, but the main thing I remember is that you need to be very careful to ensure that you've exactly matched up versions so that "everything" is the same exact version (kernel source, KDK, developer tools, etc.). Thank you Kevin for that hint. I suspected it wouldn't be straightforward. It's still on my TODO list to experiment with that and hopefully get it to work in the coming weeks. If it does, then it will help in a big way in debugging (and reporting) some of the issues we have been running into recently.

OK, so this is the part I haven't explained as well as I should. You don't actually need to build the kernel, as you already have a development build of the kernel in the KDK. That's what "kernel.development.t6020" and "kernel.kasan.t6020" installed by the KDK in /System/Library/Kernels "are" That was it - I built a kext collection using this pre-shipped kernels in the KDK and I was then able to boot this "custom" kext collection without any issues. I used the kernel.development variant for my test. Upon boot I even verified that it was indeed using the development variant of the kernel: $> sysctl kern.osbuildconfig kern.osbuildconfig: development Thank you very much Kevin for this very valuable help. I have several other things to read and try out (including hopefully building a trivially modified kernel version from xnu sources and booting it), but this initial step had blocked me for several months to even think of these additional experiments. For now, I will just write up these steps and share here. Thank you again.

Hello Kevin, "uname -v" on my local system shows: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:30 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6020 so I've been using T6020 as the "platform" when building the kernel. The corresponding xnu source is this tag https://github.com/apple-oss-distributions/xnu/tree/xnu-11417.140.69 and the KDK is KDK_15.6_24G84.kdk. sw_vers shows me: sw_vers ProductName: macOS ProductVersion: 15.6 BuildVersion: 24G84 So I think that's the right KDK version for this system. I'm guessing the XCode version doesn't matter for these experiments (as long as the build succeeds), but for the record, I'm on XCode 16.4: xcodebuild -version Xcode 16.4 Build version 16F6 Apart from the other build instructions, the primary one I use to generate a "DEVELOPMENT" variant of the kernel is: export KDK=/Library/Developer/KDKs/KDK_15.6_24G84.kdk make SDKROOT=macosx KDKROOT=$KDK BUILD_WERROR=0 BUILD_JSON_COMPILATION_DATABASE=1 TARGET_CONFIGS="DEVELOPMENT ARM64 T6020" and then to generate a (bootable) kext collection for this kernel, I use (this command is similar to what's noted in the linked article): kmutil create \ --arch arm64e \ --no-authorization \ --variant-suffix development \ --new boot \ --boot-path /Users/me/xnu-11417.140.69/dist/macos-15.6-development.kc \ --kernel /Users/me/xnu-11417.140.69/dist/kernel.development.T6020 \ --repository $KDK/System/Library/Extensions \ --repository /System/Library/Extensions \ --repository /System/Library/DriverExtensions \ --explicit-only $(kmutil inspect -V release --no-header | grep -v "SEPHiber" | awk '{print " -b "$1; }') This generates the kext collection at /Users/me/xnu-11417.140.69/dist/macos-15.6-development.kc.development and the following command against that kext collection file seems to suggest all looks OK: file /Users/me/xnu-11417.140.69/dist/macos-15.6-development.kc.development /Users/me/xnu-11417.140.69/dist/macos-15.6-development.kc.development: Mach-O 64-bit arm64e All this goes fine, so does running the following command in recovery mode: kmutil configure-boot --volume "/Volumes/Macintosh HD" --custom-boot-object "/Volumes/Macintosh HD/Users/me/xnu-11417.140.69/dist/macos-15.6-development.kc.development" (along with "nvram boot-args='-v wlan.skywalk.enable=0 dk=0'") Yet, when I restart with that configured custom boot object, the Apple icon keep repeating and the system keeps restarting. I haven't done any changes to the kernel code itself, so I can rule out any custom code contributing to this. My next plan is to build the RELEASE variant of this kernel and see if that boots fine instead of the DEVELOPMENT variant. If not, I'll read up a bit to understand how to track down the boot issue. Thank you very much for the helpful hints so far.

Short update - the linked article did help me successfully build a kext collection for the kernel on my local M2 system. I had to do minor adjustments to the instructions in that article to get it working. I have been trying to boot my M2 using this kext collection (after "kmutil configure-boot ..." successfully completed), but so far that step hasn't worked. Every time the system tries to boot with this custom built kext collection (in Permissive mode), the Apple icon shows up for a few seconds and then system shutdown and then again the Apple icon shows up and this keeps continuing. I switched back to "Restrictive mode" to allow me to boot the regular kernel, but I'll experiment some more and see how I can debug/investigate what's preventing a successful boot - it's going to be challenging because I can't seem to locate any logs for this part of the boot process.

However, I'm told by an engineer on the kernel team that the arm install instructions here "work": https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html Thank you Kevin, I'll give that a try in the coming days. As for x64 vs arm, I am interested in arm since that's what I have access to.

Thank you Quinn. I've now filed FB20302424 with the relevant details.

Hello Jed, I gave xctrace a try on my macos M1 system. But every time I use "xctrace record ...", it generates a kernel panic and reboots the system. I have filed a feedback issue FB20000672 with the details.

The instruments command-line tool was deprecated a few years ago and replaced with xctrace. Thank you Jed, I'll read up on xctrace and give it a try.

I configure Java with: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 Based on what you note, the issue you are running into doesn't look related to the recent Local Network Privacy changes that are enforced in macos. Instead it just looks like an issue related to which interface the socket (listening on 5005) is bound to. Starting Java 9, the instruction "address=5005" tells the JDK to bind to localhost if no specific host (like in this case) is specified in the value for "address". That's noted in the release note here https://www.oracle.com/java/technologies/javase/9-all-relnotes.html#JDK-8041435. Based on this above output you pasted, that's what appears to be going on here - the JVM is listening on a socket bound to localhost: nc on the same host says: Mac-mini:13 alan$ nc -v localhost 5005 Connection to localhost port 5005 [tcp/avt-profile-2] succeeded! These following documents have the details about how to configure the "address" option: https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#oracle-vm-invocation-options https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#transports Specifically, the documentation states: Socket transport addresses have the format ":" where is the host name or the IP address (may be enclosed in square brackets) and is the socket port number to attach to or listen on. If is empty, the local loopback address is used. If equals "*" in contexts where a server is waiting for a client to attach, the server listens on all network interfaces.

Hello Quinn, It seems that you ran into problems with that because of SIP. Correct To run dtruss, you have to disable Disabling and Enabling System Integrity Protection. Is it feasible to do that in your test setup? If so, a dtruss log that shows setsockopt misbehaving would be super helpful. One of the challenges with this issue is that, although it happens on several instances, all those instances are part of an infrastructure to which access isn't available to everyone and changes like these aren't allowed. I'll however follow up internally on that front and see if I can disable SIP for the duration of this test and collect the logs. So far I haven't been able to reproduce this on my local macos system.

Hello @cbfiddle, I am trying to setup remote Java debugging between two machines running macOS (15.6 and 26). I am able to get the Java program to listen on a socket. What exact option do you use to launch the java application with? I use nc to test the connection. It reports Connection refused when trying to connect from the other machine. Is there any firewall involved on either of these systems? The java command contains a hard-wired Info.plist which, annoyingly, requests permission to use the microphone, but not Local Network access. As far as I know, there's no permission id that can be used to request/grant Local network access to applications. It has to be explicitly granted whenever the macos system shows up the popup.

If there's anything else that you or others would like to know to narrow this down, please do let me know, either here on in the feedback issue FB15368430 Unfortunately, the discussion in that issue stalled because none of the logs that were shared could identify what was causing this issue. We still keep running into this almost every week, so I went ahead and looked into the "xnu" source code that Apple publishes to understand what could cause this problem. Based on what I see in the code, I've updated this issue with the possible cause of this problem. I think this investigation could have been much more simpler if there was some level of logging/debuggability in these socket filters area. Given what I see in the "xnu" related to socket filters, I have now opened an enhancement requesting for some logs at the right places to understand what socket/interface filters are in use on a given system and which one of those is returning a non-zero error during filtering of BSD socket operations. The feedback id for that enhancement is FB19570486. I plan to pursue FB15368430 further but I may have reached the dead end because I don't have access to these socket filters' implementation code. So I hope someone who has access to those might be able to provide some hints/inputs on that feedback issue.

An update on this one - Apple replied to the FB18173706 issue that I had filed and they noted that the issue has been resolved starting Beta3 of macos 26. As part of the fix, the man page of sw_vers continues to remain the same as it was previously but the support for the environment value SYSTEM_VERSION_COMPAT is no longer present in macos 26. i.e. irrespective of what value you set to SYSTEM_VERSION_COMPAT or even if that environment variable is unset, the macos version reported by sw_vers will always be 26. So this behaviour now matches what's noted in the man page for sw_vers.

Hello Quinn, Oh, and you should definitely test on the macOS 15.6 release candidate that we’re currently seeding. It contains at least one important local network privacy fix. Would it be possible to tell a bit more of that fix in 15.6 release candidate? We had numerous issues in 15.x releases related to local network privacy (some of which I've raised in these forums previously). There weren't any solutions we could come up with for these problems because the local network privacy configuration couldn't be automated (on test machines). So we had to temporarily disable several tests that were running into issues local network privacy issues. If there's some specific fix in this area, then I would like to try it out on a separate system and see if it helps us in some manner.

Hello @torarnv, you are right - with XCode 15.4, I just tried: NSOperatingSystemVersion osVer = [[NSProcessInfo processInfo] operatingSystemVersion]; on a macos 26 Beta 4 system and it returned: majorVersion=26 minorVersion=0 patchVersion=0 This wasn't the case in a previous Beta version of macos 26. So it looks like this got addressed in a recent Beta release. I hope this is an intentional change/fix from Apple (and not accidental) so that we can rely on this change in the upcoming 26 release.