Beiträge von griven

Eine eigentlich praktische Funktion nur leider oft an der Praxis vorbei weil man viel Schrott auf hat den man eigentlich beim nächsten Start nicht wieder aufhaben will. Ich habe bisher keine Einstellung gefunden die das grundsätzlich deaktiviert *nöl*

Sieht schwer nach einer Boot DVD aus die nicht astrein in ordnung ist.

Zum Verständnis: von der DVD wird ähnlich wie bei einer Linux LIVE CD ein Mini System im Speicher erzeugt und gebootet quasi ein bis auf das allernotwendigste reduziertes MaC OS. Auf diesem MiniSystem startet dann der eigentliche Installer.

Die Fehlermeldung, die Du bekommst sagt aus das bei der allocation des notwendigen Speichers für die Ramdisk ein fehler aufgetreten ist meist hängt das mit einer nicht 100% funktionierenden Bootdvd zusammen in seltenen Fällen kann es aber auch am Speicher selbst liegen.

Ich gehe davon aus, dass Du dem Stick nach der Behandlung mit XMove durchaus auch einen Bootloader verpassen kannst. Ich würde da einfach mal versuchen mit Multibeast Chimera oder Chamelon druff zu packen und das testen.

Ich hab da auch lange fummeln müssen bis mir die Idee kam, den Stick nach dem GUID Schema zu partitionieren und eben nicht mit FAT oder so wie sonst bei USB Sticks üblich.

Was Löst die Kernelpanik denn aus sprich was steht da?

Grundsätzlich ja, kannst Du, der Assistent der Dich nach dem ersten starten der neuen Installation begrüßt fragt Dich sogar ob Du Daten oder sogar ganze Benutzer aus einem TimeMachine Backup wiederherstellen möchtest ;O)

Auch von mir alles Gute zum Geburtstag

Ich befürchte da wirst Du bei MAC OS wenig Glück mit haben.

Die gesamte Gui aber auch einige der anderen Frameworks setzen bestimmte Versionen des Kernels und der Kexte voraus und versagen schlichtweg den Dienst wenn da was nicht zusammenpasst. Was vermutlich gehen wird ist dann in den singleuser Modus zu booten aber die Gui bekommst Du auf die Weise nie und nimmer ans laufen.

Ich hatte das Release auch testweise installiert. Ergebnis war, dass mein Rechner gar nicht mehr gebootet hat entweder "MACH Kernel not found" oder Kernelpaniken ich bin erstmal wieder zurück auf chimera ;O)

Im Singleusermode geht es ganz gut mit nano.

einfach alles ändern was nötig ist und dann mit ctrl+x verlassen natürlich die Frage ob man die Änderungen speichern möchte mit Y (liegt auf der Taste Z) bestätigen und fertig.

Die Sache sieht so aus, dass Apple mit dem Letzten Update für SnowLeopard wohl die native Unterstützung für NVidia Fermi Karten eingestellt hat, komischerweise laufen sie aber unter Lion wieder klaglos, muss man nicht verstehen ist halt Apple Logik...

Ganz gut laufen sollen die NVidia eigenen Treiber <<Hier entlang bitte>>
Vielleicht ein Anfang, möglicherweise hat ja jemand von den anderen Usern hier noch eine bessere Idee da ich wahrlich kein nvidia Spezialist bin.

Wäre toll, wenn es die XML´s auch für den ALC833 Codec geben würde.
Die nötigen Befehle zum Binärpatchen habe ich bei Insanlymac gefunden:

ALC833

Einen Linuxdump von dem Codec habe ich aber ich komme damit nicht weiter.

Also auf die Grafische Oberfläche kannst Du im Moment dann gar nicht booten wenn der Rechner im Startvorgang eine KernelPanik verursacht.
Hier hilft dann nur noch der Single Mode "-s" oder Du versuchst mal im abgesichtern Modus "-x" zu starten. Wenn abgesichert geht, dann einfach über die Oberfläche den installierten Treiber wieder löschen, wenn nicht musst du das Manuel über die Konsole machen.

Dazu einfach wie folgt vorgehen:

- Starten mit dem Schalter -s für SingleUser oder alternativ von der Bootcd starten und dort die Terminal App wählen
- Wenn die Eingabeaufforderung kommt folgende Befehle eingeben:

Achtung! Du bist jetzt als root am System angemeldet bitte vorsichtig agieren. Wenn Du vorher im Verbose gebotet hast siehst Du normalerweise bei dem Text der auf die Kernelpanik hinweist welche kext die Panik ausgelöst hat, sehr Wahrscheinlich wird es der Treiber sein, den Du zuletzt installiert hast den also am besten gleich mal wieder löschen oder wohin verschieben wo er nicht stört.

