Hallo an alle,

ich habe leider ein Problem in einem Bereich, wo ich mich so gut wie gar nicht auskenne: 1 (von insgesamt 2) seit vielen Jahren installierten und funktionierenden Kernel Extensions geht plötzlich nicht mehr, wobei plötzlich insofern relativ ist, als ich sie zuvor das letzte Mal vor einem Jahr benutzt habe.

Die Kernel Extension ist daspi 1.5 (ein Treiber für Blu-ray-Laufwerke); das Programm, das sie benötigt, ist MakeMKV, mit dem ich alle Jubeljahre mal eine Blu-ray auslese. MakeMKV hatte ich eben auf die neuste Version (1.17.7) aktualisiert; macOS ist bei mir noch immer 10.14.6 Mojave.

MakeMKV findet daspi auf einmal nicht mehr und greift daher über den OS access mode (d.h. den macOS-eigenen Treiber) auf das Laufwerk zu; angeblich geht das in 99,9% der Fälle genauso, aber bei mir ging das noch nie; ich bekomme dann nur endlose SCSI-Errors.

daspi scheint auch in der Tat nicht geladen; der KextViewr von Patrick Wardle, der alle geladenen Kernel Extensions auflistet, zeigt (von Apples Kernel Extensions abgesehen) nur noch den SATSMARTDriver an, meine zweite seit Jahren genutzte Kernel Extension (zur Anzeige des SMART-Status in externen Laufwerken).

Und hier geht es mit meinem Unverständnis los: In den letzten 12 Monaten (seit daspi das letzte Mal ging) blieb daspi unverändert und meiner Erinnerung nach gab es von Apple für Mojave keinerlei Updates mehr; es müsste also eigentlich alles noch exakt so sein wie vor einem Jahr, wo der KextViewr noch beide Extensions angezeigt hatte.

Systeminformationen → Software → Erweiterungen sagt zu daspi:

daspi:

Version:                                                    1.5
Zuletzt geändert:                                      27.02.22, 20:25
Paket-ID:                                                  com.makemkv.kext.daspi
Notariell beglaubigt:                                 Unbekannt
Geladen:                                                  Nein
Erhalten von:                                           Nicht signiert
Art:                                                           Intel
Architekturen:                                           i386, x86_64
64-Bit (Intel):                                             Ja
Ort:                                                           /Library/Extensions/daspi.kext
Kext-Version:                                            1.5
Ladbar:                                                      Nein
Fehler bei der Unterschriftenvalidierung:  Nicht signiert
Abhängigkeiten:                                        Erfüllt
Signiert von:                                              Nicht signiert

Als blutiger Laie argwöhnte ich zunächst, das Problem sei, dass die Kernel Extension als Ladbar: Nein angezeigt wird. Das ist wohl aber anders zu verstehen, denn das ist bei dem SATSMARTDriver genauso, und der wird im KextViewr ja erkannt. Auch ist der SATSMARTDriver genauso wenig signiert und notariell beglaubigt, aber bei ihm ist das alles kein Problem: Bei ihm steht Geladen: Ja.

Da daspi gar nicht signiert ist, kann jedenfalls auch kein Zertifikat abgelaufen sein.

Ein Versuch, daspi im Terminal selbst zu laden, endet so:
Und die Kernel Logs sagen dazu:

Da stehe ich angesichts der Tatsache, dass im letzten Jahr nichts verändert wurde, jetzt ratlos davor.

Die Kernel Logs melden unabhängig davon in kurzen Abständen kontinuierlich:
Keine Ahnung, was das heißt und ob es schlimm ist, aber mit dem daspi-Problem hat das wohl eher nichts zu tun.


Versteht hier jemand mehr von diesem ganzen Zeugs als ich und weiß Rat?

Liefert dir dies noch zusätzliche Informationen?
Bei einem Problem half mir mal den Kext-Cache zu löschen. Hintergründe müsste ich auch nachlesen.

Diese Apple-Discussions zum Kext-Cache habe ich gefunden, bei der es um ein Problem mit Mojave ging. Das Ganze ist von mir natürlich nur ein Schuss ins Blaue.

Zwei Vorbemerkungen:
1. Ich habe daspi.kext (wieder) nach /System/Library/Extensions verschoben; da sollte es zwar nicht sein, war es aber, als es noch funktionierte. Sollte nichts ändern, nur zur Sicherheit …
2. Falls jemanden die Meldung unten wundert: SIP ist bei mir prinzipiell ausgeschaltet.
Leider ändert das nichts. Trotzdem danke!
Nur so halb:
root# kextcache --clear-staging
root# kextutil -v /System/Library/Extensions/daspi.kext
Defaulting to kernel file '/System/Library/Kernels/kernel'
Can't create kext: invalid CFBundleVersion in identifier cache entry entry 320.
Can't create kext: invalid CFBundleVersion in identifier cache entry entry 320.
Can't create kext: invalid CFBundleVersion in identifier cache entry entry 320.
Kext with invalid signatured (-67062) allowed: <OSKext 0x7fbd4364c7c0 [0x7fff964ec920]> { URL = "file:///System/Library/Extensions/daspi.kext/", ID = "com.makemkv.kext.daspi" }
Code Signing Failure: not code signed
/System/Library/Extensions/daspi.kext appears to be loadable (not including linkage for on-disk libraries).
Can't create kext: invalid CFBundleVersion in identifier cache entry entry 320.
Loading /System/Library/Extensions/daspi.kext.
Disabling KextAudit: SIP is off
KextAudit initialized: audit=F
(kernel) kxld[com.makemkv.kext.daspi]: The following symbols are unresolved for this kext:
(kernel) kxld[com.makemkv.kext.daspi]: __ZN12IOUserClient8DispatchE5IORPC
(kernel) kxld[com.makemkv.kext.daspi]: __ZN15OSMetaClassBase8DispatchE5IORPC
(kernel) kxld[com.makemkv.kext.daspi]: __ZN9IOService8DispatchE5IORPC
(kernel) Can't load kext com.makemkv.kext.daspi - link failed.
(kernel) Failed to load executable for kext com.makemkv.kext.daspi.
(kernel) Kext com.makemkv.kext.daspi failed to load (0xdc008016).
(kernel) Failed to load kext com.makemkv.kext.daspi (error 0xdc008016).
Failed to load /System/Library/Extensions/daspi.kext - (libkern/kext) link error.
Failed to load /System/Library/Extensions/daspi.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).

