Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
fassl

HowTo: EFI

41 posts in this topic

Recommended Posts

EDIT: Es gibt jetzt eine alternative zu PC_EFI und nennt sich Chameleon, gibts in #chameleon im osx86 irc oder chameleon.osx86.hu

 

Vorteile:

  • Software RAID Support
  • Eine boot0 und boot1h für MBR als auch für GUID
  • Neuer Bootloader kann installiert werden indem man ihn einfach nach root kopiert -> /boot
  • Braucht kein startupfiletool mehr, d.h. man kann es im laufenden Betrieb installieren.

 

EFI (Extensible Firmware Interface)

ist sozusagen der Nachfoler des BIOS und wird von Apple benutzt.

Wer mehr dazu erfahren will: http://de.wikipedia.org/wiki/Extensible_Firmware_Interface

 

Für uns ist aber in erster Linie PC_EFI interessant.

 

Was ist PC_EFI eigentlich?

  • es ist ein modifizierter Darwin Bootloader der ein paar Informationen in den RAM schreibt, das macht normalerweise EFI, aber da wir kein EFI sondern BIOS haben, müssen wir auf dieses fake EFI zurückgreifen
  • es erlaubt uns Vanilla Kernel (ungepatcht/original Apple) zu benutzen (dsmos.kext muss "installiert" sein)
  • unsere Hackmacs werden oder sollten bei Geekbench und System Profiler nicht mehr als Hackintoshe angezeigt werden
  • die neueste Version V8 unterstützt schon GUID und GFX-STRINGS
  • GUID ist die Apple Partitionstabelle
    • Vorteil: ist die Platte mit GUID formatiert kann man problemlos Partition vergrößern/erstellen etc.
    • Nachteil: Dual/Triple Booting kann ein schweres Unterfangen werden

    [*]GFX-STRING

    • macht eigentlich nichts anderes als die Injektoren, wie zB alcINJECT, nvINJECT, atiINJECT... wie man am Namen erkennen kann, ijezieren diese Kexte etwas. Sie sind keine Treiber, sie senden nur wertvolle Informationen an den Kernel, damit dieser weiß welchen Treiber er laden soll.
    • GFX-Strings machen eigentlich genau dasselbe wie diese Injektoren
    • hat man sich seine Strings gebastelt kann man auf die Injektoren verzichten (natürlich nur auf diese, für die man sich einen String gebastelt hat :) )
    • man kann mit GFX-Strings auch Time Machine und den UUID 35 Error fixen
    • man kann sich diesen String von echten Macs holen. Wenn deine Grafikkarte zB nicht vollständig läuft mit Natit Nvinject etc. kann man sich von einem Mac der dieselbe Grafikkarte hat, diesen String holen. Mit ziemlich großer Sicherheit wird es dann voll kompatibel sein.

PC_EFI Bootloader Installieren

  1. Holt euch das PC_EFI Package: PC_EFI
  2. Kopiert euch das Package ins Root Verzeichnis damit wir später leichter zugreifen können
     
    im Terminal: cp -R "hier den efi ordner reinziehen" /
    oder einfach im Finder den Ordner nach root ziehen
    nennt den Ordner am besten /pcefi
     

  3. Jetzt müssen wir herausfinden wie deine Festplatte anzusprechen ist
     
    diskutil list
    das schaut dann ca. so aus:
     
    /dev/disk0
      #:				   	TYPE NAME					SIZE   	IDENTIFIER
      0: 	FDisk_partition_scheme						*111.8 Gi   disk0
      1:				  Apple_HFS MacOSXLeopard	   	25.0 Gi	disk0s1
      2:				  Apple_HFS Kalyway			 	20.0 Gi	disk0s2
      3:				  Apple_HFS Files			   	66.8 Gi	disk0s3


     
    was wir brauchen, ist der Identifier deiner Leopard Partition, in meinem Fall disk0s1
    merken!!

  4. (Optional aber empfohlen!) Jetzt werden wir AppleEFIRuntime umbenennen, weil sie bei manchen das Booten mit PC_EFI verhindert
    EDIT: Anscheinend wurde das mit boot_v8 gefixt, und es besteht keine Notwengigkeit mehr diese kext zu löschen.
     
    mv /System/Library/Extensions/AppleEFIRuntime.kext /System/Library/Extensions/AppleEFIRuntime.kext.old
  5. Wir müssen nun im Single User Mode (booten mit -s Parameter) den neuen Bootloader schreiben
     
    cd /pcefi (oder je nachdem wie ihr den Ordner benannt habt)
    ./startupfiletool /dev/rdiskXsY ./boot_v8
    reboot
    Nun is der PC_EFI Bootloader installiert. Falls ihr eine Bootschleife bekommt versucht mal im Bios den No Executable (NX/XD) zu aktivieren. HPET sollte aktiviert sein und cpuid limit aus. Vielleicht auch noch hilfreich Netkas' Forum -> PC_EFI