wird man den Treiber wieder los, ein anschließendes exit startet den Rechner in die GUI durch, ein reboot startet den Rechner neu je nachdem was gewünscht ist.

Moin zusammen,

hat es irgendwer von Euch hinbekommen bzw. hat irgendwer vielleicht eine Idee wie man das auf dem genannten Board verbaute onboardsounddings dazu bewegen kann so zu rennen, dass es ohne VoodooHDA läuft?

Ich frage deshalb weil im Zusammenspiel mit der VoodooHDA.kext einige komische Effekte auftreten, die ich gerne los wäre...

Ohne VoodooHDA/Ohne Sound:
- Graka wird mit "GraphicsEnabler = YES" locker erkannt
- Netzwerk (RTL8169SC/8110SC) wird erkannt bekommt aber "nur" eine generische IP == Kein Inet mit Lnx2Mac dann aber funktionstüchtig
- Sleep Funzt nicht hat es aber nie weder mit DSDT patch noch mit Sleepenabler. Ich denke es liegt daran, dass ich konsequent nur P-ATA Platten in dem Hacki einsetze....

Mit VoodooHDA/Mit Sound:
- ATY_Init.kext MUSS geladen werden weil ansonsten {PCI Configurartion Begin} Showstopper (Lion,SL.0.8)
- Mic unrauchbart, da vollkommen verrauscht
- Netzwerk keine Funktion mehr mit Lnx2Mac unter SL hilft Realtek1000.kext (nur 32bit mode, 64Bit = Kernel Panik) und unter Lion geht selbst das nicht mehr, hier war eine neue Karte fällig

Falls also irgendjemand eine Idee hat wie ich das "Miststück" ohne VoodooHDA ans rennen bekomme Immer her damit ;O)

*ps* die Lion eigene Rechtschreibkorrektur, die plump bei IOS abgekupfert ist wäre ich auch gerne los, NERVDINGS DAS...

Noch ein Update und ganz sicher das letzte zu dem Thema von meiner Seite aus...

Ich habe mich damit abgefunden, dass mit DSDT Patching bei dem Board in meinem Setup (P-ATA only) nix zu machen ist. Zwar bekomme ich es hin, dass ich ohne NullCPUPowermanagement.kext booten kann aber der Preis dafür ist ein Hubschrauber auf meinem Schreibtisch, sprich der CPU Lüfter dreht immer volle Granate schein also so, als wenn die CPU immer unter Volllast läuft, selbst dann, wenn der Rechner in den "Ruhezustand" geht.

Mein Fazit also, das P5VD2-X ist und bleibt Hackintosh mäßig eine Großbaustelle der man einfach nicht beikommt. Angefangen bei dem DSDT Zeuch über die Netzwerkkarte bis hin zum Sound nix als frickelei und Patchwork...

Wenn einer von Euch ne Platine rumliegen hat die DDR-2 Ram frisst, eine P-ATA Controller hat und nebenher kompatibler zu MAC OS ist als mein ASUS, dann immer her damit insbesondere dann, wenn das Dingen rumliegt und verstaubt und es auch sonst niemand haben möchte...

dsdt.aml habe ich jetzt leider ist aber Essig mit nativen Powemanagement, Sleep und Co denn trozt DSTD Fixer Einsatz bekomme ich ne nette Kernel Panic wenn ich NullCPUPowermanagement.kext entferne.

Jemand hierzu eine Idee? Dieses dsdt Zeuch werde ich wohl nie wirklich verstehen *seufz*

Edit: Ha so langsam werde ich mit dem Zeuch doch noch warm ;O)
Hab mich noch mal mit dem Editor hingehockt und siehe da nun können wir auch ohne NullCPUPowermanagement und ohne Kernelpanik booten. Ob sleep geht weiß ich noch nicht wird sich zeigen im moment versuche ich meine Soundkarte dazu zu bewegen ohne VodooHDA Treiber zu laufen...

Jesess, da will ich mich doch glatt mal an das Thema anhängen wo wir hier doch schon mal einen DSDT Experten mit ASUS Board haben...

Ich hocke hier auf einem ASUS P5VD2-X und es ist mir bis heute noch in keinem Forum eine wirklich funktionierende DSDT für Das Board untergekommen. Ich habe zwar mit meinen zugegebenermaßen rudimentären Kenntnissen im Bereich DSDT Patching zumindest mal das RTC/BIOS Reset Problem in den Griff bekommen aber es wäre natürlich schon cool, wenn man den Rest auch ein wenig besser ans rennen bekommen würde...

