Hallo zusammen,

gestern hatte ich eine KEXT von Hand manipuliert, um die Control Unit der Carrera Bahn meines Söhnchens ansprechen zu können. Kext-Dev-Mode=1 in den Boot Args war gesetzt. Nach dem Reboot blieb der Mac nach ca. 30 Sekunden mit einem Haltevebotszeichen auf grauem Grund stehen. Ein verbose Boot zeigte, dass OS X direkt nach dem Start des Kernels stehen blieb und behauptete, das Boot Device sei nicht mehr zu finden.

Habe dieses Verhalten zunächst auf mein Gefummel an der KEXT geschoben und ein OS X 10.10.1 drüber gebügelt. Update auf 10.10.2 gemacht und den aktuellen Secure Patch eingespielt. Alles paletti, Machine läuft wieder rund.

Vor einer Stunde fällt mir auf, dass ich den Trim Enabler noch nicht aktiviert habe. Nach der Aktivierung mit anschließendem Reboot bleibt die Maschine wieder mit diesem doofen "Halteverbotsschild" hängen und ich spiele wieder 10.10.1 ein. Diesmal habe ich nicht an den KEXTen gefummelt, sondern es war Trim Enabler.

Meine Fragen: Hat Apple den Schalter Kext-Dev-Mode=1 mit dem letzten Security Patch entfernt? Gibt es einen neuen Schalter, um die Überprüfung zu umgehen? Ich möchte nicht über den Sinn oder Unsinn von trim bei SSDs diskutieren, aber ich würde weiterhin gerne mal eine KEXT patchen.

Kext-Dev-Mode=1,
sicher das du das in Grosschreibung am Wortanfang machen musst?

versuch mal das in Kleinschreibung.

Steffel

Wahrscheinlich ein Rechteproblem.

Schau einmal auf cindori.org. Oscar Groth hilft.

Ich bin noch mal in mich gegangen und offensichtlich habe ich den Fehler selbst herbeigeführt. Nachdem ich den Rechner mit der manipulierten KEXT neu gestartet hatte, startete OS X zunächst im Sicherheitsmodus. Der Grund hierfür war wohl meine KEXT. "Zur Sicherheit" habe ich dann erstmal das NVRAM zurückgesetzt und damit die KEXT-Prüfung selbst wieder aktiviert

Nach dem Drüberbügeln mit 10.10.1 und nach allen Updates war das System zwar frisch, aber "kext-dev-mode" war natürlich noch nicht gesetzt und da meine Version von Trim Enabler nicht die aktuelle Version ist, hat Trim Enabler kext-dev-mode auch nicht gesetzt.

Werde das Prozedere heute nochmal in Ruhe durchgehen und dann wird sehr wahrscheinlich alles funktionieren.

Danke fürs Lesen und viele Grüße!

Hier die Empfehlung vom Entwickler wie man am einfachsten vorgeht:

Danke, danke, aber es war tatsächlich mein eigenes Verschulden. Ich war zu fokussiert auf die Anbindung der Carrera Control Unit über den FTDI-Treiber und hatte den Trim Enabler einfach nicht mehr auf dem Schirm. Meine Versuche zur Fehlerbehebung liefen demnach in die falsche Richtung, nachdem ich das NVRAM resetet hatte.

Was bleibt ist ein gewisses Ungemach darüber, dass man bei Apple per default immer an die Leine genommen wird. Der Schalter "kext-dev-mode" ist sicher eingängig und Profis werden keine Probleme damit haben. Im Beruf bin aber kein Entwickler und diesen Schalter in die Sicherheitseinstellung des Kontrollfeldes zu integrieren, würde Hobby-Proggern sicher das Leben etwas vereinfachen. Die im Bootverlauf gezeigte kommentarlose Fehlermeldung "Halteverbotschild" ist zwar stylisch, aber einfach nur nutzlos. Das beim Booten des Kernel im verbose-mode ebenso keine ordentliche Fehlermeldung erscheint, kreide ich Apple in diesem Fall echt an. Einen Log-Eintrag "unsigned kernel extension xyz found - system halted" hätte ich z.B. sofort verstanden, aber dem Benutzer vorzugaukeln, dass das Boot-Device nicht mehr gefunden wird, obwohl der Kernel gerade noch von diesem Device gestartet wurde, ist eine erstklassige Nebelkerze - auf die auch ich reingefallen bin.

