Wieso sollte die Auswahl des Bootvolumes mit OC nicht funktionieren? Ich verstehe nur Bahnhof.
-
-
Dann versuche ich es nochmal zu erklären.
Wenn ich macOS mit OC starte und anschließend in Systemeinstellungen -> Startvolume die Catalina-SSD als Boot-Volume auswähle, sollte doch immer automatisch Catalina booten, es sei denn ich wähle ein anderes Betriebssystem.
Leider funktioniert das nur bis ich mal Windows ausgewählt habe, danach bootet automatisch Windows. Ich muss es in der UEFI-Firmware oder in Linux mit efibootmgr wieder umstellen.
EDIT: mit automatisch meine ich vorausgewählt.
-
Richtig, ich verstehe aber nicht, inwiefern die Lage mit Clover besser sein soll als mit OC. Dass die Firmware Windows vorschiebt sollte BL-unabhängig und nicht einfach behebbar sein.
-
-
Da stecke ich nicht tief genug in der Materie um das zu verstehen. Ich kann da nur mitteilen, dass man in Clover einstellen konnte welches bootbare Medium vorausgewählt werden soll und das hat dann immer funktioniert. Auch wenn man zwischendurch mal ein anderes BS hochgefahren hat, startete danach wieder macOS, da es in Clover vorausgewählt war.
Mit OpenCore funktioniert das zwar wenn ich zwischendurch mal Linux starte, aber soblad ich einmal Windows hochgefahren habe, funktioniert es nicht mehr.
-
Doctor Plagiat Sorry, kann dazu nichts mehr sagen. Was *im* Bootloader eingestellt ist, sollte doch vollkommen egal sein, weil du beschreibst, dass Windows sich *vor* den Bootloader drängelt. Wenn Windows vor OC ist, ist egal, was OC als Standard auswählt, genau wie in Clover die Standardauswahl egal wäre, würde Windows vor diesen gesetzt werden. RequestBootVarRouting ist aver an, oder?
-
Nur ein Info, die SSDT-PM.aml funktioniert auf dem Asus Prime Z390-A, nachdem das Ding als erstes geladen wird.
-
RequestBootVarRouting steht auf true
Ich dachte was im Bootloader eingestellt ist, bleibt dann auch gültig.
Irgendwie habe ich das Gefühl jeder von uns spricht eine andere Sprache. Du der Profi stehts ganz tief in der Materie und ich der einfache Anwender kratze eben nur an der Oberfläche.
Konnte mir nicht vorstellen,dass es so schwer ist ein Problem zu beschreiben.
Trotzdem DANKE! dass du versucht hast mich zu verstehen um eventuel eine Lösung herbei zuführen.
-
PMCR bzw PMC1 hatte ich schon immer aktiv, nur dass es eben hier auf dem X299 nativ dazu gehört. Wusste nicht, dass es der Z390-Plattform so helfen kann. Wen es interessiert (Original aus Asus Prime X299 Deluxe), ich habe es mal aus DSDT und SSDT herausgepopelt und isoliert zum probieren:
-
Doctor Plagiat Sorry, kann dazu nichts mehr sagen. Was *im* Bootloader eingestellt ist, sollte doch vollkommen egal sein, weil du beschreibst, dass Windows sich *vor* den Bootloader drängelt. Wenn Windows vor OC ist, ist egal, was OC als Standard auswählt, genau wie in Clover die Standardauswahl egal wäre, würde Windows vor diesen gesetzt werden. RequestBootVarRouting ist aver an, oder?
Das kann ich nur bestätigen, ich habe mit Clover exakt das gleiche Verhalten. Das im BIOS voreingestellte (Clover)-Laufwerk wird immer zuverlässig angesprochen, wenn ich jedoch Win10
einmal boote, ist beim nächsten Start das Win10 Laufwerk im BIOS voreingestellt. Es übrigens auch egal, ob man Windows mit Shift oder Crtl runterfährt.
Der Booteintrag im BIOS wird geändert. Da können weder der Clover noch der OC-Bootloader was dran ändern.
-
Altemirabelle
Bei mir muss der Eintrag nicht als erstes geladen werden.
Ich habe den Eintrag einfach hinten dran geklemmt.
-
Ach so ich dachte es geht bei dir nicht.
-
Läuft auf Z390 Phantom Gaming ITX, musste aber sorted Order in Clover haben.
SSDT-PM.aml auf 1.Stelle, dann geht es.
-
Ich dachte was im Bootloader eingestellt ist, bleibt dann auch gültig.
Zwei Sachen:
Erstmal allgemein was DF wahrscheinlich meint:
Sehen wir es mal vereinfacht so: dein Computer startet -> dein Computer startet (weil als standard ausgewählt) OpenCore vom Datenträger -> OpenCore startet nun (weil als Standard in macOS ausgewählt) macOS. MacOS startet also nur, nachdem überhaupt OpenCore die Kontrolle hatte.
Wenn du jetzt Windows bootest und Windows schiebt sich im BIOS vor den OpenCore Datenträger, dann sieht es so aus: dein Computer startet -> dein Computer startet (weil jetzt als Standard ausgewählt) Windows direkt vom Datenträger. OpenCore kommt insofern garnicht zum Zug und kann deswegen nichts an der Situation ändern. Windows wird an OpenCore "vorbei" gestartet.
Die andere Sache ist: vielleicht musst du dein Problem einfach mal ein bisschen besser beschreiben. Der * symbolisiert im OC BootPicker ja die Standard-Bootoption. Was ist jetzt das Problem: nach einem Windows Start steht das * vor Windows und nicht mehr vor macOS oder sonstwo? Oder, nach einem Windows Start startet automatisch Windows und der Bootpicker erscheint garnicht, bei manuellem Start vom OC Datenträger ist die Standard-Bootoption aber nach wie vor macOS?
-
Genau das meinte ich und deswegen, Doctor Plagiat, verstehe ich deine Aussagen zu Clover leider nicht. Wenn OC nicht mehr Standard ist (und somit keinerlei Kontrolle haben *kann*), liegt es auch nicht an OC, wenn der neue Standard statt dem gewünschten startet. Analog dürfte keine Option in Clover Einfluss auf dieses Verhalten haben
-
Das kann ich nur bestätigen, ich habe mit Clover exakt das gleiche Verhalten. Das im BIOS voreingestellte (Clover)-Laufwerk wird immer zuverlässig angesprochen, wenn ich jedoch Win10
einmal boote, ist beim nächsten Start das Win10 Laufwerk im BIOS voreingestellt. Es übrigens auch egal, ob man Windows mit Shift oder Crtl runterfährt.
Der Booteintrag im BIOS wird geändert. Da können weder der Clover noch der OC-Bootloader was dran ändern.
Bootest du Windows über Clover oder über F12 vom Bios aus? Wenn ich Windows über Clover boote, habe ich das Problem nicht. Beim Boot mit F12 kommt es mir jedoch ebenfalls bekannt vor. Dann drängelt sich die Windows-Platte gerne mal in den Boot Option Priorities im Bios vor. Das hat jedoch mit den Clover- oder OpenCore-Einstellungen logischerweise überhaupt nichts zu tun.
-
Guten Morgen,
Bislang habe ich immer über Clover gebootet, aber auch wenn ich über F12 das Bootlaufwerk ändere passiert das gleiche. Ich vermute Windows ändert die Bootreihenfolge ungefragt,
das ist wohl eine der "Segnungen" des UEFI-BIOS.
-
Läuft auf Z390 Phantom Gaming ITX, musste aber sorted Order in Clover haben.
SSDT-PM.aml auf 1.Stelle, dann geht es.
Mit OC ist die Stelle an der es eingefügt wird egal, ich habe es einfach am Ende hinzugefügt.
Thema Thema Windows drängelt sich bei der Boot Reihenfolge vor im UEFi.
Das Tritt aber unabhängig vom verwendeten Bootloader seit dem Letzen Update von Windows bei mir auf.
-
Danke für diesen Durchbruch!! Habe bei meinem ASUS ROG STRIX Z390-F Gaming mit OpenCore 0.5.5 nun auch beschreibbares NVRAM (NVRAM als solches war ja schon immer da).
-
Kurz auch von mir ein Erfolgsbericht zu dieser Methode - allerdings nicht auf einem Z390-Mainboard, sondern einem Laptop. Ich gehe davon aus das hier gewisse hardwarespezifische Ähnlichkeiten existieren (WhiskeyLake CPU i7 8565U) und es deshalb auch funktioniert - zumindest war das der Hintergedanke bei mir um es mal mit dieser Methode zu probieren.
Hintergrund:
Habe bei meinem Razer Blade Stealth 2019 das Problem gehabt dass ein Start des Systems mit Optiov3, AptioMemory oder QcQuirks (mit verschiedenen Settings in der QcQuirks.plist) funktioniert, aber bei einem Restart oder beim Herunterfahren eine Kernel Panic geschieht. Konnte man wundervoll nachvollziehen mit keepsyms=1 bootarg.
Die einzige Möglichkeit das zu umgehen war der Einsatz von EmuVariable in Verbindung mit den RC Skripten.
Hinzunahme von SSDT-PM und Anpassung der QcQuirks.plist wie von al6042 beschrieben hat dazu geführt das:
- NVRAM nativ funktioniert (Variable gesetzt, nach Neustart vorhanden - ebenso merkt sich Clover das vorher ausgewählte Bootvolume)
- Herunterfahren und Neustart ohne Kernel Panic funktioniert.
Wirklich schöne Sache!
Interessanterweise habe ich im System nur das Device PMCR über IORegistry, aber nicht das Device PPMC.
Trotz Definition in der AML.
cheers
