FYI, things work better if you just reply to the thread instead of using "comments". Honestly, the comment feature doesn’t really work.
First, let me start with the error messages you posted:
Thank you. Yesterday, I accidentally removed arm64e from the compilation architecture and kept only x86_64 and arm64 architectures. The problem of Domain=NSPOSIXErrorDomain Code=8 "Exec format error" was solved.
One thing you need to be careful about when looking at our log messages is focusing too much on the EXACT error code/detail instead of the overall flow. Looking at this message as an example:
KernelManagerd: Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error"
This format structure:
"Error Domain"=<string> "Code"= <number> <string>
...is a common structure used by NSError to describe error codes from lower level subsystems. In this case, it's saying this was a POSIX error code, meaning error code "8" from the ERRNO range, or "ENOEXEC". The string "Exec format error" is actually the generic POSIX error string description returned by perror(). All of that means that the specific error code isn't necessarily all that "literal" or useful.
What would have been useful was what was earlier in the same log message, which would have been the actual description of the issue by kernelmanagerd. I'm not sure of exactly when that particular one would have been logged, but I suspect that there was an earlier message saying "Job submitted but not running", which was probably where the error originated.
The other issue here is that message ordering is really important, as lower level daemons tend to be what actually generate the issues that higher level daemons end up reporting. Last, but not least, the complexity of our logging means that it's really easy to misunderstand or misinterpret what you're actually seeing. For example, I've had many cases where the logging that "seemed" significant/relevant was really just noise and the actual issue was being logged in a totally different place.
In any case, I can only really look at an issue like this with the "full" dataset in front of me, ideally in the form of a sysdiagnose uploaded to a bug.
The strange thing is that when disabling SIP, the M1 architecture seems to require the DEXT to be ARM64e architecture, and when enabling SIP, the ARM64e architecture is not allowed. Is this true?
No. To be honest, until today I hadn't actually looked at exactly what architecture we're building, but the standard Xcode configuration produces "x86_64" and "arm64". More to the point, while it's SLIGHTLY possible that SIP could "widen" what the system accepts, there's no situation where it will "narrow" the configuration. I don't know what's actually going on, but from past experience, it's very easy to misunderstand why one configuration works and another doesn't. If you want me to dig into this more deeply, please file a bug and upload the following:
-
All the DEXTs you've created, noting which one works in which environment.
-
A sysdiagnose showing the load failure when SIP is disabled and noting what time you tested.
...then post the bug number back here once everything is uploaded. Note that when collecting a sysdiagnose, make sure you do not restart your machine before collection, as restarting causes significant log data loss.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