Kommentar:
Die fehlenden Symbole werden offenbar in der Kernel-Datei gesucht (das war mir bislang unklar und ist es immer noch).
Das klingt irgendwie in der Tat nach Cache-Problem, aber kextcache --clear-staging hat ja jedenfalls nicht geholfen.
Abgesehen vom Link-Problem wäre die Extension ladbar.
Das sind wieder dieselben Fehlermeldungen, wie sie schon in den Kernel Logs zu finden waren. 3 Symbole, die nicht zugeordnet werden können.

Ich habe dann den Ratschlag in der letzten Zeile befolgt:
root# kextlibs /System/Library/Extensions/daspi.kext
Can't create kext: invalid CFBundleVersion in identifier cache entry entry 320.
For i386:
No libraries found.
375 symbols not found in any library kext.

For x86_64:
com.apple.iokit.IOCDStorageFamily = 1.8
com.apple.iokit.IOSCSIArchitectureModelFamily = 408.250.3
com.apple.kpi.iokit = 18.7
com.apple.kpi.libkern = 18.7
com.apple.kpi.mach = 18.7

3 symbols not found in any library kext.

Wieder dasselbe: 3 Symbole, die nicht mehr zugeordnet werden können. Aber wie kann das sein, wenn an macOS in der ganzen Zeit nichts geändert wurde?

Vielleicht eine blöde Frage, aber hast Du nach sudo kextcache --clear-staging auch einen Neustart gemacht?
Erst nach einem Neustart kopiert macOS automatisch alle noch verfügbaren und durch Dich zuvor einmal erlaubten Extensions wieder in den StagedExtensions-Ordner.

Du hast den falschen Befehl verwendet. Die richtige Vorgehensweise wäre
und danach ein Neustart des Computers.

Die "StagedExtensions" sind für etwas ganz anderes, nämlich als eine Art Quarantäne-Bereich für Treiber, die der Administrator noch zu genehmigen hat oder die abgelehnt wurden.

Ich war mir nicht sicher, ob Du touch jetzt zusätzlich zu kextcache --clear-staging meintest oder stattdessen, also habe ich beides gemacht – erst kextcache, dann touch und danach Neustart. Das ändert leider überhaupt nichts.

Du hast den kext über die Bundle Id geladen. Da steht, dass ein Link nicht gefunden wurde. Geht es so?
Laut dieser Quelle soll es meist ohne diesen kext funktionieren . Hilft deinstallieren?
Da steht noch was von disable "approved by Apple"

Problem gelöst!
Nein, das war es nicht.

Das Problem war/ist, dass daspi.kext in verschiedenen Versionen existiert, die alle dieselbe Versionsnummer tragen. 🙄

Die Versionen haben offenbar auch alle den exakt selben Quelltext, aber sie sind mit verschiedenen Xcode-Versionen kompiliert. Und für Mojave darf keine Xcode-Version > 10 benutzt worden sein, denn dann verlinkt Xcode denselben Quellcode in eine IOKit-API, die es unter Mojave noch gar nicht gibt – das sind diese 3 fehlenden Symbole.

Ich hatte offenbar nach meiner letzten erfolgreichen Nutzung schonmal „vorsorglich“ eine neuere Version installiert, mich daran jetzt aber gar nicht mehr erinnert. Die Version, die auf Mojave funktioniert, muss 2012 kompiliert worden sein.

Ich habe die alte Version aus Time Machine geholt, dann im Terminal eingegeben:
und daspi ist wieder da.

Wie ich darauf kam? Ich hätte gleich nach einem der fehlenden Symbole googeln sollen, hielt das aber aufgrund früherer Erfahrungen für zu speziell, um ein sinnvolles Ergebnis zu bekommen.

Jetzt habe ich es doch gemacht und gleich das erste Symbol (__ZN12IOUserClient8DispatchE5IORPC) war ein Volltreffer, insofern es mir zeigte, dass es eine vollkommen andere Kernel Extension gibt, der exakt auf Mojave exakt dieselben drei Symbole fehlen . Das ist also ein systematischer Fehler. Auf der verlinkten Seite gab es eine lange Diskussion dazu und irgendwo stand dann der goldene Satz:Damit war alles klar.
Bei meinem Laufwerk hat das ohne nie funktioniert. Ich habe es dennoch versucht und so, wie es im Moment aussieht, mir dadurch mein Blu-ray-Laufwerk geschrottet. Insofern bin ich nicht wirklich weiter … 😢