Lessons Learned: Apple hat zwar IMO aktuell das beste, schönste und eleganteste Unix am Start, liefert aber auch selbst entwickelte Hürden frei Haus, die man bei anderen IX-Systemen weder kennt, noch in dieser Form erwarten würde ("Don't steal OS X.kext" wäre ein weiteres unsägliches Beispiel dazu).

Falls jemand also Interesse daran besitzt, eine Carrera Control Unit mit einem Rechner zu verbinden, hat er folgende Möglichkeiten:
1. Windows - Die freien FTDI-Treiber installieren und sofort loslegen.
2. Linux - Die freien FTDI-Treiber installieren und sofort loslegen.
3. OS X - Den Kernel über die boot-args manipulieren, die freien FTDI-Treiber patchen, damit der Kernel diese akzeptiert und für den verwendeten FTDI-Chipsatz auch verwendet und dann - endlich loslegen.

Das eigentlich frustende sind halt die Stunden, die ich nun mit diesen Einstiegshürden bei OS X verbracht habe, anstatt einfach meinen Raspberry Pi anzuwerfen und loszulegen.

gn8

Aehm... das Halteverbotsschild ist aber ein selbst verursachtes Problem deinerseits duch die Installation eines nicht aktuellen Trim-Enablers bzw. überhaupt dessen Nutzung.

Durch die Nutzung des Trim-Enablers kannst Du das Bootvolumen nicht mehr korrekt nutzen, sofern Du mit "kext..." nicht das vorabladen unsignierter Kexts erlaubst.
Nur dann erscheint das Verbotsschild.

Sonstige veränderte Kexte werden einfach nicht geladen. Das System bleibt aber nach wie vor bootbar und kann genutzt werden. Nur ohne die gepatchten und veränderten Kexte.

4.Option, einne korrekt entwickelten und per Developer-Certificate signierte Kext in OSX zu verwenden, um sich das ganze gebastel zu ersparen - gibt die nicht? Den Entwickler in d.. A... treten und auffordern, seine Software für OSX anzupassen.

Ich bin wahrlich ein Apple Fan, aber freie Entwickler in den A... treten zu sollen, damit sie Apple in den A... kriechen, damit Apple ihre freien Treiber zertifiziert halte ich für nicht angemessen. Anders herum wird ein Schuh draus. Apple könnte dem User die Freiheit geben, "besondere Sicherheit" zu gewährleisten, indem man die KEXT-Prüfung willentlich aktivieren muss. Änderungen an den System Files erfordern doch sowieso Admin-Rechte, wieso legt Apple hier noch weiter einen drauf und fordert praktisch einen "God Mode" für KEXTe?

Seit den 80ern bin ich in der IT-Welt unterwegs und die Salami-Taktik, mit der der User von der Technik von iOS/OS X auf Distanz gehalten werden soll, ist doch bei Apple offensichtlich.

Wenn ich über eine serielle Schnittstelle Kontakt u.a. mit einer Carrera Bahn aufnehmen möchte und dazu einen von Apple zertifizierten Treiber benötige, dann besitzt das Apple System in meinen Augen einen gravierenden Nachteil für den User! Ich habe kein Problem damit, meine Basteleien zukünftig ausschließlich mit Linux durchzuführen.

Das der Trim Enabler sowieso nur deshalb notwendig ist, weil Apple lieber die eigenen, teureren SSD an die Benutzer verkaufen möchte, will ich hier nicht weiter diskutieren. Befremdlich finde ich halt nur Äußerungen, die dieses Vorgehen auch noch lautstark unterstützen.

Abschließend möchte ich nochmals betonen, dass der Fehler bei _mir_ lag, denn ich habe im Vorfeld nicht tiefgründig genug darüber nachgedacht, dass meine Manipulationen an Treiberdateien zur seriellen Übertragung von Daten dazu führen, das System unbenutzbar zu machen, OBWOHL meine Manipulationen in keiner Weise die Funktionsfähigkeit des Systems beeinträchtigen. Apple sieht Änderungen an der info.plist Datei eines Treibers halt nicht vor und bestraft solches Vergehen mit Arbeitsverweigung des gesamten OS.