Ausgehend vom "Golden Master" also der letzten Beta von Lion sieht es wohl so aus, als wenn Apple es tatsächlich drauf ankommen lässt und Lion zumindest zunächst nur Online vertreibt. Der "Golden Master" kommt als .pkg was einer ausführbaren Datei entspricht und öffnet auf Doppelklick den Installer von Lion in dem man dann wählen darf/kann ob man ein Update machen möchte oder doch lieber neu installieren mag.

Ich habe die Updatevariante auf einem installierten SnowLeopard probiert und musste ernüchtert feststellen, dass nach einer guten halben Stunde installationsarbeit inkl. reboot mich mein SnowLeopard nach wie vor freundlich begrüßt hat. Soweit ich das verstanden habe installiert der Installer erstmal ein Basis System (basesystem) und kopiert da alle nötigen Dateien hin um die Installation dann nach dem Reboot zu finalisieren was sicher auch auf MAC´s gut funktioniert (inkl. der ominösen rescue Partition) auf unseren Hacki´s hingegen dank EFI Emulation leider nicht.

Dankenswerterweise kann man sich selber eine installierbare Version aus dem pkg basteln, hierzu folgt man einfach der dieser Anleitung: Klick Me und kann dann wie auch schon von Leopard gewohnt installieren oder Updaten wenn man im Installer seine SL Partien als Ziel der Installation wählt.

Wenn ich mir das hier alles so durchlese ist mein System wohl eher der Inbergriff für das Gegenteil des Threadtitels ;O)

Aber was solls man soll ja auch Leuten mit weniger kompatibler Hardware Mut machen ;O)

Also hier rennt ein inzwischen etwas in die Tage gekommenes ASUS P5VD2-X das sich, wie ich feststellen musste, nur sehr bedingt "Out of The Box" für Hackintosh Systeme eignet. Wer es dennoch versuchen möchte findet in dem Board eigentlich einen guten und stabilen Begleiter durch die bunte Apple Welt.

Als Grafikkarte setze ich eine ATI Radeon HD5570 (Saphire) mit einem GB DDR3 Grafikspeicher ein weil die ursprünglich verbaute Point of View Geforce 7800GT sich absolut nicht davon überzeugen lassen wollte, dass es auch Systeme mit 64Bit geben soll *hrhr*

Insgesamt betreibe ich meinen Hacki wohl eher auf LOW END Hardware was dem Ganzen aber eigentlich keinen Abbruch tut denn selbst Lion läuft auf der Kiste mit ein wenig überzeugungsarbeit bis zum Golden Master bislang absolut stabil und ohne zu murren.

Fazit mein Setup eignet sich nicht für Einsteiger und Menschen, die möglichst wenig selbst Hand anlegen möchten für Leute, die es wie ich aber lieben zu basteln und den "ES GEHT ABER DOCH" Effekt mögen, denen sei so ein alter Hobel wie meiner dringend ans Herz gelegt, denn das Gefühl, dass sich einstellt wenn die Kiste endlich ohne KernelPanic durchbootet hat was gottgleiches.

Ach fast vergessen, neben einer Handgestrickten DSDT.aml benutze ich noch die RTL1000.kext, VoodooHDA.kext, FakeSMC und die ATY_init.kext um unter Lion dem überaus lästigen <PCI Config begin> Problem zu begegen.

Hi Gandalf,

einfache Antwort, nein kann man nicht.

Kexte (Kernel Extensions) sind Treiber die der Kernel nach Bedarf hinzuläd um die vorhandene Hardware zu unterstützen. Um über einen DSDT Patch drittanbieter Kexte einzusparen um eine möglichst orginale Installation zu bekommen muss Apple die fragliche Hardware (in Deinem Fall Sound und Lan) von sich aus schon mal unterstützen sprich die verbaute Hardware muss zumindest rein theoretisch schon mal in irgendeinem echten MAC aufgetaucht sein.

Ein DSDT Patch ersetzt im Grunde auch keine Kexte sondern biegt die Bios Informationen des Rechners so um, dass MAC OS die Hardware sicher erkennen kann und die Apple eigene KEXT beim Bootvorgang einbindet. Je nach verwendeter Hardware braucht es im übrigen nicht mal ein DSDT Patch um die Apple eigenen Treiber zur Kooperation zur bewegen oftmals reicht es schon aus die Geräte ID der verwendeten Soundkarte/Lan Karte in die info.plist des entsprechenden Apple Treibers einzutragen (applehda.kext, ionetworkingfamily.kext) und schon kann MAC OS damit umgehen.