PC_EFI deinstallieren

 

Falls es aber patout nicht funktioniert und ihr PC_EFI rückgängig machen wollt, macht folgendes:

p.s. Du brauchst einen UST-Stick

  1. DVD booten
  2. Terminal öffnen
  3. PC_EFI auf den Stick kopieren
     
    cp -R /Volumes/NAME_DEINE_LEO_PARTITION/pcefi /Volumes/USB_STICK/

     
  4. Leo Partition unmounten
     
    diskutil unmount /dev/diskXsY
    oder
    diskutil unmount NAME_DEINER_LEO_PARTITION
     

  5. Standard Darwin Bootloader installieren
     
    cd /Volumes/USB_STICK/PC_EFI
    ./startupfiletool /dev/rdiskXsY ./usr/standalone/i386/boot
    reboot
     
    Fertig.

EFI Strings erstellen

Für Grafikkarten

  1. Was wir brauchen:
     
    PC_EFI_V8 installiert

    gfxutil
    Property List Editor
     
    Die Tools kriegst du hier: plist_gfxutil
     
    Einen funktionierenden Injector (Natit/Nvinject/NvinjectGo/Atiinject/....)
    Einen Beispiel-String

[*]Device-Path auslesen

  • Terminal öffnen
  • cd "Ordner wo sich GFXUTIL befindet"
  • ./gfxutil -f display

Nun kriegt ihr euren Device-Path angezeigt, der schaut ca. so aus:

 

DevicePath = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)

 

[*]Plist editieren

 

Sofern in den Dateien mit dem Beispiels String, die ihr runtergeladen habt, keine Plist vorhanden ist, müssen wir diese zuerst generieren. Andernfalls muss die vorhandene Plist modifiziert werden.

  • ./gfxutil -i hex -o xml "hier die hex datei ins terminal ziehen" string.plist

Öffnet die Plist mit dem Property List Editor

 

20080202-m6gt7h28cyhj347xww75n9kxb8.jpg

 

hier hervogehoben ist der Device-Path, kopiert hier euren rein (siehe Punkt 2)

 

