Post not yet marked as solved
We use kextsymboltool when compiling our kext, but kexts will not load on Big Sur, generally it simply claims it can not find the Plugins/module.kext, or if I try to codesign Plugins/module.kext I get;
... because file does not have a __LINKEDIT segment
I'm guessing there has been some slight changes to make kextsymbtoltool.c up to date, anything I can handle now, or must I wait for XNU source?
Post not yet marked as solved
Not sure it is a kernel issue, or a "log stream" issue, but when you start a day of developing, you get:Requesting load of /tmp/zfs.kext./tmp/zfs.kext loaded successfully (or already loaded).# log stream --source --predicate 'sender == "zfs"' --style compactkernel.development[0:1b115] (zfs) ZFS: Loaded module v0.8.0-852_g6c5f6be15, ZFS pool version 5000, ZFS filesystem version 5and as you hack away, kextunload'ing and kextloading the module, it gets offset (presumably due to location change of symbols?)# kextunload -b net.lundman.zfscompile, compile,Requesting load of /tmp/zfs.kext./tmp/zfs.kext loaded successfully (or already loaded).# log stream --source --predicate 'sender == "zfs"' --style compactkernel.development[0:20c88] (zfs) ool version 5000, ZFS filesystem version 5With enough time, you get just garbage. Rebooting fixes it.Been the case since we got "log" command (Mavericks?)
Post not yet marked as solved
I believe that we aren't "allowed" (supposed to?) call mount from within the kernel, at least, I have notyet found a way to do so that isn't dreadful.It is how "upstream" does it and I'm trying to maintain familiarity to users.But in "recent" kernels, there is SNAPSHOT_OP_MOUNT - and I am trying to mount a snapshot -just one of mine, not Apple's.Is this interface also Apple private? Or could I use it to mount my snapshots?If it was public, I could then presumably also create/revert snapshots in my filesystemissued by macOS utilities if I defined those vnops?
OK I somehow managed to break lldb loading KDKs, and my best guess is it picks the wrong python framework.lldb /Library/Developer/KDKs/KDK_10.14_18A336e.kdk/System/Library/Kernels/kernel
(lldb) target create "/Library/Developer/KDKs/KDK_10.14_18A336e.kdk/System/Library/Kernels/kernel"
unable to load scripting data for module kernel - error reported was Missing parentheses in call to 'print'. Did you mean print("Loading kernel debugging from %s" % __file__)? (kernel.py, line 69)
File "temp.py", line 1, in# which lldb/usr/bin/lldb# which python/usr/bin/pythonClearing PATH and PYTHONPATH, or setting thing appears to make no changes.Any clues?
Post not yet marked as solved
Part of the install of our kext is a simple launchctl script to automatically mount the volumes. <key>ProgramArguments</key> <array> <string>/usr/local/libexec/zfs/launchd.d/zpool-import-all.sh</string> </array> <key>RunAtLoad</key>In essence, the script is:#!/bin/bash/usr/local/sbin/zpool import -aIf users add "bash" to allow Full Disk access, the script runs on boot. So that's "a" solution.But allowing "bash" Full Disk access is an excessively large hammer I feel. However, allowing "Full Disk" access to "zpool" will not work, it is apparently not enough. In the interest of doing things the way Apple intended (or rather, not going against Apple) what wouldbe the "right" way to approach this. Clearly there is some inheritance in play, but it isn't clear to mehow that works. Why wouldn't allowing "zpool" to work? How to debug this?
lundman.