Fazit DSDT Patches sind sicher Sinnvoll aber nur in den Fällen in denen die verbaute Hardware dem entspricht was auch Apple verbaut und MAC OS diese aufgrund der "fehlerhaften" bzw. Windows optimierten DSDT Tabellen im PC Bios nicht erkennt. Bei Exotischer oder älterer Hardware wird man auch mit einem DSDT Patch nicht wirklich drum rum kommen die Appletreiber entweder mit der Geräte ID der entsprechenden Hardware auszustatten oder eben doch weiter die drittanbieter Kexte zu nutzen.

Da ich finde das dieses Thema absolut gar nicht erledigt ist, eben weil es auch eine ganze Menge Leute gibt, die trotz Subskription im Developer Programm sogar mit "echten" Macs den Fehler (noch immer) bekommen mach ich einfach nen neuen Thread dazu auf...

Ursache für das "GUID" Problem:
GUID steht für "Globally Unique Identifier" und repräsentiert im Grunde gar nichts anderes als die MAC Adresse Eurer Netzwerkkarte. MAC Adressen an sich sind tatsächlich einzigartig sprich es gibt auf der Welt eigentlich keine zwei Netzwerkkarten, die die selbe MAC Adresse haben jedenfalls sollte das eigentlich Werksseitig so geregelt sein.
Eigentlich bezieht das Betriebssystem die MAC Adresse direkt aus dem Bios des Computers und dieses bezieht sie wiederum direkt aus den Hardwareinformationen der Karte und genau hier kommt die "HACKMACK" Community ins Spiel. Während es bei Rechnern deren Bios MAC OS nahezu ohne Änderungen unterstützt kaum Probleme mit der GUID gibt finden sich User "älterer Systeme" oder eben auch User von echten MACS mit einer Netzwerkkarte, die nicht zum Lieferumfang des MAC´s gehörte und die demnach eine modifizierte Kext benötigt um überhaupt zu funktionieren, oftmals in dem GUID Dilemma bzgl. des Appstores wieder.

Das Problem an sich:
Viele Hackintoshler und auch einige MAC´ler deren eingebaute Netzwerkkarte abgeraucht ist nutzen Hardware für die Internetverbindung, die so von Apple nicht vorgesehen wurde und damit eben auch von MACOS so ohne weiteres nicht erkannt wird, was ja erstmal dank entsprechender KEXT kein Problem darstellt.
Einmal die richtige KEXT gefunden rennt die Karte als gäbe es kein Morgen mehr zumindest ist das genau solange der Fall wie man nicht auf die Idee kommt das eine oder andere angezeigte Update aus dem APPStore laden zu wollen oder gar was neues installieren möchte denn spätestens dann bekommt man den roten TEXT zu sehen mit dem Hinweis auf die GUID

Die Lösung;
Hackintoshler weiter lesen, MAC´ler schade, aber die Lösung funzt bei EUCH auf keinen Fall...
Nachdem das Netzwerk (natürlich mit KEXT, bei mir R1000.KEXT 64 BIT) bei mir zufriedenstellend lief und ich den GUID Fehler beim Appstore trotzdem weiter beharrlich bekommen habe war es Zeit für ein bisschen Google und siehe da, meine installierte Kext ( und es trifft auf den Großteil aller anderen Treiber ebenfalls zu) kümmert sich einen Dreck um das, was im Bios steht bzw. die Netzwerkkarte als MAC liefert. Eigentlich ist das auch gar kein Wunder, da bei den meisten Hackintosh Rechnern mit einer DSTD.aml gearbeitet wird, die als Bios Ersatz fungiert. Wird die Netzwerkkarte nun von MAC OS nicht erkannt folgt meist eine entsprechende KEXT die das dann regelt, Netzwerk funzt...
Blöd nur, dass die DSDT.aml vor allen Treibern geladen wird und somit die KEXT für das Netzwerk zumindest im Bezug auf die MAC (Verbose Boot mal verfolgen) nur Unsinn geliefert bekommt und somit auf einen Wert zurückfällt der irgendwo in der Kext Hardcoded ist und gleichsam für den Faktor XY an Usern gesetzt ist die diese KEXT benutzen.
Für den reinen Zugang zum Internet ist das unerheblich denn da interessiert niemanden die MAC Adresse einer Netzwerkkarte, für Apple scheint diese Info jedoch relevant zu sein, da die MAC zusammen mit dem Usernamen und dem Kennwort offenbar die Basis zum Appstore login bilden.

Ich habe den trotz aller Anstrengungen bestehenden Fehler durch den Einsatz von EFI Studio und das hinzufügen eines Device Strings zur com.apple.boot.plist beheben können. Wichtig hierbei ist nur, dass es die richtige com.apple.boot.plist ist (/E/)