[*]Informationen vom Injector holen:

  • Konsole öffnen (Konsole und nicht Terminal!! :( )
  • Links system.log auswählen
  • rechts oben im Suchfeld euren Injector eingeben (zB NVinject)

    schaut dann ca. so aus:
     
    NVinject: Probing.
    NVinject: Setting NVPM=<data not shown>
    NVinject: Setting @0,device_type=display
    NVinject: Setting NVCAP=<data not shown>
    NVinject: Setting @0,compatible=NVDA,NVMac
    NVinject: Setting model=Graphics by NVIDIA
    NVinject: Setting @1,name=NVDA,Display-B
    NVinject: Setting device_type=NVDA,Parent
    NVinject: Setting name=display
    NVinject: Setting rom-revision=NVinject 0.2.1
    NVinject: Setting @0,name=NVDA,Display-A
    NVinject: Setting @1,compatible=NVDA,NVMac
    NVinject: Setting @1,device_type=display


  • tragt diese Infos nun in eure Plist ein
  • ändert nur die Werte die ihr von der Konsole bekommen habt

Beachte: Wahrscheinlich werden die Werte als Data (Hex) eingetragen sein, aber ihr könnt getrost die Class auf String ändern und als Text eingeben (NUR bei Infos wie name, model, etc. NICHT bei zahlenwerten wie zB NVCAP:

 

20080202-t9uhisnn11wdn7a5kdek63ig7u.jpg

NVCAP und NVPM erhalten wir mit (oder andere Werte die als angezeigt werden):

  • ioreg -lw 0 -p IODeviceTree | grep NVCAP
  • ioreg -lw 0 -p IODeviceTree | grep NVPM

Speichere die modifizierte Plist ab.

 

[*]Jetzt konvertieren wir diese Plist wieder in einen Hex String

  • ./gfxutil -i xml -o hex string.plist string.hex

Unser String befindet sich jetzt in string.hex (könnt ihr mit TextEdit öffnen)

 

[*]Nun müssen wir den String noch in die Boot.plist eintragen:

 

  • Backup: cp /Library/Preferences/SystemConfiguration/com.apple.Boot.plist /Library/Preferences/SystemConfiguration/com.apple.Boot.plist.old
  • Öffnet die Boot.plist mit Property List Editor
  • klickt auf Root -> New Child "device-properties" ; Class = String ; Value = Euer generierter hex-string

 

20080202-k6ckgumxr8er7sk3nweph3rams.jpg

  • speichert die plist in einem Ordner wo du Zugriff hast, zB Desktop
  • sudo cp ~/Desktop/com.apple.Boot.plist /Library/Preferences/SystemConfiguration/

Nun, wir wären fertig ;)

 

Eins noch: der Injector muss deaktiviert werden, das machen wir mit

  • sudo mv /System/Library/Extensions/"euer Injector".kext /System/Library/Extensions/"euer Injector".kext.old

Rebooten und viel Glück ;)

 

Ob der String auch übergeben wurde überprüft ihr mit

  • ioreg -lw 0 -p IODeviceTree | grep device-prop

EFI Strings erstellen

 

Für Netzwerk (Time Machine + UUID35 Error fix)

  1. Was wir brauchen:

    PC_EFI_V8 installiert
     
    gfxutil
    Property List Editor
    plist_gfxutil
  2. Device-Path auslesen

    * Terminal öffnen
    * cd "Ordner wo sich GFXUTIL befindet"
    * ./gfxutil -f ethernet
     
    Nun kriegt ihr euren Device-Path angezeigt, der schaut ca. so aus:
    DevicePath = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)


     

  3. Plist editieren

    Sofern ihr schon einen existieren String in Form von einer plist habt fügt ihr einfach euren Network device-path hinzu, ansonsten erstellt ihr einfach eine neue .plist:
     
    Öffnet die Plist mit dem Property List Editor
     
    hier hervogehoben ist der Device-Path, kopiert hier euren rein (siehe Punkt 2)
     
    20080212-83y5xpumn1hx2c8uhgm585tfnp.jpg
    Speichere die modifizierte Plist ab.
     
  4. Jetzt konvertieren wir diese Plist in einen Hex String

    * ./gfxutil -i xml -o hex "hier die erzeugte plist in das terminal ziehen" string.hex
    Unser String befindet sich jetzt in string.hex (könnt ihr mit TextEdit öffnen)
     
  5. Nun müssen wir den String noch in die Boot.plist eintragen:

    * Backup: cp /Library/Preferences/SystemConfiguration/com.apple.Boot.plist /Library/Preferences/SystemConfiguration/com.apple.Boot.plist.old
    * Öffnet die Boot.plist mit Property List Editor
    * klickt auf Root -> New Child "device-properties" ; Class = String ; Value = Euer generierter hex-string
    * speichert die plist in einem Ordner wo du Zugriff hast, zB Desktop
    * sudo cp ~/Desktop/com.apple.Boot.plist /Library/Preferences/SystemConfiguration/

