The "not authentic" error message has to do with bad on-disk
permissions, say, of a parent directory involved. That's a problem on
the user's system.
The other seemingly mysterious error ("Executable file doesn't contain
kernel extension code") is the Leopard kextload (specifically, the
IOKit.framework that kextload links against) barfing on the x86_64
Mach-O binary that's part of the fusefs.kext Universal binary. Rather
than ignoring the architecture it doesn't know about, kextload is
complaining--that too, with a misleading error (if at all, it should
be complaining that it found kernel extension code for more
architectures than it expected, rather than saying that it didn't find
any kernel extension code at all.) That's a buggy error message.
Anyway, as you found, this shouldn't stop the kext from loading and
working properly.
Amit
On Jan 6, 12:58 pm, Jon Shea <[email protected]> wrote:
> I’ve noticed that calls to ‘sudo kextload -vt /Library/Filesystems/
> fusefs.fs/Support/fusefs.kext’ (‘-t’ is the validate and authenticate
> flag) on 10.5.6 fail with the message:
>
> kextload: kext /Library/Filesystems/fusefs.fs/Support/fusefs.kext is
> not valid
> can't add kernel extension /Library/Filesystems/fusefs.fs/Support/
> fusefs.kext (validation error) (run kextload on this kext with -t for
> diagnostic output)
> kextload: resolving dependencies for kernel extensions with validation
> and authentication failures
> kernel extension /Library/Filesystems/fusefs.fs/Support/fusefs.kext
> has problems:
> Validation failures:
> {
> "Executable file doesn't contain kernel extension code" = true
>
> }
>
> I can’t find any further documentation of the what might cause the
> validation failure. Despite the failure, fusefs seems to load and
> function properly, so this may be a known behavior or limitation. This
> validation failure happens with both MacFUSE 2.03 and 2.1.5 (Beta).
> MacFUSE 1.7.1 validates correctly, and MacFUSE 2.1.5 validates
> correctly on Tiger. All tests were on intel machines. I’m reporting it
> because I can’t find any further information about it. The same
> behavior results from running ‘kextload -vnt /Library/Filesystems/
> fusefs.fs/Support/fusefs.kext’ (which not attempt to actually load the
> kernel).
>
> I’d like to share some tangentially related background in case anyone
> is having a similar experience. We recently had a user whose
> installation of MacFUSE wouldn’t load (load_fusefs failed), even after
> running uninstall-macfuse-core.sh and reinstalling MacFUSE. In this
> case, the following error was printed to the user’s Console Messages,
> I’m pretty sure by load_fusefs (nothing else I know about would have
> called kextload):
>
> kextload: extension /Library/Filesystems/fusefs.fs/Support/fusefs.kext
> is not authentic (check ownership and permissions; run with -t for
> details)
>
> This is, of course, the message which prompted me to run ‘kextload -
> t’. We had one other user who was unable to load the MacFUSE kext even
> with a fresh installation, and were able trace it to a permissions
> problem (for reasons unknown, the user’s load_fusefs was not chmod
> +s). If I’m able to figure out anything else about these very rare
> issues, then I’ll post an update here.
>
> -Jon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MacFUSE" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/macfuse?hl=en
-~----------~----~----~----~------~----~------~--~---
