OpenCore startet funktionierende EFI nicht mehr - ist das Board hin ?

    Hallo zusammen,


    ich mache mal ein neues Thema auf... Und zwar war ich die letzten Tage am Feintuning meiner x79/C602 Konfiguration gewesen und hatte es fast geschafft. Dann hatte ich aber das Problem, dass ich immer 2-3 Mal die Meldung "OCB StartImage Failure - Aborted" bekomme, bevor der Bootvorgang durchlief.
    Nun wollte ich wieder zu meiner "funktionierenden" EFI auf Big Sur zurück und habe das Problem, dass ich das selbe Phänomen nun mit dieser EFI auch habe. Und jetzt bootet das System nur noch alle 15-30 Male... Hab schon drei verschiedene USB Sticks und SSDs getestet sowie BIOS Reset (Batterie war draussen) und leider keine Besserung... Es wird eher schlimmer!
    Kann es sein, dass mein Board bzw. der NVRAM warum auch immer zerschossen wurde ? Windows bootet jedoch immer fröhlich ins System.


    Die EFI 0.6.7 liegt im folgenden Eintrag:
    Huananzi x79 Dual CPU C602 Board & DDR3 RAM - Hackintosh Monterey 12.0/Windows 11 DevBeta mit OpenCore 0.7.0

    Habe vorhin auch eine komplett neue EFI auf 0.7.0 Basis erstellt. -keine Besserung Irgendwie habe ich ein sehr ungutes Gefühl.

    taube111111 ,

    meinst du bei bzw. mit den unterschiedlichen usb-sticks auch unterschiedliche betriebssysteme ala *nux oder win-pe, diagnose-sticks, oder waren das alles osx-sachen?

    Um auszuschließen, dass es nicht an einem physichen Speichermedium liegt, habe ich nur OC auf den Sticks mit den verschiedenen SSDs getestet. Auf den SSDs ist jeweils BigSur von dem ich weiß, dass es funktionieren müsste. Die Windows-SSD hatte ich zum testen einmal rangesteckt und über OC gestartet.

    ok, wäre sonst eine option um zu testen ob das board himmelt oder nicht

    Stimmt, das wäre noch ein Option. -Danke! Hättest du einen Vorschlag für eine Hardwarediagnose ?

    meinst du eine iso für den stick, oder fernmündlich ob dein board himmelt?

    als iso z.b. die in meiner signatur verlinkte oder die ubcd sind linux basiert, ansonsten kannst du dir ggf. -für die zukunft- mit ein wenig frickelei auch selbst eine auf win pe basis zusammenstellen - das hier als "basis"-seite http://win10se.cwcodes.net/Compressed/index.php bzw- http://win10se.cwcodes.net/


    lg :)

    Für ein eigenes WinPE empfehle ich dies: https://www.tenforums.com/soft…our-own-rescue-media.html

    Ich meinte schon eine iso für den Stick :D Aber eine zweite/dritte/fünte Meinung ist mir immer Willkommen ^^
    Ist nehme mal die ubcd -Danke!

    Wenn das Problem nur bei boot von macOS auftritt kann es schon an NVRAM Einträgen liegen denn je nachdem unter welcher GUID die liegen beeinflussen die eben auch nur macOS und kein anders OS und während macOS den Dienst verweigert startet in dem Fall alles andere fröhlich weiter. Wenn es das wäre wäre dem Problem mit einem NVRAM Reset einfach beizukommen denn damit wäre zumindest zunächst erstmal alles wieder auf Anfang gesetzt ;)

    Haswell, Notebook

    Das habe ich nach jeder Änderung im BIOS oder an einer Test-EFI gemacht. Mal bootet er- mal nicht. Habe auch den Stick erstellt, werde nachher mal die Hardware durchtesten. Nachdem gestern meine bessere Hälfte einen Hardwareschaden am Bein (ausgelöst durch Pferdetritt) hatte, musste dort schleunigst an der Kühlung gearbeitet werden. Um das System dann möglichst ruhig und stabil laufen zu lassen bin ich vom Pusten auf Wassereis umgestiegen. Kann ich nur empfehlen ^^

    Lade mal deine aktuelle EFI hoch. Du hast ja daran noch viel gearbeitet. Vielleicht fällt mir etwas auf.

    Zitat von taube111111

    Die EFI 0.6.7 liegt im folgenden Eintrag:
    Huananzi x79 Dual CPU C602 Board & DDR3 RAM - Hackintosh Monterey 12.0/Windows 11 DevBeta mit OpenCore 0.7.0

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    Ich würde sagen, dass ich die höchste Chanche auf einen erfolgreichen Boot in der Ursprungs-EFI liegt.

    Bei den letzten 20 Starts war etwa jeder 5. Erfolgreich.Allerdings auch zwischendurch 2x direkt hintereinander.

    Jedes Mal wurde ein NVRAM reset gemacht.

    apfelnico: du kannst sie dir aber sehr gerne anschauen.

    Bin gerade schon am schauen, was es sonst an Alternativen so gibt. Macht es Sinn in ein neues Board zu investieren ? Wäre dann natürlich immer noch x79 aber die 8Core CPU mit 32GB RAM würde ich gerne übernehmen.

    Oder macht für die Radeon VII ggf eine andere Kombi mit DDR4 und neuerer Architektur ggf mehr Sinn ?

    Es ist halt ein ChinaBoard, da will ich nicht ausschließen, dass das vllt einen Schuss weg hat.

    Ich versuche später mal die CPU und den RAM auf dem noch freien Sockel laufen zu lassen.

    Schade wenn dein Board jetzt hinüber wäre! Hat die v1 Version schon Postcodes?sollte dem so sein, mal checken.


    Upgrade geht immer, hängt aber wie immer von deinem Budget ab. Ein Ersatz Mobo wäre aber auch locker drin. Gibt ja nicht nur huananzi und in der Ferne nicht nur x79.


    viel Erfolg!


    |Asus Z270 rog strix i|7700k|32gb |Vega 64 Liquid|Sonoma {OC}
    |Asus Z370 rog strix i|8700k|32gb |Vega Frontier Liquid | Sonoma {OC}

    |Asrock Z490 phantom gaming itx/tb3|i9 10850K|32gb|RX 6800XT|Sonoma {OC}/Win 11 Pro
    |Asus Zenbook UX3410UA macOS Ventura{OC}|MacBook Pro mid 2009| 10.6.8& 10.15

    |Macbook 4.1 |10.6.8 & ELIVE OS

    |MacBook Air M1 13'2020

    Wenn das Board nen Schuss hätte würde es vermutlich gar nicht mehr booten...


    Der Fehler liegt in der KASLR begründet zumindest ist das das typische Verhalten wenn es nicht genügend Slide Werte gibt um den Kernel zu entpacken. KASLR steht ja für Kernel Adress Space Layout Randomization wobei Randomization hier der springende Punkt ist. Die Adresse wird bei jedem Systemstart um einen zufälligen (random) Offset verschoben wobei ausgehend von diesem Offset dann halt genügend zusammenhängender freier Speicher verfügbar sein muss um den Kernel zu entpacken. Gerade bei X-Serie Mainboards ist aber genau das oft ein Problem. Ich kenne Deine EFI jetzt nicht taube111111 aber check mal ob Du unter dem Punkt Booter -> Quirks die Option ProvideCustomSlide auf true gesetzt hast und falls nicht mach das mal. Zudem verwende mal eine Debug Version von OC und stell Dir unter Misc -> Debug das Target auf 67. Die Debug Version liefert Dir ab jetzt ein log file auf die EFI Partition in Diesem findest Du unter anderem auch einige Informationen zu den nutzbaren Slide Werte und ggf. auch einen Hinweis darauf ob der Bereich aus dem die Offsets stammen dürfen begrenzt werden sollte (ProvideMaxSlide). Ich denke auf die Weise werden wir uns dem Problem am ehesten auf logische Weise nähern.

    Haswell, Notebook

    griven : Ich glaube das ist die richtige Fährte... :-) Vielen Dank schonmal für den Input!


    Habe den Quirk gesetzt (war auf NO) - hat nicht gefunzt

    Mal daraus inspiriert, folgenden Absatz im Guide gelesen:
    https://dortania.github.io/Ope…/kaslr-fix.html#test-boot


    Bin gerade nur zu blöd einen Slide wert zu errechnen. Komme auf 2038 (größer als 256) und weiß nicht ganz was mit dem zweit höchsten Wert gemeint ist...


    Mit slide=0 komme ich zum Patchen der BootKernelExtensions, bricht dann aber ab.


    PS: Hab nun an der EFI weitergearbeitet und die extrahierten SSDTs aus dem Hauptpost integriert.

    Dateien

    • EFI + LOG.zip

      (10,15 MB, 46 Mal heruntergeladen, zuletzt: )

    Einmal editiert, zuletzt von taube111111 ()

    Ich habe mal das Log studiert und dabei ist mir folgendes ins Auge gesprungen:

    Code
    1. 07:237 00:000 OC: Plist System\Library\Extensions\X86PlatformPlugin.kext\Contents\Info.plist is missing for forced kext System\Library\Extensions\X86PlatformPlugin.kext ()
    2. 07:319 00:081 OC: Failed to fit 64-bit kext X79X86PlatformPlugin.kext () - Invalid Parameter
    3. 07:324 00:005 OC: Kext reservation size info 589000 exe 30F000

    Hier stimmt also schon mal was nicht was dazu führen dürfte das das erzwungene laden von X86PlatformPlugin mit einiger Sicherheit nicht klappen dürfte und möglicherweise generell auch zu Problemen führt. Soweit ich das verstehe wird das landen von X86PlatformPlugin erzwungen damit die X79X86PlatformPlugin.kext greift und der gesamte Klimmzug wird vollführt um den MSR2 Lock zu umgehen (Kernelpanik ausgelöst von AppleIntelPowerManagement.kext) richtig? Falls dem so sein sollte sollte es doch eigentlich reichen unter Kernel -> Quirks die Optionen AppleCpuPmCfgLock und AppleXcpmCfgLock jeweils auf true zu setzen denn die kümmern sich um den MSR-2 Lock und ermöglichen es das AppleIntelPowerManagement.kext korrekt geladen wird und arbeitet ( -> Fehlerquelle weniger). Als nächstes fällt auf das Du Audio.dxe zwar lädst aber nicht richtig konfigurierst (ist zwar Makulatur aber wenn es eh nicht geht muss man es auch nicht laden)...

    Code
    1. 03:485 00:181 OCAU: PlayFile has no AudioIo or provider is unconfigured
    2. 03:713 00:227 OCAU: PlayFile has no AudioIo or provider is unconfigured
    3. 03:715 00:002 OCAU: PlayFile has no AudioIo or provider is unconfigured
    4. 03:716 00:000 OCAU: PlayFile has no AudioIo or provider is unconfigured
    5. 03:716 00:000 OCAU: PlayFile has no AudioIo or provider is unconfigured
    6. 03:717 00:000 OCAU: PlayFile has no AudioIo or provider is unconfigured

    Ich habe die config mal ein wenig angepasst schau mal ob es damit weiter geht: config.plist

    Haswell, Notebook

    griven:
    Danke für die Mühe, habe aber das gleiche Fehlerbild mit der Config.
    Habe einmal mit und ohne slide=0 getestet.


    Hier sind wieder die logs:
    Nach dem patchen des Kernels ist leider Ende.


    Ich schaue später die logs auch mal genauer durch.

    Ohne Slide ist aber nicht ohne denn Du gibst ja mit slide=180 einen Wert vor...

    Haswell, Notebook

    Moooooooooment, wird da ohne Slide=X ein random Slide Wert erzeugt ?

    Je nach Boot hatte ich mal 180 mal 224 oder 195, wenn er nicht fest via Bootarg definiert ist

    Korrekt ohne wird ein Zufallswert erzeugt und genau das ist ja auch der Sinn der Sache. Der Adress Space des Kernels soll ja gerade bei jedem Boot um einen zufälligen Wert (Offset) verschoben werden. Der Parameter Slide=XX gibt hebelt genau diesen Zufall aber aus indem er einen festen Offset vorgibt (Slide = 0 wäre kein Offset und damit gleichbedeutend mit KASLR Fehlanzeige). Wenn Du auf den Parameter verzichtest und OC machen lässt (provide cutom slide Quirk ist eingeschaltet) ermittelt OC im Vorfeld welche Offsets in Frage kommen und erzeugt aus diesem Pool einen zufälligen Wert was die Chance auf einen erfolgreichen Boot erheblich erhöht.

    Haswell, Notebook