Nun, wir wären fertig ;)

 

Rebooten und viel Glück ;)

 

Ob es funktioniert hat überprüft ihr am besten mit IORegistryExplorer oder sucht in der Konsole nach firewire, er sollte jetzt keinen "failed to determine security mode" fehler mehr anzeigen.

Auch wenn ihr mit diskutil repairPermissions / keinen UUID 35 Error mehr bekommt hat es funktioniert.

Links rund um PC_EFI:

Netkas' Forum

PC_EFI_v8

 

Hoffe das war hilfreich und bitte informiert mich wenn mir wo ein Fehler unterlaufen ist.

 

greetz fassl

Share this post


Link to post
Share on other sites

ich weiß, die Frage wird kommen ... die genaue "Anleitung" zu Chameleon:

 

auf benannter Seite den Loader ziehen und entpacken ... aus dem entpackten Verzeichnis das file "boot" ins Root-Verzeichnis kopieren/ziehen ... im Terminal zu dem entpackten Verzeichnis wechseln und folgendes eingeben:

 

vorher natürlich die Disknummer (X) und die Partition (Y) per "diskutil list" ermitteln, also

 

diskutil list

 

sudo -s

 

fdisk -u -f boot0 -y /dev/rdiskX

 

dd if=boot1h of=/dev/rdiskXsY bs=512 count=2

 

 

und jetzt kommt der Knüller ... mein 10.5.3 System bootet jetzt doppelt so schnell !!! Danke fassl für den geilen Hinweis !!!!

Share this post


Link to post
Share on other sites

Oder einfach die .pkg doppelklicken :)

 

Kann sein dass pc_efi bei dir den FSB nicht korrekt ausgelesen hat und deshalb hast du jetzt nen schnelleren boot. Oder was weiß ich ;)

Share this post


Link to post
Share on other sites

.pkg ? ... die gabs auf der Seite nicht, oder ich habs übersehen ?! ... oder nur im IRC ?

 

hatte eh bisher nur per DVD gebootet ... dachte, das is egal ... aber die Kiste rennt auf einmal wie Sau *freu* ... man lernt ja nie aus ;)

Share this post


Link to post
Share on other sites

Richtig blöde Frage wahrscheinlich ... diese Dinge funktionieren immer nur mit Intel-CPUs, oder? Vermisse Details, mit was es kompatibel ist. :-(

Share this post


Link to post
Share on other sites

hmmm, Fassl danke!

 

Doch So hatte ich etliche Male PC_EFI V8 installiert. Mein System ist danach immer gebootet (ohne GFX String) doch EFI hat anscheinend nicht funktioniert :soldiers:

 

 

Denn mit:

 

terminal: ioreg -lw0 -p IODeviceTree | grep EFI

 

wenn nix kommt -> nicht installiert

 

Kommt nix...

 

/dev/disk0
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	 FDisk_partition_scheme						*298.1 Gi   disk0
  1:			   Windows_NTFS Untitled			   53.7 Gi	disk0s1
  2:				  Apple_HFS Alt					 9.8 Gi	 disk0s5
  3:			   Windows_NTFS Daten2				 175.8 Gi   disk0s6
  4:				  Apple_HFS Leopard				 58.8 Gi	disk0s7
/dev/disk1
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	 FDisk_partition_scheme						*186.3 Gi   disk1
  1:				  Apple_HFS Download				186.3 Gi   disk1s1
/dev/disk2
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	 FDisk_partition_scheme						*57.3 Gi	disk2
  1:				  Apple_HFS Backup				  57.3 Gi	disk2s1
/dev/disk3
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	 FDisk_partition_scheme						*74.6 Gi	disk3
  1:				  Apple_HFS Daten Mac			   74.6 Gi	disk3s1
/dev/disk4
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	 FDisk_partition_scheme						*149.1 Gi   disk4
  1:				  Apple_HFS Music				   149.1 Gi   disk4s1

 

Das ist meine Partitionstabelle. Ich habe PC_EFI in Disk0S7 installiert. Auf Alt ist ein kleines Sicherheitssystem (iAtkos 2.0i zum Testen; Backup ist ein Backup meiner Leopard Platte - aber leider nicht Bootfähig)

 

Chameleon hatte ich mal mit dem PKG installiert. Der Erfolg war, dass ich immer einen Boot0: Error hatte und per Script.sh von der ToH DVD Darvin neu installieren musste...

 

Ich hätte gerne EFI, damit ich einen 9.3.0 Kernel nutzen kann. Vanilla wird zwar nicht laufen (erst mit dem Q6600), aber wohl ein Binpatched sollte es...

 

Hat irgend jemad eine Idee?

Share this post


Link to post
Share on other sites

Chameleon besteht aus 3 loadern, stage 0 (boot0), stage 1(boot1h) und stage 2(boot) in stage 2 is die EFI simulation eingebaut, sowohl in Chameleon als auch in pc_efi

Share this post


Link to post
Share on other sites

Habe ich auch beides schon probiert...

 

Sowohl Leopard in Single User als auch Alt in Single User..

 

Auch habe ich mal von jedem Single User Mode startupfile Tool sowohl für BEIDE Partitionen als auch nur für die jeweils gebootete Partition installiert...

 

Auch habe ich bei der iAtkos Installation in ALT PC_Efi angegeben...

 

Schon komisch...

Share this post


Link to post
Share on other sites

Werde ich machen...

 

Aber jetzt gleich ist erstmal F1 und dann EM...

 

Werde aber berichten!

 

Danke erstmal!

 

 

Doch eine Frage: Wenn Chameleo, dann brauche ich auch KEIN EFI mehr, oder?

Share this post


Link to post
Share on other sites

Ok, hab es dann doch jetzt noch probiert...

 

Boot0: error

 

 

habe es so gemacht: File Boot aus dem Archiv ins Leopard Root gezogen (vorhandene ersetzt), dann im Terminal:

 

sudo -s
cd in/das/verzeichnis/wo/chmeleon/entpackt/wurde
fdisk -u -f boot0 -y /dev/rdisk0

dd if=boot1h of=/dev/rdisk0s7 bs=512 count=2

 

ohne Erfolg...

 

Dann habe ich sogar die Files boot0, boot1h und cdboot nach usr/standalone/i386 kopier und die vorhandenen ersetzt... Gleiches Ergebnis..

 

Schade!

Share this post


Link to post
Share on other sites

Es funktioniert auch mit AMD, das wäre ja der Wahnsinn schlechthin. Backup jetzt und dann gehts los, danke für die Antwort. Ich werde berichten!

 

//edit:

Die Installation von EFI scheint funktioniert zu haben (Konsole: kein Eintrag zu firewire "failed to dertermine ..."), bei diskutil repairPermissions / keine UUID 35-Fehler. Siehe Systeminfos in der Signatur.

 

In welcher Weise bin ich jetzt mit einem AMD überhaupt in der Lage, einen Vanilla-Kernel zu nutzen? Ist es richtig, dass nur der Vanilla-Kernel dafür sorgt, kurz gesagt, dass ein Rechner als Mac (bei Apple-Updates etc.) erkannt wird?

Selbst wenn dies dann der Fall ist, ist es doch weiterhin problematisch, mit AMD diverse Updates von Apple zu fahren (z. B. 10.5.3), liege ich damit richtg oder falsch? Danke für Antworten! :-)

Share this post


Link to post
Share on other sites
In welcher Weise bin ich jetzt mit einem AMD überhaupt in der Lage, einen Vanilla-Kernel zu nutzen?

gar nicht, vanilla geht nur mit Core Intel CPU's

 

 

Ist es richtig, dass nur der Vanilla-Kernel dafür sorgt, kurz gesagt, dass ein Rechner als Mac (bei Apple-Updates etc.) erkannt wird?

nein, wenn du vanillla kernel und eine unmodifizierte appleacpiplatform.kext verwendest wird er dir als model nicht MacPro oder was auch immer anzeigen sondern die information die er aus deinem SMBIOS liest. bei mir zB AMILO PI 1556 (laptop modellbezeichnung)

 

Selbst wenn dies dann der Fall ist, ist es doch weiterhin problematisch, mit AMD diverse Updates von Apple zu fahren (z. B. 10.5.3), liege ich damit richtg oder falsch? Danke für Antworten! :-)

Mit AMD ist so ziemlich alles problematisch ;)

Share this post


Link to post
Share on other sites

Danke für die Antwort. :-)

 

Nächste und eigentlich fast letzte Frage. Zum Surfen und Arbeiten habe ich einen Dell Vostro 1400 gekauft, der morgen geliefert wird, Celeron 540 CPU, ist es mit dem möglich, einen Vanilla-Kernel zu nutzen? Es muss nicht unbedingt funktionieren, ich spiele auch gerne, wie hier auf AMD, damit rum, aber es wäre natürlich geil ... :-)

Share this post


Link to post
Share on other sites

Ne Celeron ziemlich sicher ned, aber solangs bin patched und gehackte kernel gibt is das ja wayne ;)

 

EDIT: hmm, obwohl der supported ziemlich viel:"MMX, SSE, SSE2, SSE3, SSSE3, Intel 64 (Intel's x86-64 implementation), XD bit (an NX bit implementation)"

 

naja, probieren kann mans ja mal :(

Share this post


Link to post
Share on other sites

So, ich nochmal...

 

Also es scheint an meinem System - oder dem Windows auf meiner HDD zu liegen...

 

Habe gerade iATOKOS 2.0i auf meinem Notebook installiert und da geht EFI... - bringt aber nichts, da viel zu Langsam...

 

 

/EDIT:

 

Ich habe jetzt den Native Mode im BIOS für AHCI 0-3 deaktiviert. Jetzt funzt EFI - jedoch der Boot mit nem 9.3er Kernel bleibt hängen - ohne Fehlermeldung...

 

/EDIT2:

 

Kernel 9.3.0.0 (aus dem IRC) mit -64bit flag läuft jetzt auch perfekt! (dsmos.kext - vor allem mit richtigen Rechten sollte man nicht vergessen :) )

Share this post


Link to post
Share on other sites

Wäre sehr cool wenn du das ganze nochmal so super verständlich für den Audio string z.B für die ALC889 Karte machen könntest.

 

Vielen Dank!

 

Greetz

FuRiuS

Share this post


Link to post
Share on other sites

Hat vielleicht schon jemand einen EFI String für den Grafikchip meines boards (GMA 950, Geräte-ID: 0x2772, Versions-ID: 0x0002) gebastelt? So dass ich nur noch Schritt 6 der Anleitung nachvollziehen müsste. Für Experten sind die vorhergehenden Schritte wahrscheinlich Kinderkram, für Laien bleiben aber noch ein paar Fragen offen.

Oder bestünde Interesse, die Anleitung anfängersicher zu formulieren?

 

 

10.5.2 und 10.5.3 laufen zwar auch so auf meinem Rechner, allerdings mit leichten Grafikunebenheiten, die z.B. auftreten, wenn man Findernamen editiert. Diese Macken verschwinden zwar, wenn man das Leopard Graphic update installiert, aber dann funktioniert der Ruhezustand (S3) nicht mehr.

 

Grüsse, pilsator

Share this post


Link to post
Share on other sites

Der erste Stolperstein im Kapitel "EFI Strings erstellen Für Grafikkarten" war für mich der Satz

 

"Sofern in dem Beispiels String den ihr geladen habt keine Plist vorhanden ist müssen wir diese zuerst generieren" (Abschnitt 3).

 

