Possibly it can be done, but I went to beta3 instead, which has a matching KDK.

This is still an issue, including on the sonoma release. Snapshot API calls are there, but the ability to load kexts is still missing.

Word is that there now is a work-around, if somewhat complicated. I suspect with a bit more time, it will be streamlined down to something nicer.

Same here, 10.14 and 10.15 both need to be notarized. With 10.15 I can copy the notarytool from Monterey's xcode (13.1), and it runs fine. With 10.14 it does not run due to: dyld: Library not loaded: /System/Library/Frameworks/CryptoKit.framework/Versions/A/CryptoKit If I copy over a local copy of CryptoKit, I can not set DYLD_LIBRARY_PATH anymore, sad-face. Possibly I could strip it of the codesign certificate and add "com.apple.security.cs.allow-dyld-environment-variables" but that feels like I'm close to yak shaving. 10.13 does not need notarizing, so it is odd Apple left one OS out in the cold. Has anyone come up with a solution that doesn't require me to copy it to a 2nd VM running newer macOS?

Cooked together a "notarytool" replacement that will do the work for me, and the build environment can remain the same. Instead of calling "xcrun notarytool" I run this: https://gist.github.com/lundman/9166dc8bef1973e5d9fc5428e0cedc57 Nothing special, but might save someone a few minutes having to do it themselves.

OK, so wait, now is not the time. Thanks Quinn.

I am unsure if there has been any progress in this area. But I needed to resolve a recent Tahoe panic, so chatgpt cobbled together this: https://gist.github.com/lundman/54e633a850e7623aae5adab38a39f464 If we are allowed to share? Either way, output was: ./symbolicate_panic.py -p ~/ZFS.2.3.1rc1.kernel.panic.-.Tahoe.M4.Pro.Mac.Mini.txt -k /Library/Extensions/zfs.kext/Contents/MacOS/zfs --kernel --kdk-nearest --accept-mismatch === KEXT mapping === bundle: org.openzfsonosx.zfs arch: arm64e base@: 0xfffffe004400d840 file __TEXT vmaddr: 0x0 file __TEXT_EXEC vmaddr: 0x70000 delta=0x70000 chosen TEXT_LOAD: 0xfffffe0043f9d840 === Kernel mapping (via KDK) === checking for KDK build 25A354 ... nearest: /Library/Developer/KDKs/KDK_26.0_25A353.kdk build: 25A354 SoC: t6041 kernel: /Library/Developer/KDKs/KDK_26.0_25A353.kdk/System/Library/Kernels/kernel.release.t6041 panic Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 KDK Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 file __TEXT vmaddr: 0xfffffe0007004000 file __TEXT_EXEC vmaddr: 0xfffffe00072cc000 delta=0x2c8000 panic Kernel text exec base: 0xfffffe003e2c4000 chosen TEXT_LOAD: 0xfffffe003dffc000 ESR: 0x96000005 -> Data Abort, same EL; Translation fault, level 1 FAR: 0x0000000000000084 === Panicked thread (merged, ordered) === 0xfffffe004401d934 [zfs] taskq_dispatch (in zfs) (spl-taskq.c:1457) 0xfffffe003e3164c0 [kernel] handle_debugger_trap (in kernel.release.t6041) (debug.c:1863) 0xfffffe003e48bc54 [kernel] handle_uncategorized (in kernel.release.t6041) (sleh.c:1818) 0xfffffe003e489e8c [kernel] sleh_synchronous (in kernel.release.t6041) (sleh.c:0) 0xfffffe003e2c7d48 [kernel] fleh_synchronous (in kernel.release.t6041) + 72 0xfffffe003e3167d0 [kernel] DebuggerTrapWithState (in kernel.release.t6041) (debug.c:830) 0xfffffe003ec199c8 [kernel] Assert (in kernel.release.t6041) (debug.c:841) 0xfffffe003ec24c74 [kernel] sleh_synchronous_sp1 (in kernel.release.t6041) (sleh.c:1191) 0xfffffe003e48bac4 [kernel] handle_kernel_abort (in kernel.release.t6041) (sleh.c:3960) 0xfffffe003e489ed0 [kernel] sleh_synchronous (in kernel.release.t6041) (sleh.c:1544) 0xfffffe0044155ab4 [zfs] vdev_disk_io_start (in zfs) (vdev_disk.c:750) 0xfffffe0044140c54 [zfs] zio_vdev_io_start (in zfs) (zio.c:0) 0xfffffe004413bdd8 [zfs] zio_nowait (in zfs) (zio.c:2580) 0xfffffe00440dbb98 [zfs] vdev_probe (in zfs) (vdev.c:1840) 0xfffffe00440dc92c [zfs] vdev_open (in zfs) (vdev.c:2273) 0xfffffe00440e4d90 [zfs] vdev_open_child (in zfs) (vdev.c:1868) 0xfffffe004401ffe4 [zfs] taskq_thread (in zfs) (spl-taskq.c:2144) 0xfffffe0044020574 [zfs] spl_thread_setup (in zfs) (spl-thread.c:128) 0xfffffe003e2c87cc [kernel] Call_continuation (in kernel.release.t6041) + 204 Maybe it will help someone, or, if there is an official way now, please let me know.