Warum rEFInd für etwas nehmen, was die Firmware auch selbst kann?
Beiträge von mhaeuser
-
-
"Index" ist die Position der neuen Boot-Option. Einfach vorher mal "bcfg boot dump" ausführen und gucken, on du's irgendwo dazwischen quetschen oder ans Ende packen willst.
"Pfad" ist der Pfad zur Clover-Datei. Also, schalte auf die ESP (normalerweise "fs0:" - und ja, das ist das volle Kommando, da muss nix vornedran) und geh' in den Clover-Ordner ("cd EFI\CLOVER"). Vom Clover-Ordner aus ist "{Pfad}" gleich "CLOVERX64.EFI". Könntest auch einfach "fs0:\EFI\CLOVER\CLOVERX64.EFI" ausschreiben, aber das Tippen mit US-Layout auf einer DE-Tastatur ist oft nervig.@QSchneider Trautes Heim, Glück allein.

-
MountEFI wird dir nicht weiterhelfen. Abgesehen davon, dass diese Funktion nur noch über den NVRAM funktioniert (was ich nicht wirklich verstehe, war glaub' ich eine Änderung von JrCs), lädt nicht der Kernel die Kexts, sondern der Bootloader. Da dies in der EFI-Phase geschieht, ist die ESP definitiv gemountet und MountEFI hat keine Wirkung.
-
UEFI hat kein Konzept von "bootbaren Platten/Partitionen", alle, die das im Bootmenü in die Sicht geworfen bekommen, haben einfach einen OEM erwischt, dem diese Bootweise gefällt. Die einzigen, von UEFI zugesicherten Methoden sind 1) auf wechselbaren Medien wird die BOOT{arch}.efi aus dem Boot-Verzeichnis der EFI-Partition gestartet und 2) erstellte Boot Optionen werden für nicht-Wechseldatenträger angeboten. Also, müssen viele eine Boot Option selbst erstellen.
Eine solche erstellst du entweder via UEFI Shell (bcfg boot add {Index} {Pfad} "{Name}") oder via Clover auf dem USB-Stick (sollte unter "Clover Boot Options" oder wie auch immer einen Eintrag zum Erstellen geben).
-
Falls 1) Die richtige Kext installiert ist 2) Rechte korrekt sind und Cache definitiv richtig erstellt, kann es auch an der "FSBFrequency" liegen... ist sie zu hoch oder zu niedrig, wird das ganze System schneller bzw. langsamer - bei minimalen Abweichungen merkt man beim Darstellen der GUI nichts, aber die Verschiebung der Frequenz zum Audiochip kann sich durch Knistern bemerkbar machen.
Also, sicherstellen, dass alles korrekt installiert und eingerichtet wurde und falls das Problem dann immer noch besteht, die "FSBFrequency" kontrollieren (via IOJones oder aus der Clover Debuglog kannst du den genutzten Wert auslesen und via Clover config verändern).
-
Ich hab' im Moment alles zu. Wenn ich was aufmachen will, kann ich das immer noch tun.
-
Wow, was'n das für eine Paranoia hier?
Clover gehört festgenommen? Ins "BIOS geHÄCKT"? Unglaublich?
Glauben kannst du das gerne schon, denn der Eintrag wird von OS X höchstpersönlich erstellt. Dies geschieht während der Installation, manchmal nach Updates und immer, wenn du die "Startup Disk" festlegst. Da dieser Eintrag mit vollem HDD-Pfad festgelegt wird, anstatt wie Windows- und Clover-Einträge nur mit Partitionsinformationen, aus denen die Firmware beim Starten einen kompletten Pfad erstellen muss, wird er von den meisten Firmwares unter keinen Umständen entfernt. Bootbar ist er nicht, da erstens Clover nichts davon weiß (es ist ja kein DXE-Treiber) und zweitens, weil der Pfad keinen Dateipfad enthält, sondern dieser auf Macs via "bless" eingeholt wird. Außerdem ist der SATA-Multiplier nicht gesetzt, was bei vielen Firmwares einfach zur Arbeitsverweigerung führt (würde die Firmware den Eintrag selbst erstellen, wie bei Windows, wäre der Multiplier korrekt).Also, beruhig dich, es ist alles in Ordnung.

-
Solange dein Board eine UEFI-Firmware von AMI hat und Intel Boot Guard nicht genutzt wird (meistebs nur Notebooks/Tablets), sollte es funktionieren. Andere UEFI-Implementierungen als die weit verbreitete AMI-Variante können funktionieren, müssen aber nicht.

Habe aber definitiv eine Wiederherstellungsoption parat, z.B. DualBIOS, USB-Flashback oder einen SPI-Programmierer. Viel Glück!
-
Für Ozmosis auf jeden Fall, ist ziemlich "schmal"... Wenn du kexts und so weiter drinne haben möchtest, musst du halt gucken, wie's hinkommt.
-
Nö, hat mit Mac vs Nicht-Mac nix zu tun. Das NVRAM-Tool hat den OS X "Namespace" als Standard, egal, auf welcher Maschine.
Starte mal mit Chimera und guck, welche layout-id du verwendest; und dann, welche nach dem Start mit Ozmosis angezeigt wird. -
Wer dieser "The King" ist und wieso man ihm glauben schenken sollte konnte ich beim durchstöbern des Threads allerdings nicht herausfinden.
Vielleicht verschafft dir dieser Post mehr Klarheit: http://www.insanelymac.com/for…d-quo/page-1#entry1883913
-
Ozmosis überprüft nicht beide VendorGuids nnach den selben Variablen. Welcge Guid welche Variable hat, siehst du auf der OzmosisBIOS GitHub-Seite.
Außerdem ist zwar AcpiLoaderMode nicht nur für OS X, sollte aber auf das Bootmenü keine Auswirkungen haben. -
-
Such doch mal in /System/Library/Extensions anch FakeSMC.kext.

-
Naja, entweder lagerst du Dateien (vielleicht sogar Ozmosis selbst) auf die ESP aus, oder du komprimierst Treiber... CORE_DXE, CSM, usw. bringen relativ viel. Muss nicht immer direkt neue Hardware sein.

-
Du könntest die Netzwerk-/CSM-Treiber komprimieren. Ozmosis wird in Zukunft nicht wieder viel kleiner werden, also ist es nur vorausschauend.

-
Wieso hast du nicht Ozmosis 1479 genommen? Damit sollte der NVRAM meines Wissens nach korrekt angesprochen werden können.
-
Als ich die Nachricht zu erst las, dachte ich, dass es zu schön sei um wahr zu sein. Dann sah ich die Quelle und merkte, dass ich richtig liegen könnte (und damit meine ich nicht insanelymac!)... Hoffen wir also das Beste und konsumieren für die Zwischenzeit "Tea. Earl Grey. Hot."
Willst du damit sagen, dass du THe KiNG nicht für eine vertrauenswürdige Quelle hälst?
-
guck mal was. wenn du 'nvram -p' im Terminal eingibst, unter 'boot-args' steht.

-
"Gibt es schon eine El Capitan fähige Ozmosisversion ?"
- Ich glaub' es gibt keine Frage, die in den letzten Tagen so oft gestellt wurde wie diese.
Kurz und bündig: nein.Zum ALC887: Da benutzt du am besten toleda's Patches. Achte drauf, dass du via DSDT/Clover/dev_props die richtige layout-id für die Kext setzt-