OpenCore Sammelthread (Hilfe und Diskussion)

  • kaneske

    Dann würde ich empfehlen mal unter IORegistryExplorer nachzugucken ob auch die eingetragene UUID da auch auftaucht.


    Wenn nicht liegt ein unterschiedlicher Config vor, zbspl. wegen der Hardware ID durchreichen für´s Windows Aktivierung usw.

    Evtl. hast du da ja was konfiguriert.


    Gruss Coban

     MSI-B150M Mortar | Intel® Core™ i7-6700 Skylake | 64GB DDR4 RAM | Intel® HD Graphics 530 | Samsung NVMe 960 EVO / 1x2 TB HDD | BCM943602BAED DW1830 | OpenCore aktuell / macOS Catalina 10.15 / Windows 10 Pro / Ubuntu 20.04 LTS

     Lenovo S340-15IIL | Intel® Core™ i7-1065G7 IceLake | 12GB DDR4 RAM | Intel® Iris Plus Graphics G7 | Nvme Intel SSDPEKNW512G8L/SSD Samsung 256GB | BCM94360NG | OpenCore aktuell / macOS Catalina 10.15 / BigSur 11.0 / Win 10 Pro / Ubuntu 20.04 LTS


    " Chasch nöd s Föifi und s Weggli ha."

  • Danke für den Hinweis, sind alle 3 identisch.

  • cobanramo Dito... bei mir auch alle Identisch. Wenn ich die uuid im Terminal auslese, ist die nicht identisch mit dem was in der Hardware Übersicht drin steht, ist das normal?


    hackmac004 die MAC Adresse war bei mir schon vorhanden

  • Wie liest du den UUID im Terminal aus?

    Falls du den "uuidgen" meinst, das generiert einen neuen UUID.


    Eben wie gesagt wenn die;

    MLB,

    SystemProductName,

    SystemSerialNumber,

    SystemUUID,

    ROM,


    überall übereinstimmen sollte, wüsste ich nicht warum das probleme machen könnte...

    Bei mir tut´s was es soll.


    Was mir noch einfällt wäre doch zu kontrollieren ob man was unterschiedliches unter

    DataHub

    PlatformNVRAM

    SMBIOS

    eingetragen hat falls man diese Felder abgesehen vom "Generic" einsetzt.


    Gruss Coban

     MSI-B150M Mortar | Intel® Core™ i7-6700 Skylake | 64GB DDR4 RAM | Intel® HD Graphics 530 | Samsung NVMe 960 EVO / 1x2 TB HDD | BCM943602BAED DW1830 | OpenCore aktuell / macOS Catalina 10.15 / Windows 10 Pro / Ubuntu 20.04 LTS

     Lenovo S340-15IIL | Intel® Core™ i7-1065G7 IceLake | 12GB DDR4 RAM | Intel® Iris Plus Graphics G7 | Nvme Intel SSDPEKNW512G8L/SSD Samsung 256GB | BCM94360NG | OpenCore aktuell / macOS Catalina 10.15 / BigSur 11.0 / Win 10 Pro / Ubuntu 20.04 LTS


    " Chasch nöd s Föifi und s Weggli ha."

  • Habe ich verstanden. Meine Frage war aber die, warum Du auf jede eine separate EFI inkl. BL verteilst, wenn doch für Alles eine einzige reicht - egal, ob auf einer Platte oder - wie inzwischen von mir favorisiert, weil deutlich flexibler - einem Stick (natürlich zusätzlich zum Backup-Stick). Die Beweggründe dahinter würden mich schon interessieren.

    Du sorgst da u. U. für Verwirrung und solchen Auswirkungen wie von Dir beschrieben.

    was spricht gegen meherere EFI's auf mehreren Platten? Mache ich nicht anders und kann bei Bedarf aus dem BIOS booten.

    Das spart ein Bündel USB-Sticks

    Grüße

    Arkturus


    iMacPro1,1 Asus Prime B250M Plus, Intel QuadCore i5 7500 Kaby Lake 3,41 Ghz, PowerColor RX580 8192 MB VRAM, Realtek ALC888B (ID 1 (2)), Fenvi T919 , 16GB Ballistic Sport DDR4 2400, Mojave 10.14.6 ((18G3020) Clover r5119, BS 11.1 (20C5048k) OC 0.6.2

  • was spricht gegen ...

    Da könnte ich auch fragen: was spricht für ...? ;)

    Dass das zu Irritationen führen kann, kann man etwas weiter vorne nachlesen.


    Worin besteht der Vorteil von mehrfach verteilten BL-EFIs auf diverse Platten gegenüber einer einzigen EFI auf einer vorbestimmten Platte? Was passiert bei Änderungen? Muss ich dann umher "reisen"?


    Ich habe zwar ein Bündel Sticks, aber die beheimaten alle OS X bzw. macOS plus ihre gepatchten Ableger für die MP2.1 bzw. MP3.1. Da ich Installationsapp und BL eh schon lange getrennt halte, weil in meinen Augen generell sinnvoller, kann ich die bei den MP unterstützen OS so einstecken - kein BL kann stören.


    Dazu kommen bei mir die beiden BL-Sticks mit OC 065 bzw. Clover 5127 (noch nicht ganz fertig) plus ihre jeweiligen Kopien als Backup-Sticks, die Jeder haben sollte - egal ob von Platte oder Stick gebootet wird. Das war's auch schon. ;)


    Ich mit meiner Methode muss mich nicht mal um die Erreichbarkeit einer EFI auf einer eingebauten Platte kümmern. Änderungen passieren auf dem Stick, den ich dafür überall in andere Macs/Hackintoshs einhängen und bearbeiten kann.


    Letztlich ist es Jedermanns eigene Entscheidung. Ich mache es mir gerne übersichtlich und bequem. ;)

    Gruß

    LOM



  • Als Newbie damals bin ich schier verrückt geworden, als ich mehrere EFIs auf unterschiedlichen ESP gespeichert hatte und nicht mehr unterscheiden konnte, welche tatsächlich geladen wurde. Erst als ich den Unterschied zwischen ESP und EFI gelernt hatte, wurde es besser; und das auch erst, nachdem ich aus dem Dschungel der Clovereinstellungen herausgefunden hatte.

    Die Lösung mit den EFIs, die ausschließlich auf USB-Sticks gespeichert werden, finde ich sympathisch, werde aber meine EFI weiter auf einem festen Speichermedium vorhalten. Warum? Wahrscheinlich deshalb, weil ich zu faul bin, oder befürchte, dass ich bei einem Problem nicht mehr daran denke, dass die EFI hinten am Rechner eingesteckt ist und ich nach ihr suchen müsste.

    Die USB-Lösung halte ich insgesamt für empfehlenswert. Ebenso für empfehlenswert halte ich die Idee einen USB-Stick als Backup in der Schublade zu haben.

    iMac19,1: Big Sur, Windows10, BL: OpenCore v063, Mainboard: Gigabyte Designare, CPU: i7-9700K, Ram: 32Gb Corsair Vengeance LPX; Grafik: Sapphire RX5700 XT Nitro+ 8Gb, SSD: Samsung 970 NVME 500GB, Samsung 850 Evo 500Gb, HDD: Seagate ST3000DM001 3TB Wifi/Bluetooth: BCM94360CD Combo (oob), PSU: be quiet! Dark Power Pro11, Case: Jonsbo UMX4

  • Ein Frage mit Gegenfrage zu beantworten zählt nicht.


    für dezentrale Verwaltung spricht m.E. die unmittelbare Insatzfähigkeit. Ich habe die EFI,s für Linux und Windows auf deren SSD plaziert und dort liegen diese ungestört und sind direkt aus dem BIOS-Bootmenü erreichbar. Dann habe ich für macOS OC im Einsatz auf der System-NVMe, sowie zwei weitere auf der stillen Reserve 10.14.6, sowie als Backup der SystemNVMe auf der HDD von Time Machine.


    Das heißt ja nicht, dass innerhalb der EFI Partitionen noch weitere EFI's als Backup liegen, soweit der Platz das erlaubt. Diese sind immerhin erst bootbar, wenn sie in EFI umbenannt wurden. Mag sein, dass dieses im Notfall über die UEFI-Shell machbar ist. Aber die dafür erforderlichen Terminalbefehle kann ich mir nicht merken. Da müsste ich mir ein Handbuch anlegen, aber ich sehe für mich keinen Sinne darin, im Notfall mit einem Stick nur deshalb eine andere Möhre anzuschmeißen, nur weil ich trotz Gelegenheit keine andere bootbare EFI auf den reichlich vorhandenen GUID-Laufwerken liegen habe.


    Ich kann nicht erkennen, dass durch diese Arbeitsweise Nachteile bei der Konfiguration enstehen könnten.


    Nun hätte ich gerne gewusst, warum das der von Dir geübten Praxis zum Nachteil gereichen soll LuckyOldMan


    EDIT: Grundsätzlich habe ich für jede Möhre einen eigenen Notfallstick


    EDIT: Wer orientierungslos in der Hackintosh-Welt unterwegs ist, der mag sich eine Eselsbrücke bauen, z.B. einfach eine leere Datei im EFI-Verzeichnisbaum ablegen, welche eine Hinweis zum Ort gibt, z.B. im Dateinamen.

    Darin könnte man auch leicht wichtige Informationen als Logbuch, wer will.

    Grüße

    Arkturus


    iMacPro1,1 Asus Prime B250M Plus, Intel QuadCore i5 7500 Kaby Lake 3,41 Ghz, PowerColor RX580 8192 MB VRAM, Realtek ALC888B (ID 1 (2)), Fenvi T919 , 16GB Ballistic Sport DDR4 2400, Mojave 10.14.6 ((18G3020) Clover r5119, BS 11.1 (20C5048k) OC 0.6.2

  • Es gibt viele Ansätze, die alle ihre Vor- und Nachteile haben.

    Das wichtigste ist aber, dass man keinem Backup traut, dass man nicht selbst getestet hat. (Und ohne Backup, kein Mitleid!)

  • Ein Frage mit Gegenfrage zu beantworten zählt nicht.

    Habe ich nicht, denn ich habe mein Vorgehen erläutert und begründet. Das kann man übernehmen, weil man es nachvollzieht ... oder eben auch lassen. ;)

    Aufhänger dieser Thematik waren die Probleme, die Kollege schmalen hatte - es ist dazu Ausreichendes geschrieben worden und dabei möchte ich es für meinen Teil hier im Threads jetzt auch belassen.

    Wer weitere Fragen zu meinem Konzept hat (ist ja weniger ein OC-Thema), kann mich gerne anschreiben.


    Was Anderes:

    Bzgl. grafischem Menü bei OC habe ich den Schritt wieder zur Liste gemacht, weil ich dachte, dass das den Vorgang ab Einschalten und Bios-Zugang bis zum OC-Menü verlangsamte.

    Aber das scheint es nicht zu sein: es ist der Chime, der zumindest bei mir im Vergleich zum nicht-aktivierten Chime soviel Zeit kostet und nicht die Grafik.

    Hat Jemand ähnliche Erfahrung mit aktiviertem Chime?

    Gruß

    LOM



  • Hallo allerseits, bevor ich noch Wahnsinnig werde, frage ich euch:

    Auf meinem HacBook sind die Tasten ^ und < vertauscht:

    - zwischen der shift und der Y-Taste sollte < sein, es ist aber ^ und

    - links neben der 1 sollte es ^ sein, ist aber <


    Eigentlich müsste in der Config alles richtig sein, aber es will einfach nicht! Ich habe nun de:3 und de:253 ausprobiert - natürlich jedes mal mit NVRAM Reset, nichts! Was mache ich falsch? Woran könnte es liegen?

    Code
    1. <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
    2. <dict>
    3. ...
    4. <key>prev-lang:kbd</key>
    5. <string>de:253</string>
  • pebbly


    Weiß nicht, ob ich dich richtig verstehe, aber unter Systemeinstellungen/Tastatur/Sondertasten kannst du Einstellungen vornehmen.


  •  MSI-B150M Mortar | Intel® Core™ i7-6700 Skylake | 64GB DDR4 RAM | Intel® HD Graphics 530 | Samsung NVMe 960 EVO / 1x2 TB HDD | BCM943602BAED DW1830 | OpenCore aktuell / macOS Catalina 10.15 / Windows 10 Pro / Ubuntu 20.04 LTS

     Lenovo S340-15IIL | Intel® Core™ i7-1065G7 IceLake | 12GB DDR4 RAM | Intel® Iris Plus Graphics G7 | Nvme Intel SSDPEKNW512G8L/SSD Samsung 256GB | BCM94360NG | OpenCore aktuell / macOS Catalina 10.15 / BigSur 11.0 / Win 10 Pro / Ubuntu 20.04 LTS


    " Chasch nöd s Föifi und s Weggli ha."

  • .....

    Bzgl. grafischem Menü bei OC habe ich den Schritt wieder zur Liste gemacht, weil ich dachte, dass das den Vorgang ab Einschalten und Bios-Zugang bis zum OC-Menü verlangsamte.

    Aber das scheint es nicht zu sein: es ist der Chime, der zumindest bei mir im Vergleich zum nicht-aktivierten Chime soviel Zeit kostet und nicht die Grafik.

    Hat Jemand ähnliche Erfahrung mit aktiviertem Chime?

    das Aktivieren von Playchime hat bei mir keine messbaren oder gefühlten Veränderungen in der Performance. Weder auf den Möhren wo es funktioniert (T430; T460), noch wo nicht (den beiden iMacPro1,1 (HW; KBL)

    Grüße

    Arkturus


    iMacPro1,1 Asus Prime B250M Plus, Intel QuadCore i5 7500 Kaby Lake 3,41 Ghz, PowerColor RX580 8192 MB VRAM, Realtek ALC888B (ID 1 (2)), Fenvi T919 , 16GB Ballistic Sport DDR4 2400, Mojave 10.14.6 ((18G3020) Clover r5119, BS 11.1 (20C5048k) OC 0.6.2

  • n'Abend zusammen,


    ich habe noch immer keine Lösung gefunden wie man die Namen im OC (0.6.4) Bootpicker (OpenCanopy) ändert, bzw. wie diese korrekt angezeigt werden. Ich nutze eine NVMe mit BigSur als Produktivsystem sowie eine SSD als Backup, tägliche CCC Sicherung. Die NVME heißt "BigSur_NVMe" die SSD entsprechend BigSur_SSD. Im Bootpicker haben aber beide dasselbe Icon und denselben Namen nämlich "BigSur-NVMe". Wie kann dieser Name angepasst werden? Umbenennung im Disk Utility bringt keine Änderung...



    Grüße, MacDream

  • wenn du die Sicherung in „Big Sur_CCC“

    umbenennst, also im CCC

    Grüße

    Arkturus


    iMacPro1,1 Asus Prime B250M Plus, Intel QuadCore i5 7500 Kaby Lake 3,41 Ghz, PowerColor RX580 8192 MB VRAM, Realtek ALC888B (ID 1 (2)), Fenvi T919 , 16GB Ballistic Sport DDR4 2400, Mojave 10.14.6 ((18G3020) Clover r5119, BS 11.1 (20C5048k) OC 0.6.2

  • macdream


    Im Terminal folgenden Befehl ausführen sudo diskutil apfs updatePreboot / könnte helfen.

  • LetsGo leider nicht. Es muss um das Tastaturlayout von OC gehen, in den Einstellungen ist es als De qwertz richtig eingetragen - auch das neue identifizieren mittels Shift + rechte Taste daneben hat nichts gebracht.