Ich hatte "geladen" zunächst verstanden als "zur weiteren Bearbeitung mit einem Programm geöffnet" - wovon vorher ja nicht die Rede gewesen war. Dann fiel mir ein, dass wohl "runtergeladen" gemeint war.

Runtergeladen als "Beispiel String" für den Intel GMA 950 hatte ich von dem mediafire-link einen Ordner, der 2 Dateien enthielt: gma950.hst und gma 950.plist. Ich habe das einfach mal etwas willkürlich interpretiert als "Plist vorhanden". An dieser Stelle fragt sich der Laie: kann ein string eine plist enthalten, ohne dass man das so auf Anhieb sieht (Stringtheorie?). Handelt es sich eventuell bei einer der beiden Dateien im Ordner um den string und müsste der auf Vorhandensein einer plist untersucht werden? Ich habe mich letztlich gegen diese Interpretation entschieden, weil eine plist nach meiner Kenntnis eine Datei mit eben diesem suffix ist und nicht ein Bestandteil einer anderen Datei.

Ich bin also davon ausgegangen, dass nicht erst eine plist generiert werden muss und ich direkt mit Punkt 6 fortfahren kann.

Welche der beiden Dateien im Ordner ist nun der Hex String? Keine hat das suffix .hex. Während die .plist-Datei in TextEdit ein bisschen wie html aussieht, sieht die .hst-Datei mit der Folge von Zahlen und Buchstaben schon eher so aus, wie wohl ein string aussehen sollte.

Ich habe also die com.apple.Boot.plist wie beschrieben im Terminal gebackupt und im Property List Editor wie beschrieben die Folge von Zahlen und Buchstaben eingetragen, die man zu sehen bekommt, wenn man die Datei gma950.hst mit TextEdit öffnet.

Abschliessend sollte der Injector deaktiviert werden. Ich habe aber im Erweiterungsordner nichts gefunden, was irgendwie nach einem Injector aussah. Kein Natit/Nvinject/NvinjectGo/Atiinject etc.

Ich habe mehrere Systeme installiert, in anderen System findet sich eine natit.kext, aber nicht in diesem.

Wo nichts ist, kann man nichts deaktivieren, also habe ich einfach einen Neustart gemacht.

 

Ich muss noch erwähnen, dass ich vor der Modifikation der com.apple.Boot.plist das Leopard Graphic update installiert hatte, weil fassl irgendwo in einem anderen thread sowas geschrieben hatte wie "Graphic update installieren, gfx string eintragen und fertig". Aus Erfahrung wusste ich, dass ohne gfx string dann der Ruhezustand (S3) nicht mehr funktioniert und die Auflösung nur durch Editieren der com.apple.Boot.plist verändert werden kann, nicht mehr in den Systemeinstellungen.

Also Neustart...Ruhezustand funktioniert nicht, Auflösung kann in den Systemeinstellungen nicht verändert werden.

 

Wenn ich das versuche:

 

"Ob der String auch übergeben wurde überprüft ihr mit ioreg -lw 0 -p IODeviceTree | grep device-prop"

 

vermeldet das Terminal:

 

~ normalo$ ioreg -lw 0 -p IODeviceTree | grep device-prop

| | "device-properties" = <6d0000000100000001000000610000000200000002010c00d041030a000000000101060000027

ff0400100000006d006f00640065006c0000000b000000474d412039353020000000410041005000

c002c00480061007300500061006e0065006c0000000800000001000000>

| | "device-properties" = {"acpi-path"="IOACPIPlane:/_SB/PCI0@0","acpi-device"="IOACPIPlatformDevice is not serializable"}

 

Es dürfte kein Problem sein, den vorherigen Zustand wiederherzustellen - das backup der com.apple.Boot.plist durch Umbenennen aktivieren und AppleIntelGMA950.kext und AppleIntelIntegratedFramebuffer.kext von einem anderen 10.5.2 System mit kext helper installieren. Aber jetzt habe ich Blut geleckt, das mit den gfx strings kann doch nicht so schwer sein.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×