Suchergebnisse

karacho SIP ausschalten und das mit dem Kext Updater war bei mir unter Catalina hierfür nicht notwendig. Ganz normal mit sudo im Terminal hat bei mir ausgereicht.EDIT: Nein, SIP war bei mir offensichtlich schon deaktiviert EDIT 2: SIP ausschalten scheint (siehe Beitrag von Harper Lewis weiter unten) für Änderungen an /etc/fstab tatsächlich auch nicht nötig zu sein.

Den Mount-Befehl hab ich nicht probiert. Ich hab einfach "sudo nano /etc/fstab" gemacht und konnte dann problemlos die Volumes eintragen, die ich nicht automatisch gemountet haben will. Ich check aber nochmal, ob SIP bei mir vielleicht doch deaktiviert ist.Hier jedenfalls nochmal zusammengefasst, was man da einträgt:für ein NTFS-Volume:LABEL=VOLUMENAME none ntfs ro,noautofür ein HFS-Volume:LABEL=VOLUMENAME none hfs rw,noautofür ein APFS volumeLABEL=VOLUMENAME none apfs rw,noauto"VOLUMENAME" ist …

CMMChris Das mit SSDT-EC gilt dann so sicher auch für Clover? Wenn ich noch zwischen Mojave und Catalina hin und her wechsle, ist es aber kein Schaden, wenn die Datei einfach drin bleibt, oder?

Hi! Wenn ich versuche (eigentlich nur aus kosmetischen Gründen für die richtige Anzeige in den Systeminformationen unter PCI), den zweiten Ethernet-Anschluss meines Mainboards hier einzufügen, bootet der Rechner nicht und bringt diverse ACPI Errors und Exceptions.Mach ich dabei irgendwas falsch? Der Eintrag für die Onboard-Soundkarte (Realtek ALC1220-VB) macht ja auch keine Probleme. In Clover lässt sich der Ethernet-Anschluss auf dieselbe Weise völlig problemlos eintragen.Funktionieren tut der …

(Zitat von apfelnico)Perfekt, danke, so hat es funktioniert!

In meinem OpenCore-Bootmenü wird die Windows-Partition nicht angezeigt. Über Clover kann ich Windows dagegen problemlos booten und es taucht auch (auch wenn ich über OpenCore boote) in den Systemeinstellungen als Startvolume auf:Unter ScanPolicy ist folgendes aktiviert:FILE_SYSTEM_LOCKDEVICE_LOCKFS_APFSFS_HFSFS_NTFSFS_EXTDEVICE_SATADEVICE_SASEXDEVICE_SCSIDEVICE_NVMEDEVICE_USBWenn ich FILE_SYSTEM_LOCK abschalte, taucht Windows zwar auf (als "BOOTCAMP Windows"), aber das läuft dann aufs selbe raus…

karacho Sensationell, danke! So klappt es War zwar erst etwas verwirrt, welchen von den vier FS-Einträgen, die der map-Befehl zur Windows-SATA-SSD ausgespuckt hat, ich nehmen muss, aber es war gleich der richtige (der mit "HD(2,GPT" etc.)

plutect Einfach vom OpenCore-Menü oder vom Clover-Menü aus die UEFI-Shell ausführen und den Befehl "map" eingeben. Ich habe die korrekte Partition dann eben daran erkannt, dass es bei mir ja die SATA-SSD ist, und dass der Boot-Ordner sich wohl bei Windows normalerweise auf der zweiten Partition davon befindet.Den Pfad hab ich mir dann einfach aufgeschrieben und den Eintrag wie folgt angelegt:

Wenn ich meine config.plist direkt auf der EFI-Partition bearbeiten will, bekomme ich nach kurzer Zeit folgende Meldung:Wenn ich dann auf "Unlock" drücke, kommt folgendes:Ich muss die config.plist also immer z. B. auf den Schreibtisch kopieren, dort bearbeiten und dann wieder auf die EFI-Partition schieben. Ist das normal? Bei Clover ging das immer problemlos direkt auf der EFI-Partition.Das Problem tritt unabhängig davon auf, ob ich die Datei mit Xcode oder einem anderen Programm bearbeite. Bei…

karacho Nein, ist nicht gesperrt. Der Terminal-Befehl bringt leider auch keine Änderung.Ich kann immer exakt eine Änderung erfolgreich speichern, danach kommt die Meldung. Sobald die Datei auf dem Schreibtisch liegt, lässt sie sich problemlos bearbeiten.Wenn ich eine Textdatei auf die EFI-Partition ziehe und sie bearbeiten will, kommt sofort folgende Meldung:

Normalerweise mounte ich über ein Applescript (das aber quasi auch übers Terminal mountet), aber es macht keinen Unterschied, ob ich stattdessen über den Kext Updater oder Clover Configurator oder sonstiges mounte.Es betrifft jetzt übrigens auch die Clover-EFI-Partition. Kann das mit der aktivierten SIP zusammenhängen? locojens Genau, das ist offensichtlich exakt dasselbe Problem.

locojens Seit wann hast du das Problem? Mir ist es jetzt erst seit gestern, nach dem Update auf macOS 10.15.3 aufgefallen. Hab davor aber auch nur Clover benutzt. Wenn ich mit Clover boote, habe ich aber jetzt dasselbe Problem.

Über den nano-Editor im Terminal hat es bisher allerdings noch überhaupt keine Probleme mit dem Bearbeiten gegeben. Der speichert alles wie er soll. Aber das ist ja nicht Sinn der Sache, die config.plist damit zu bearbeiten.Die Berechtigungen stimmen auch. Alle Ordner und Dateien im EFI-Ordner (und auch der Ordner selbst) sind auf rwxrwxrwx.

Den PLIST Editor hab ich mir jetzt auch gekauft. Dass man damit soviel man will gleichzeitig in der Ansicht ein- und ausklappen kann, ist wirklich super. Ich finde auch die Häkchen statt "YES" oder "NO" bzw. true oder false recht praktisch. Wie dem auch sei, der Fehler taucht unabhängig vom Editor auf.Aber es ist mittlerweile tatsächlich der falsche Thread für das Thema, da sich ja jetzt herausgestellt hat, dass das unabhängig von OpenCore passiert.So, hier dafür noch was OpenCore-Betreffendes:I…

Ja, es wäre auch schlecht, wenn die Nummer gültig wäre. Die wäre dann schon auf einen vorhandenen echten Mac registriert.

karacho mhaeuser macdream Sn00py locojensDie Vermutung hat sich bestätigt. Die aktivierte SIP verursacht das Problem. Mit deaktivierter SIP gibt es kein Problem, da lässt sich alles wunderbar bearbeiten. Bei mir funktioniert die Deaktivierung der SIP über die OpenCore-config.plist mit dem Wert <E7030000> übrigens einwandfrei – ganz im Gegensatz zu dem Typ, der bei insanelymac was dazu schreibt. Das sieht bei mir dann so aus:"csrutil status" meldet im Terminal dann dementsprechend:EDIT: Und mit …

(Zitat von apfelnico)Jetzt bin ich etwas überfordert. Ich hab hier einmal eine ellenlangen Wert:<3c617272 61793e3c 64696374 3e3c6b65 793e494f 4d617463 683c2f6b 65793e3c 64696374 3e3c6b65 793e494f 50726f76 69646572 436c6173 733c2f6b 65793e3c 73747269 6e673e49 4f4d6564 69613c2f 73747269 6e673e3c 6b65793e 494f5072 6f706572 74794d61 7463683c 2f6b6579 3e3c6469 63743e3c 6b65793e 55554944 3c2f6b65 793e3c73 7472696e 673e4145 37453441 39322d30 4635352d 34304638 2d413241 322d4233 30454532 32323431 45463c2…

(Zitat von Download-Fritz)Genau hier liegt das Problem: Nach dem NVRAM-Reset findet der Rechner die EFI-Partitionen zunächst nicht (auch die von Clover nicht) und bootet deshalb Windows. Wenn es nur die OC-Partition beträfe, wäre in den Boot Option Priorities als zweites nämlich ne Clover-EFI-Partition drin, dann müsste er von dieser booten. Tut er aber auch nicht und nimmt stattdessen die Windows-Partition (die ich übrigens sogar aus den Boot Option Priorities entfernt habe).Nachdem Windows dan…

mhaeuser Aah, danke. OK. Dann scheint es Sinn zu ergeben. apfelnico Wenn ich den EFI-Ordner auf der Windows-EFI-Partition mit dem OpenCore-EFI-Ordner ersetze, bootet er nach dem NVRAM Reset dann auch wie erwartet über OpenCore. Ich könnte den Windows-EFI-Ordner dann entweder woanders ablegen (aber wer weiß, ob das bei Windows-Updates irgendwelche Probleme machen kann?) oder ich lebe eben damit, dass nach dem NVRAM-Reset kurz Windows hochfährt. Wenn es offensichtlich eh nicht nötig ist, das so o…

Ja, dachte ich mir schon fast. Aber das geht nicht, weil die Windows-Platte ne SATA-SSD ist und die Hackintosh-Platte eine PCIe NVMe. Aber durch Tauschen der Ordner konnte ich es zumindest kurz ausprobieren.