dreamwhite

My bad, ero convinto ci fossero 2 OSI. Comunque come te concordo che sia meglio avviare Windows dal proprio bootloader o quantomeno non da OpenCore. Personalmente non ho Windows, ma ho impostato come bootloader principale systemd-boot con due entry: una per Arch e una che punta ad OpenCore.efi

Mi intrometto nel thread perchè ho ancora qualche dubbio: perchè non mettere un all'inizio dell'SSDT così il codice viene eseguito solo se il sistema operativo, o meglio il kernel, è Darwin? Potrebbero esserci delle complicazioni su motherboard con BIOS legacy/primi UEFI? La vedrei come una soluzione più pulita piuttosto che riempire gli SSDT di n-Darwin...

Salve a tutti, ho acquistato di recente un monitor Acer modello EG240YPbipx (165Hz, 2ms, Freesync Premium, IPS, FHD). L'ho collegato al mio laptop in firma (Dell Inspiron 5370) e funziona anche in modalità clamshell. L'unica piccolezza è che dalle informazioni di sistema il monitor viene rilevato come un monitor 30,5 pollici, quando è un monitor 24 pollici 😅. Premesso che è un'"""issue""" di priorità bassissima, c'è qualcosa che posso fare per far si che le dimensioni effettive del monitor vengano rilevate correttamente? Grazie a tutti e buona giornata

Successfully updated ^^

Prezzo decisamente spropositato per una scheda video con soli 4GB di VRAM. Inoltre quali sono i principali task che fai con il pc? Video editing? Produzione audio?

Può essere che non gli funzioni l'audio dato che AppleALC è in posizione 0 nella lista di kext, e non dopo Lilu? L'ordine di precedenza delle kext (quantomeno le dipendenze) è molto importante

Mmmmmh capito. Giusto per curiosità: che senso ha disabilitare la SIP? Non è più "sicuro" avere la SIP attiva? Sto cercando di immaginare i possibili edge-cases per cui serva la SIP disattiva ma oltre a iniettare delle kext in (S)LE (cosa che può fare tranquillamente OC e schif (ehm) Clover) e effettuare operazioni particolari con gli snapshot di sistema, non mi viene niente. Idee?

Domanda: perchè la SIP è su 0x67? Ricordo male o da Catalina in poi sono cambiati i bitmask della SIP?

Figurati ^^ Uh caspita, ecco perchè ho perso qualche modifica in passato...

Uh, my bad che non l'ho testato. Oggi proverò e ti darò conferma nel caso Update: su Big Sur 11.4 (20F71) la LAN funziona con il solo boot-arg ^^

Salve a tutti, mi scuso in anticipo con lo staff se ho sbagliato sezione e prego gli stessi di modificarla nel caso. Ho deciso di scrivere questa mini guida per fare un po' di chiarezza su come abilitare il NIC I225-V Intel su macOS Catalina e Big Sur. In rete ci sono diversi tentativi di abilitare questa scheda LAN tramite patch via ACPI, kext come FakePCIID et similia, ma nessuno di questi mi ha convinto particolarmente, in particolare la soluzione con FakePCIID. Dunque, come procediamo? Innanzitutto occorre avere un'installazione vanilla (e sottolineo vanilla) di macOS funzionante e un programma in grado di estrarre i PciRoot come gfxutil/IORegistryExplorer/Hackintool/HackCheck. Di seguito la procedura per ricavare il PciRoot tramite i programmi elencati: - gfxutil: da terminale scrivere gfxutil e identificare la periferica LAN (di solito si chiama GLAN o RPxx.SL05) - IORegistryExplorer: è un po' più complicato ricavare il PciRoot path ma identificando la periferica LAN (che avrà un path del tipo PCI0.RPxx@1C,4/SLxx@0) lo si può convertire tramite questa formula: PciRoot(0x0)/Pci(0xAAAAA,0xBBBBB)/Pci(0x0,0x0) - Hackintool: aprire la sezione PCI, cliccare sulla colonna "IOReg IOName" e cercare "ethernet". Identificata la riga, cliccare col tasto destro e infine cliccare su "Copy DevicePath" - Hack Check: aprire la sezione DeviceProperties e identificare la periferica LAN. Una volta fatto ciò, occorrerà apportare le seguenti modifiche al config.plist di OpenCore (sry ma non digerisco Clover): Creare un figlio in config.plist/DeviceProperties/Add contenente il PciRoot path della scheda LAN e una proprietà di tipo DATA chiamata "device-id" e contenente F2150000, come illustrato in figura: n.b. modificare di conseguenza il PciRoot path Inoltre, aggiungere in config.plist/Kernel/Patch la seguente patch: <dict> <key>Arch</key> <string>Arch</string> <key>Base</key> <string>__Z18e1000_set_mac_typeP8e1000_hw</string> <key>Comment</key> <string>i225-V Patch</string> <key>Count</key> <integer>1</integer> <key>Enabled</key> <true/> <key>Find</key> <data>8hUAAA==</data> <key>Identifier</key> <string>com.apple.driver.AppleIntelI210Ethernet</string> <key>Limit</key> <integer>0</integer> <key>Mask</key> <data></data> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string>20.4</string> <key>Replace</key> <data>8xUAAA==</data> <key>ReplaceMask</key> <data></data> <key>Skip</key> <integer>0</integer> </dict> N.B. questa patch funziona da Catalina fino a Big Sur 11.3 ed è molto importante che il Count sia impostato su 1. N.B. per macOS Big Sur aggiungere ai boot-arg dk.e1000=0. Per comodità allego un file .plist contenente tutte le modifiche da integrare al config.plist di OpenCore Spero sia di vostro gradimento questa mini guida config.zip

Ok ora mi è più chiaro. Che tu sappia questo problema è circoscritto alle sole Z390 Gigabyte o anche Z390 di altri brand (Asus, AsRock, MSI)?

Ehm 😅 perchè dici così? E' da un bel po' che le Z390 sono state documentate (vedi KASRL come ha proposto giustamente @A23SS4NDRO sopra al mio commento). Piuttosto mi verrebbe da dire che il problema sia dovuto ad una possibile (sottolineo possibile) versione datata del bootloader (Clover). Ha due alternative: aggiornare Clover o fare lo switch a OpenCore (consapevole che dovrà documentarsi a dovere prima di dover procedere) 🙂

Premesso che non hai allegato la EFI ne tantomeno un dump del sysreport, a occhio e croce direi "perchè hai aggiunto SSDT-AWAC e SSDT-PMC?".

Ehm non penso che questo boot-arg riesca a fixare l'accelerazione grafica... Mi spiego meglio: questo boot-arg viene usato nel momento in cui dopo un ciclo sleep/wake o un semplice cold-boot lo schermo è nero. Nel suo caso dovrebbe patchare la grafica tramite WhateverGreen ed eventualmente patchare i connettori video

La possibilità di lasciare attivo il VT-d nel BIOS attivo, e DisableIoMapper disattivo?

Decisamente no. Potresti fare qualche futile tentativo con macOS virtualizzato da Linux (KVM) ma le prestazioni sarebbero pressochè ridicole, considerata la RAM installata e la potenza del processore

Ciao Gengik, grazie mille per avermi risposto ^^ Ho effettuato per sicurezza un reset nvram ma voglio aspettare ancora qualche giorno prima di confermare la soluzione. Grazie ancora ^^

Allego anche i risultati relativi a syspolicyd presenti in system.log: syspolicyd_system.log.zip

Buongiorno a tutti, recentemente ho reinstallato macOS Big Sur sul mio laptop Dell in firma e ho riscontrato tramite iStat Menus dei strani picchi di utilizzo percentuale della CPU relativi al processo syspolicyd. Cercando in rete, questo processo sembra essere relativo al GateKeeper che ho attivato già da diversi mesi e non mi ha mai causato problemi del genere. Avete idee su come risolvere eventualmente? Grazie a tutti per la collaborazione

Oddio per quanto riguarda linux posso confermarti che non è necessario avere la partizione EFI all'inizio della tabella delle partizioni, dal momento che sei tu a specificare tramite /etc/fstab l'UUID della partizione EFI .-. Per quanto riguarda il discorso di multiefi non so, non mi è mai capitato di dover creare più partizioni EFI, quanto piuttosto crearne una più grande (il massimo mai raggiunto forse è stato 600MiB)

Confermo. Per motivi che non sto qui a spiegare, per testare un dual boot macOS-Pop!_OS la dimensione minima della partizione EFI secondo Pop!_OS doveva essere di 500MiB, ergo i 200MiB che Disk Utility crea erano futili. Ho risolto cancellando la tabella delle partizioni con GParted e ricreandola in formato GPT e creando le partizioni che mi servono. N.B. quando crei manualmente una partizione EFI, assicurati di aver spuntato solo i flag boot, esp e che msftdata non sia spuntato. Se è presente questo flag, in automatico la partizione verrà considerata come una normale partizione dati presente nel PC e si monterà automaticamente

Ah, vabbè posso attendere. d'altronde non ho chissà quale fretta di testare Monterey

Buongiorno a tutti, stamane ho aggiornato i/le kext acidanthera e hanno fixato in pochissimo tempo i problemi di attivazione del Bluetooth su macOS Monterey. Scaricando l'ultima release master di BrcmPatchRAM, compilandola (Lilu.kext debug e MacKernelSDK nella root del progetto) e iniettando BrcmPatchRAM3+BrcmFirmwareData+BluetoolFixup il bluetooth ha ripreso a funzionare come su BigSur con BrcmFirmwareInjector. Per maggiori informazioni potete consultare il README.md di BrcmPatchRAM (link). Fatta questa piccola premessa, i tempi di boot di Monterey sul mio Crucial MX500 M.2 SATA III attaccato al PC tramite un enclosure USB3 sono decisamente più alti rispetto a quelli di Big Sur (20 secondi per BS e quasi un minuto per Monterey). E' normale? Ho effettuato una clean install proprio per essere sicuro di non avere un'installazione corrotta. Avete idee? Grazie mille

Yep, è una macchina discreta ma svolge il suo sporco lavoro. D'altronde per la programmazione non serve chissà quale potenza. Un 4C/8T basta e avanza