Booteinträge bei OpenCore

Harry69 siehe Kommentar von cobanramo. Alles gut, habe ich auch. Um das zu ändern müsstest du die Automatik/Generic deaktivieren und die komplette Platforminfo mit den zig Einträgen von Hand konfigurieren.

Booteinträge bei OpenCore

Mal was zu ScanPolicy=0

Damit wird kein Linux angezeigt. Dazu ist ein Eintrag unter Misc->Entries nötig.

karacho bei mir wird Windows nur angezeigt, wenn ScanPolicy auf "0" steht.

Das war nicht meine Aussage Steffen. Mit ScanPolicy=0 wird Windows ja auch angezeigt. Aber ein Linux bootloader wird nicht erkannt. Ich habe ScanPolicy auf dem Standard Wert gelassen und für Windows und Linux jeweils einen Eintrag in den Entries gemacht, den ich bei Bedarf mit der Leertaste beim booten einblenden kann.

karacho es bezog sich ja nicht auf deine Aussage, sondern es war insgeheim ein Hilferuf

Alkes gut. Ich wollte auch nur darlegen, dass der TE mit ScanPolicy=0 kein Linux finden wird 😉

War wohl mein Fehler, wenn ich ESP aus der Suche ausschließe, oder?

Dann such er ja nicht Windows auf einer anderen Platte, oder?

Beim Wert 0 wird alles gescannt, auch alle ESPs und was darin zum booten gefunden wird. Nur halt kein Linux. Den Pfad zur grubx64.efi muss man manuell bei Misc->Entries eintragen.

Zitat von karacho

Mal was zu ScanPolicy=0

Tut mir leid wenn ich mit meiner Aussage "Linux" Verwirrung gestiftet haben sollte,

OC scannt keine Linux, da hat Karacho recht, meine aussage sollte eher alles andere beinhalten.

Für den Linux braucht es einen manuellen Eintrag unter "Misc/Entries"

Die falsch aussage basiert auf meinem ungewöhnlichem Umgebung, ich persönlich binde zusätzlich zbspl. ntfs.efi um externe Medien unter anderem Windows Installer oder WinPE zu starten, alles unter OC.

Werde mein aussage dort korrigieren.

Beispiel für einen Linux Eintrag;

PciRoot(0x0)/Pci(0x1D,0x4)/Pci(0x0,0x0)/NVMe(0x1,88-CF-C0-91-3B-E4-D2-5C)/HD(1,GPT,658F6EE5-AD6D-41D3-843D-BBD0F4ADC6CD,0x800,0x82000)/\EFI\Ubuntu\shimx64.efi

Den Pfad für euren müsst Ihr selber herausfinden, Siehe Handbuch, man kann nicht einfach übernehmen.

Gruss Coban

Hm sehr interessant, hab nicht einen _OSI eintrag hinterlegt. W10 rennt als gäbe es kein Morgen mit OC.

cobanramo Die Aussage zu Linux war doch nicht von dir. Der TE hat das in seinem ersten Posting gefragt. Daher schrieb ich überhaupt auf das, auf ScanPolicy bezogene Statement, das man mit '0' kein Linux angezeigt bekommt. Von daher, alles gut Jong. 😉

Zitat von badbrain

funktioniert bei mir auch ohne.

Klar, ne lösung gibt es immer, ich hantiere da nicht gross rum. verschiebe einfach die Daten in den Partition und schon hab ich das was ich brauche, mit Fat32 müsste ich entweder den wim splitten oder den Medium verändern. Mit NTFS.efi werden eben die erstellten Ntfs Partitionen mit den Installationsmedien auch gescannt. Per Fat32 kann ich sogar Linux Live Systeme starten wen ich sie mal brauche.

Wird aber glaub hier so langsam offtopic.

Gruss Coban

Zitat von Harry69

Hallo miteinander,

ich hänge mich mal hier mit meiner Frage an diesen Thread da es im weitesten Sinne auch mit dem Booten und Windows 10 zu tun hat.

System ist aktuelles Catalina im Dual Boot mit aktuellem Windows 10 auf seperaten SSD.

Bootloader ist Open Core 0.6.2.

Ich denke beide Systeme und OpenCore sind sauber konfiguriert. Beide Betriebssysteme starten sauber und laufen ohnen Probleme oder abstürze flott und stabil.

Nun ist mir unter Windows 10 unter der Systeminformation aufgefallen das unter

Systemhersteller: Acidanthera

Systemmodel: iMacPro 1,1 usw. steht (siehe Anhang)

Frage: Ist dies nur ein tolerierbarer kosmetischer Fehler durch das booten von Windows 10 mit Opencore oder steckt da doch ein größerer Fehler in der Konfiguration von OC dahinter?

Wie kann man das beheben?

_OSI Einträge wären eingefügt..

Wie gesagt läuft alles sauber und stabil und ohne Probleme..., aber nerft trotzdem..

PS: Was haltet ihr von ReFind als Bootmanager vor OpenCore als Bootloader gesetzt, das würde das Problem ja auch beheben..

Alles anzeigen

Ich zitiere entgegen meiner üblichen Gepflogenheiten ausnahmsweise mal den gesamten Beitrag einfach weil er in der Diskussion zu dem anderen Thema in diesem Thread untergegangen ist und nun irgendwo gefühlte zwei Seiten weiter vorne verwaist dasteht und vermutlich niemand mehr einen Zusammenhang zusammenbringt wenn ich jetzt auf die eigentliche Fragestellung eingehe

