Theoriefrage: Kann Grub von OC beeinflusst werden fürs Gerät?

  • Mittlerweile arbeiten wir uns zu Dritt am alten Klapperkasten (Notebook) von eimem Freund ab, der unbedingt endlich einen Dualboot Mac-Linux haben will.

    Warum entweder das eine oder das andere klappt haben wir mittlerweile auch eingegrenzt: es scheint mit den einstellungen von Open Core (0.8.8) zusammen zu hängen.


    Jetzt frage ich mich: wenn Open Core mit openlinux.efi quasi den Weg frei machen soll:

    Kann OC tatsächlich den reinen Boot vorgang von Linux beeinflussen?

    Weil: wenn wir an den Häkchen in der confligplist rumspielen kann Linux zwar gebootet werden hat aber dann kein Wlan und macOS ist "leer".


    Bei Grub muss doch nix emuliert werden?

    Wenn der Grub doch nur grubx64.efi etc. an OC übergibt bzw. OC die sich holt warum gibt das denn dann mit der config.plist Probleme?


    Das ist jetzt mal ne Grundsatzfrage für uns 3.

    Weiß da jemand was Näheres zu? Ist jetzt reine Neugier für mich und vllt hilft ja eine Antwort beim Gesamtproblem.


    Hintergrund dazu hier.:



    Nachtrag: Wir haben als Installationsmedium für Linux eine Dvd im Laugwerk und die wird im OC menü nicht angezeigt obwohl auf dem Bootstick alle notwendigen Treiber sein sollten oder?

  • 6 Mal editiert, zuletzt von bluebyte () aus folgendem Grund: Verbindungsabbruch

  • Davon ab ist GRUB genau wie OC ein Booter und nicht mehr sprich GRUB hat keinen Einfluss darauf welche HW Linux erkennt oder eben auch nicht. Was aber einen Einfluss hat sind sämtliche Änderungen am ACPI in OpenCore denn OpenCore gibt alle Änderungen die gemacht werden (ACPI,SMBIOS usw.) an alle Systeme weiter unabhängig davon was gestartet werden soll :D


    Kurzes Beispiel: OC ändert das SMBIOS eines Rechners indem es die entsprechenden Felder im DMI überschreibt so wird dann zum Beispiel aus einem Thinkpad ein MacBook. Da OC zu dem Zeitpunkt an dem diese Änderungen vorgenommen werden noch gar keine Kenntnis davon hat welches OS Du gegebenenfalls starten möchtest wirkt sich die Änderung eben auf alle Systeme aus. Mit anderen Worten ein Linux das über OC startet denkt eben auch es läuft auf einem Mac (ein über OC gestartetes Windows im übrigen ebenfalls).


    Das Verhalten lässt sich ein wenig beeinflussen hierzu muss man sich aber die Mühe machen und sich in die OC Doku einlesen. Im Falle des SMBIOS reicht es unter Kernel->Quirks den Haken bei "CustomSMBIOSGuid" zu setzen und unter PlattformInfo den UpdateSMBIOSMode auf Custom zu stellen. Diese Einstellungen haben den Effekt das das Apple SMBIOS sich dann auch nur auf macOS auswirkt und für alle anderen Systeme bleibt die Kiste halt ein Lenovo, Acer WhatEver. Wo das mit dem SMBIOS jetzt noch recht einfach möglich ist braucht es bei den ACPI Sachen aber sauberes Arbeiten denn die werden tatsächlich immer angewendet. Das zu ACPI passende Stichwort ist in dem Fall _OSI hier muss wirklich peinlich genau darauf geachtet werden das alle Änderungen in den ACPI Dateien (DSDT, SSDT's) mittels _OSI Weiche nur für Darwin angewendet werden...

  • Da OC zu dem Zeitpunkt an dem diese Änderungen vorgenommen werden noch gar keine Kenntnis davon hat welches OS Du gegebenenfalls starten möchtest wirkt sich die Änderung eben auf alle Systeme aus. Mit anderen Worten ein Linux das über OC startet denkt eben auch es läuft auf einem Mac (ein über OC gestartetes Windows im übrigen ebenfalls).

    Ah,also doch!

    Irgendiw ekam mir das doch alles sehr seltsam vor aber das macht Sinn.

    Danke für die Info!


    Jetzt muss ich aber doch noch Mal nachfragen...

    Hätte Informatik studieren sollen ... Das ist ja ein vorbereitetes aml für kabylake im ACPI Ordner . Wenn das also der Grund ist und Linux darauf zurück greift. Könnte man das irgendwie dekompilieren und den Fehler finden?

    Oder noch einfacher:

    Wie schafft man es, dass Linux ohne den Ordner startet? :/

    Einmal editiert, zuletzt von EmilDeumel ()

  • Das kommt ja erstmal darauf an was in dem ACPI Ordner überhaupt enthalten ist sprich was da eingebunden wird und was nicht abhängig davon kann man dann gucken ob da Eingriffe notwendig sind oder nicht. Die Standart SSDT's die OpenCore mitliefert sind in der Regel darauf vorbereitet sprich da ist die entsprechende _OSI Weiche schon eingebaut...

  • @EmilDeumel Warum startet ihr OC + macOS nicht über Grub, so kann die config und den Ordner von OC sehr einfach gehalten werden.

    Hatte ich bei meinem Comet Lake System auch Win + Linux + OC/macOS alles über Grub, ist sehr einfach und eine sichere Nummer.

  • Das war auch mein Gedanke, Bob-Schmu weil mir der Bootrloader egal wär. Aber ich glaub wir hatten das auch am Anfang schon verscht ohne erfolg. Macht aber auch sinn weil der alte Kasten ohne dieses Oralirazeiug gar nicht upzugraden war. Da hatten wir echt Tage lang dran gewerklt. Weil Grub natürlich nicht die ACPI für den Hackintosh machen/lesen kann. Ich glaub daran lag's.


    Und du hast den richtigen Riecher gehabt griven . Es muss an dem Oralira hängen. Hab da grad nochmal vorbeigeschaut die schreiben da was von "OpencoreMOD" usw.

    Trotz miesem englisch versteh ich das so das diefür Multiboot offenbar was eigenes haben. Dann macht das natürlich Sinn wenns mit herkömmlicher Rangehenweise nicht geht.


    Leider hat das ja nicht so gut funktioniert wie mit meinem Asus und auch mit kräftiger Hilfe von OSX-Einsteiger gings nicht, da mussten wir die vorgefertigte EFI von Oralia nehmen.

    Aber immerhin wissen wir jetzt worans ungefähr liegt. :-)

  • Bob-Schmu meint sicherlich:


    GRUB->OC->macOS mit SSDTs und ggf. DSDT patched


    GRUB->Linux ohne jeglichen Einfluss von OC


    Nicht:

    GRUB->macOS


    Da brauchst du auch keinen extra Fork von OC oder sowas.

    Leg in deinen SSDTs halt Weichen an, wenn du ne tot gepatched DSDT benutzt kein Plan.


    Du kann Linux halt auch aus OC booten.


    Ich versteh so nicht wirklich das Problem hier.

  • Also irgendiwe ist diese ACPI Sache ja echt mysteriös.

    Wenn ich das richtig verstehe kann man auf diese ganzen DSDT dinge verzzichten, aber das ACPI beruht doch darauf? :/


    Wir haben jetzt diese Olarila AML rausgenommen und mit durch eigene ersetzt wie's hier auch beschrieben ist. Null Veränderung. Kumpel bootet Linux jetzt immer mit F12 durch das Bios. [wech]

    Diese ganzen AMLsachen haben anscheined dann doch keinen Einflus auf den Bottvorgang? :/


    Was ich bis jetzt verstanden habe: Diese ACPI tabellen braucht jedes OS und holt sie sich normalerweise selbst, aber wegen dem Spezialfall Apple muss OC das dafür bereitstellen - und alle anderen OS via OC holen sich die ACPI dann nicht wie sonst selbst sondern greifen auch in den ACPI-Ordner von OC?

    Habe ich das jetzt richtig verstanden? :/

  • EmilDeumel


    Zeigt doch mal eure EFI hier her :)

  • Habe ich das jetzt richtig verstanden?

    jein....


    alle anderen OS via OC holen sich die ACPI dann nicht wie sonst selbst sondern greifen auch in den ACPI-Ordner von OC

    das machen sie nur dann, wenn oc den bootvorgang angestossen hat. auch, wenn oc dann an grub oder windosendingens weitergeleitet hat. in dem fall werden die acpi-tabellen (gepatchte/bearbeitete dsdt.aml sowie die vorhandenen ssdt-irgendwas.aml) an den booter des anderen systems weitergereicht. ebenso wird ohne den oben von griven erwähnten haken (smbiosirgendwas) auch das "behauptete" macmodell mitgegeben, so dass das andere system mit dem läptop so umgeht, als wärs tatsächlich ein macbook.xyz. was auch zu verwirrungen führen kann...

    wenn das andere system per F12 mit seinem booter direkt gestartet wurde, dann bleiben die anpassungen von oc aussen vor.

    das weitergeben des fake-smbios an andere systeme lässt sich ja noch einfach umgehen, die ssdt-anpassungen sind hartnäckiger: da muss vereinfacht bei jeder anpassung dazugesagt werden: wenn (if ...) du dich auf einem macos wiederfindest { mach mal bitte folgendes..... *hier die manipulation beschreiben* }, wenn nicht { einfach bleiben lassen/ das hier ignorieren...}.

    oft läuft das auf umbenennungen (find/replace in der acpi-abteilung) einer originalen methode in kombination mit einer ssdt hinaus, deren inhalt dann (ganz grob!) in etwa so aussieht:

    methode BLA_originalername - wenn macos: mach dies/jenes/welches/. wenn nicht (aufruf der umbenannten originalmethode (BLA_umbenannt) mit originalem inhalt)

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • EmilDeumel


    Zeigt doch mal eure EFI hier her :)


    Ich pack hier mal die config rein, die ist kleiner. Wir ham keine negative Veränderung nach dem Auswechseln von dem orlaria-aml bemerkr.

    methode BLA_originalername - wenn macos: mach dies/jenes/welches/. wenn nicht (aufruf der umbenannten originalmethode (BLA_umbenannt) mit originalem inhalt)

    Aaahaaaa!

    Jetzt haben wir aber gesehen das bei Clover dafür aber eine Unterteilung gab in andere Ordner mit "original" und "patched"

    Warum gibts das denn nicht auch bei OC? Oder muss man diese Trennung selbst machen damits funktioniert? :/

  • bei Clover gibs ein Depot, in dem Clover die Original ACP abspeiern kann. Diese Funktion hat OC nicht

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

  • was mir da direkt ins auge springt: im normalfall brauchts für die SSDT-XOSI.aml doch den _OSI -> XOSI rename, damit die weiche greift? der ist aber nicht drin.


    EDITH:

    in clover/acpi/origin landen die originalen ungepatchten acpi-tabellen, wenn man beim cloverboot mit F4 die dateien "anfordert". in einem bereits gepatchten system kann man die originalen acpitabellen ja nun nicht mehr extrahieren, ubuntu (linux im allgemeinen) ist kein wirklich guter anlaufpunkt fürs ziehen der originalen tabellen, da kanns zu seltsamen fehlern kommen. eine extraktion der tabellen noch bevor irgendein system sich evtl. daran irgendwie vergriffen haben könnte ist einfach mal die sauberste sache. daher ist clover dafür mindestens noch sehr brauchbar ;-)

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • da müsste noch ein ordner patch in acpi sein? öhm... neee nicht ordner, sondern in der config in der abteilung acpi -> patch

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • bei Clover gibs ein Depot, in dem Clover die Original ACP abspeiern kann. Diese Funktion hat OC nicht

    korrigiere, OC Debug nehmen, Quirk „SysReport“ aktivieren und entsprechend konfigurieren (Target). Dann schreibt auch OC die Originale ACPI in den Ordner in dem OC liegt.


    Im Ordner „SysReport“

  • den Patch meint grt

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

  • ich würde ja das durcheinander in der kextabteilung mal gründlich ausmisten.. da stecken mehrere bluetooth-kexte drin, die sich eigentlich widersprechen (injector und, bluetool oder so) und auch noch in mehreren versionen, aktiv, mal dann doch nicht.. die voodoo...kext abteilung würde ich auch straffen, das kann echt fehler nach sich ziehen, wenn da gleich mal mehrere eingetragen sind.

    was der xhci-unsupported.kext macht, ist mir bislang verborgen geblieben. früher mal schien der in seltenen fällen bei exotischen controllern sowas wie die letzte möglichkeit gewesen zu sein, aber inzwischen behaupte ich mal dass man den getrost weglassen kann.

    der cardreader rennt auch nur, wenn sich beide kexte drum kümmern?

    utb/usbtoolbox wurden explizit für diesen läppi erstellt oder kommen die aus dem netz?

    ansonsten fällt mir erstmal nix weiter auf.

    die olarilassdt würde mich ja mal interessieren.. schieb die doch bitte mal hoch.

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr