Beiträge von INTOIT

    Ja ok interessant , aber wie bekomme dann das frisch installierte System von einem SATA-Volumen auf die NVMe, auf der ich ja das "alte" System am laufen habe und das "neue" haben möchte?


    Bisher habe ich von meinem System ein Time Machine Backup gemacht, dann das neue OSX via USB Stick auf den NVMe gespielt und dann die Benutzerdaten und Programme vom Time Machine Backup migriert.

    Hat immer tadellos funktioniert.


    Ich probiere morgen interessehalber, ob es vielleicht mit Monterey funkioniert.


    Danke und Gruß

    apfel-baum

    Ich habe die Änderungen eingefügt, leider keine Änderung.

    Willst du updaten oder neu installieren? Weil du oben updaten schreibst und für ein Update braucht man ja kein bootbares Installationsmedium.

    Womit ist der Stick erstellt? Ich habs ständig dass die Bootsticks nach dem Erstellen nicht funktionieren weil beim runterladen irgendwas schief ging, oder beim erstellen des Sticks.

    Ich möchte neu installieren, updaten war eher umgangssprachlich gemeint. Ich habe den Stick mittels Terminal Befehl erstellt, aus Big Sur heraus. Ich probiere jetzt auch mal AnymacOS aus.


    -> Ist es normal wenn auf dem Installations Stick eine Menge Dateien liegen? bei vorhergehenden Installation war da immer nur "macOS .... installieren" zu sehen.


    Guten Abend und ein Frohes Neues!


    ich möchte mein iMacPro System von Big Sur auf Ventura updaten.

    OC habe ich im ersten Schritt auf 0.8.7 aktualisiert, läuft bisher ohne Probleme unter Big Sur.


    Die Erstellung des VENTURA Installations Stick lief problemlos, Ich habe ihn auf meinem MacBook getestet und er startet.

    Aktualisierte OC Efi ist installiert. Ich habe den Installations Stick als Startvolume im BIOS ausgewählt.


    Was ich nicht verstehe ist, warum im Picker nur das Efi Volume und nicht dass Ventura Installation Volume angezeigt wird.


    Kennt ihr vielleicht das Problem und kann mir jemand einen Tipp geben? Ich habe meine Efi angehängt.


    Danke und Gruß

    Dateien

    • config.plist

      (32,96 kB, 64 Mal heruntergeladen, zuletzt: )

    Hallo Zusammen,


    ich habe eben das Update auf OC 0.8.7 auf meinem iMacPro1,1 erfolgreich durchgeführt und bin unter UEFI/Drivers auf OpenVariableRuntimeDxe.efi LOAD EARLY gestoßen.


    Soweit ich recherchieren konnte ist dieser Driver nur notwendig, wenn der NV Ram nicht nativ läuft.

    Ich habe den Treiber jetzt nicht Enabled, da ich ja unter ACPI die SSDT-PMC.aml lade.


    Dazu würde ich gern wissen, ob sich das eine oder andere ausschließt? Und wenn nicht ob beides geladen werden kann oder es ggf. besser ist für die Zukunft auf OpenVariableRuntimeDxe.efi LOAD EARLY zu aktivieren?


    Danke im Voraus!


    (Ps: All die Arbeit diehnt der Vorbereitung für das System-Update von BIG SUR auf VENTURA)

    Ich hatte jetzt eine ähnliche Situation, und zwar habe ich einen Sierra Installations Stick von meinem Big Sur System aus erstellen wollen. Big Sur hat mich auch darauf hingewiesen, dass das Betriebssystem auf meinem Mac nicht ausgeführt werden kann, mit Tinu allerdings konnte ich macOS Sierra installieren.app ohne Probleme auf den Stick spielen. Im Gegensatz dazu hatte ich Probleme das über den Terminal zu machen.


    Hier noch eine Alternative:

    Hier wird beschrieben wie du aus dem InstallOS.dmg einen Stick erstellen kannst. LINK

    Bild Quelle: Gigabyte


    • OpenCore 0.7.0

    • Motherboard - GA - H77 - ds3h Rev 1.1

    • F10 Biosmod für NVME support

    • CPU - Intel Core i5 3570K 3,4 GHz

    • GIGABYTE Nvidia GeForce GTX 770 OC & Intel HD4000 Graphics (Internal Graphics enabled)

    • RAM - 16 GB RAM DDR3 1600 MHz

    • Festplatte - NVMe Samsung SSD970EVO PLUS 500GB via NVMe PCIe x16 Adapter,

    • Audio Device - Realtek ALC888B, Nvidia HDMI

    • Wifi & BT: MQUPIN fenvi T919 Wireless Karte, BCM94360CD WiFi & BT4.0, PCIE karte

    • SMBIOS iMac 15,1 - SM BIOS ist gelöscht, das müsste Ihr individuell eintragen!

    • macOS Version - Mojave, Catalina, BigSur getestet

    • Audio, Wlan, Bluetooth, Ethernet, USB2 und USB3 läuft

    • sleep wake funktioniert auch, danke grt

    grt

    Das ist die Lösung!!!

    Stark, jetzt funktioniert alles wie es soll... sehr cool!


    Danke für die Unterstützung :feuerwerk::groesten:


    Ps: die Methode ist _PRW und der Pfad ist _SB.PCI0.GLAN


    weisst du, wie die methode im glan-device in der dsdt heisst?

    für den fall, dass sie _PRW heisst, und der pfad _SB.PCI0.GLAN

    trägst du unter acpi -> patch folgendes ein:

    Danke für das Feedback, sehr erhellend!

    Das bestätigt auch meine eigenen bisherigen Erfahrungen! Da bin ich ja beruhigt :)


    Ich für meinen Teil mache regelmäßig EFI und Systembackups von MacOS über Time Machine. Mit Windows bin ich tatsächlich etwas unsicher... Ich nutze das Systemabbild von Windows10, hatte aber zum Glück (oder leider) noch keine Gelegenheit zu Testen ob das zuverlässig funktioniert. Ich werde es wahrscheinlich irgendwann erfahren, Früher oder Später!

    Hallo Zusammen,


    das ist jetzt mal eine allgemeine Frage zum Thema Dual Boot (macOS und Windows), denn aus diverse Richtungen, die ich hier nicht nennen möchte, bekam ich die Aussage, dass eine Windows Installation auf einem Hackintosh irgendwann zu einem Datenverlust führen wird, unabhängig davon ob man Windows und macOS auf separaten Festplatten installiert ist. Ich selbst habe diese Erfahrung bisher noch nicht gemacht und nutze beide Betriebssysteme regelmäßig seit Jahren.


    Ist diese Aussage gerechtfertigt und kann man sich vor so einer Situation schützen?


    Ich freue mich auf eure Erfahrungen und Einschätzungen.

    Danke und Gruß!

    da brauchts einen rename einer methode im device glan (acpi / patches find, replace). p..irgendwas heisst die. bin leider am handy ...

    Hallo grt

    in einem weiter oben liegenden Post hast du geschrieben, das du das Sleep Problem des H77 Boards mit einem Rename in den Griff bekommen hast...

    Könntest du noch einmal schauen, wenn du wieder am Rechner bist, mit welchen Rename du das gemacht hast?


    Alle weiteren Vorschläge des Threads habe ich durchgearbeitet, leider ohne Erfolg bisher.


    Danke Und Gruß

    Der USB der BCRM ist als intern definiert, ich habe probehalber einen zweiten USBMap.kext angelegt, mit einer anderen Steck Variation der Gehäuse USB Anschlüsse und der Bluetooth Karten USB Verbindung. - Ohne Erfolg.


    GPRW/UPRW/LANC Instant Wake Patch

    Code
    1. pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

    Ergebnis ist: Wake [CDNVA] due to GLAN: Using AC


    Entsprechend den Hinweisen in der Anleitung habe ich WakeOnLAN überprüft, war aber deaktiviert.


    -> If WOL wasn't the issue, you can try the below patches


    Ich habe dann noch alle Patches getestet, GPRW/UPRW/LANC, auch das hat keine Veränderung gebracht.


    An der Stelle bin ich jetzt stecken geblieben, falls noch jemand einen Tipp hat freue ich mich sehr!

    Ich werde das Thema auf jeden Fall weiter im Blick behalten und für den Fall dass ich eine Lösung finde hier veröffentlichen.


    Soweit mit großen Dank!