Harry69 das was Du beobachtest hat nichts mit dem ACPI bzw. der _OSI Methode zu tun sondern hängt mit dem SMBIOS (System Management Bios Spezifikation) zusammen und der Art und Weise wie OpenCore diese Spezifikation interpretiert. Das Betriebssystem bezieht die Informationen darüber auf welcher Plattform es läuft via DMI (Desktop Management Interface) aus dem SMBIOS. Im SMBIOS sind vom Hersteller des Mainboards bzw. vom Zulieferer der Firmware unter anderem Informationen wie der Name des Mainboards, die Versionsnummer des eingesetzten Chipsatzes und die Hardware UUID abgelegt wobei diese Werte in der Regel nicht durch den Benutzer änderbar sind und somit zumindest in der Theorie jedem Mainboard einen einmaligen Fingerabdruck verpassen. Open Core sitzt als Mittler zwischen der Firmware des Rechners auf der einen und dem Betriebssystem auf der anderen Seite und nimmt in dieser Position einige zum Teil tiefgreifende Änderungen an bestimmten Daten vor um eine relative macOS Kompatibilität zu erreichen. Eine dieser Änderungen betrifft auch das SMBIOS bzw. eben die Informationen welche über die Hardware an das Betriebssystem via DMI übergeben werden. Je nach Einstellung überschreibt OpenCore die vom Hersteller bereitgestellten Informationen mit solchen die macOS kompatibel sind um einen Start von macOS überhaupt erst zu ermöglichen. Auch wenn es eigentlich kein Problem ist das Windows hier ein Mac untergeschoben wird mag es den einen oder andern vielleicht stören bzw. mag es sogar sein das Windows seine Aktivierung vergisst (passiert gerne wenn Windows via SLIC aus der Firmware aktiviert wurde und nun die Informationen nicht mehr zu der SLIC Aktivierung passen). Für diese Fälle kann man OpenCore so definieren das sich die Änderungen am SMBIOS nicht global auswirken sondern sich auf macOS beschränken. Erreicht wird das wie folgt:

1. Im Bereich Kernel -> Quirks wird der Quirk CustomSMBIOSGuid auf enabled (Boolean Wert true) gesetzt

2. Im Bereich PlattformInfo wird für den Key UpdateSMBIOSMode der Wert aufCustom gesetzt

Ist beides erledigt wird die config.plist gespeichert und nach einem reboot steht das Apple SMBIOS nur noch für macOS zur Verfügung alle anderen Betriebssysteme werden wieder mit den Werten versorgt die sie über das DMI aus dem SMBIOS des Boards auslesen können. Einmal richitg eingestellt verhält sich die Kiste auch so wie man es erwarten würde und das ganz ohne abstruse Chainloader Konstrukte über reFind oder ähnliche Stunts

cobanramo warum sollte ich unter Misc->Entries-> 0 den Pfad auf EFI->Microsoft.....angeben.

Ist das wegen der externen Installations Mediensammlung?

Bei mir steht dort kein einziger Eintrag, und ich kann trotzdem ganz normal Windows über den OpenCore Bootloader starten.

Was bringt es also wenn dort ein Eintrag zu Windows gemacht wird?

griven Selten so einen kompetenten auf den Punkt gebrachten Lösungsvorschlag mit kurzer Erklärung gesehen.

Was soll ich sagen. Zwei Tage Zeit vergeudet um nach OC und Apple kompatiblen Bootmanagern zu suchen weil mich das extrem genervt hatte.

Nun zwei Variablen innerhalb von einer Minute geändert und es funktioniert alles wie es soll.

Ein ganz dickes Daumen hoch..

Ohne diesen Eintrag wird Windows gescannt und "links" vor den MacOs dargestellt, mit dem Eintrag sind es "rechts" nach dem MacOs. Ist für mich nur was visuelles, mit dem Eintrag kann ich so wie ich es gerne hätte den Position sowie Label bestimmen. Mehr nicht.

Externe & gescannte Einträge füllen die "linke" Seite des Bildschirms. Siehe Bild oben.

Gruss Coban

griven vielen Dank für die Tipps. Da muss man erst mal drauf kommen.

Habe eben die Dokumentation gelesen.

Bei CustomSMBIOSGuid steht folgender Hinweis für Enabled

Normalerweise relevant für Dell-Laptops"

Bei UpdateSMBIOSMode steht folgender Hinweis für Custom

Hinweis: Ein Nebeneffekt bei der Verwendung des benutzerdefinierten Ansatzes besteht darin, dass SMBIOS-Updates exklusiv für macOS verfügbar sind, wodurch eine Kollision mit der vorhandenen Windows-Aktivierung und der benutzerdefinierten OEM-Software vermieden wird, möglicherweise jedoch Apple-spezifische Tools beschädigt werden.

Der letzte Hinweis mit den Apple-Tools gibt zu denken. Was genau kann da beschädigt werden?

Mir ist da bisher keines untergekommen und gerade auf dem Hackintosh hat das meiner Meinung nach auch keine wirkliche Relevanz. Der Kernel Quirk sorgt dafür das der Aufruf für über das DMI auf eine andere Adresse gebogen wird als die an der diese Informationen üblicherweise zur Verfügung stehen der Eintrag unter PlattformInfo sorgt dafür das OpenCore die Informationen auch an der Stelle zur Verfügung stellt. Wenn also irgendwelche Tools davon beeinflusst werden sollten dann nur solche die am Kernel vorbei auf die Informationen zugreifen und von denen wird es nicht besonders viele geben die für uns eine Relevanz hätten. Anders sieht das freilich aus wenn man OpenCore auf echter Apple Hardware verwendet hier sollte man dann von solchen Stunts vermutlich eher Abstand halten (mir fällt da zum Beispiel der EFI Firmware Updater ein der auf die Idee kommen könnte anhand der „falschen“ Informationen eine falsche Firmware auf die Kiste zu basteln).

griven vielen Dank für die schnelle Antwort

Denke da geht es um Treiber aus BootCamp, setzt ja einen echten Mac normalerweise voraus.