dreamwhite

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

Sul mio Dell Inspiron 5370 Monterey gira discretamente, incluso il trackpad con le gestures, la mappatura delle USB etc... L'unica cosa che al momento non funziona è il bluetooth della mia DW1830 il quale dipende da BrcmPatchRAM...

La butto li: hai scaricato ed installato l'ultimo aggiornamento di sicurezza di High Sierra? Di solito quando scarichi High Sierra tramite App Store/script come munki, non scarichi l'ultima versione ma una precedente (17G66 per la cronaca). Verifica gli aggiornamenti disponibili tramite App Store e riprova >)

Mi intrometto al volo, senza sviare il topic. Sono perfettamente d'accordo su quanto hai scritto, anche se, per ragioni pratiche, soprattutto con utenti che sono alle prime armi, è meglio fornire una "pappa scodellata" mirata ad ottenere le informazioni di debug per evitare di "perdere tempo" sulle operazioni più cruciali. Chi è più "smanettone" poi può tranquillamente analizzare in seguito la EFI e capire nello specifico quali sono le opzioni utili al debugging (in questo caso SysReport attivo e Target su 67). Ci sono pareri discordanti riguardo AppleXcpmCfgLock ma personalmente sono più per l'idea della soluzione pulita. macOS richiede il libero accesso all'MSR 0xE2? Si. Allora va sbloccato ove possibile. Le patch, in quanto tali, vanno comunque trattate con le pinzette, e gli utenti che sono "temerari" e vogliono sfidare la sorte, si assumono la piena responsabilità in caso di riavvii randomici e/o altro, come accaduto al sottoscritto. Purtroppo (e non ne faccio una colpa) la maggior parte degli utenti neanche sa nello specifico cosa sia il CFG Lock, nè tantomeno perchè serva disattivarlo. A tal proposito, proporrei di fare una sezione di Q&A sul forum, se non già presente, in cui si cerca di dare una risposta alle domande più comuni, del tipo: - Da dove si parte con la creazione di una EFI di OpenCore? Cosa mi occorre? - Cos'è il CFG Lock? - ecc... Cosa ne pensi? Saluti

Mi intrometto al volo: e se al posto di usare gitbook (che nella versione free è molto limitante) usaste github pages? Se la memoria non mi tradisce, Dortania usa github pages + un motore di rendering in vue (che io ricordi)

Buonasera a tutti 🙂 @Gengik84 volevo chiederti: ha senso impostare la voce "All" su true per quanto riguarda il drop della tabella ACPI delle USB?

Uhm addirittura disabilitare il VT-D? O_O Personalmente lo attivo sempre e se devo avviare OpenCore (e quindi macOS) mi assicuro che DisableIoMapper sia attivo 🙂 Avere il VT-D disattivo generalmente non causa chissà quali problemi, tuttavia se vuoi sperimentare passthrough di periferiche PCIe tramite KVM su Linux é indispensabile 🙂

Potresti allegare un dump dell'output.txt (ergo chiamato Section_PE32_Image.txt)? Che io ricordi non tutte le schede madri consentono lo sblocco CNVi

Yep I know ^^ Più che altro non ho mai avuto occasione di usare in prima persona ru.efi dal momento che le modifiche che ho applicato al mio laptop le ho fatte tramite modGRUBShell.efi usando setup_var ^^

Fantastica guida! I miei più sentiti complimenti per la guida di ru.efi ^^ Vorrei apportare una piccola correzione alle voci BIOS da modificare (premesso che la procedura per il patching è corretta): disabilitare alcune voci come: - Above 4G - CSM Support - Serial Port - SW Guard Extension - TPM State Chiaramente queste voci vanno modificate solo nel momento in cui non sono visibili nel BIOS lato GUI

Non voglio scatenare flame di alcun genere ma usare un bootloader che è la copia carbone di OpenCore (tutti i meccanismi di iniezione di OC sono stati implementati su Clover), per di più con alcune limitazioni (vedi NVRAM/Add e NVRAM/Delete che non sono minimamente presenti) è un po' da sadici. Problemi quali slide sono facilmente risolvibili con la guida che ha giustamente linkato @A23SS4NDRO. Non capisco questa ostilità nei confronti di OpenCore dal momento che non ci vuole una laurea in Ingegneria Nucleare per poter "assemblare" una EFI da zero. Software come ProperTree, in combinazione con SSDTTime e GenSMBIOS facilitano il lavoro in una maniera allucinante. Perché uno che inizia ora con hackintosh dovrebbe iniziare con un bootloader al tramonto che copia le features di OpenCore (risultando quindi in un mero duplicato senza alcun valore aggiunto o vantaggio)? Sarei curioso di sentire i pareri sia del team quadrifoglio che del team occhio blu della morte ahah Aggiungo: quale motivo pone in vantaggio l'utilizzo di un bootloader vecchio nei confronti di uno nuovo e rifinito più che bene dai developers?

Mi duole dirlo ma non ho mai avuto problemi per quanto riguarda i dispositivi della LAN 😅 Sono su un laptop con scheda WiFi (non penso influisca sul discorso LAN) senza porta LAN

Buonasera, stavo passando per caso sul forum quando mi sono imbattuto in questo topic 😂 Premesso che non voglio puntare il dito contro nessuno in particolare, ne scatenare flame di alcun genere, avrei alcune domande da porre: 1. Perchè viene usato OpenCore Configurator? E' risaputo da secoli che i configuratori a lungo andare possono causare problemi di compatibilità con il config.plist relativo alla versione X di OpenCore. Inoltre sono closed-source peggio di non so cosa e sarebbe mille volte più saggio usare alternative come ProperTree (che include la funzione di snapshot della EFI) o PListEditPlus 2. Perchè non viene rispettato l'ordine di caricamento delle kext come scritto chiaramente nel codice sorgente di ocvalidate? (source) Molto spesso mi è capitato di avere problemi con alcune kext proprio per l'ordine di caricamento delle stesse 😕

Veramente molto strano...

Effettivamente non è tanto normale... Secondo me sarebbe meglio effettuare un SysReport partendo da una EFI di OpenCore debug forse?

@Matteo88 buonasera, domanda: hai già identificato le porte USB tramite IOREG? Non sempre c'è una corrispondenza diretta fra HS03 e SS03 (vedi Gigabyte Z390 Aorus Pro) Nel caso tu non l'abbia fatto, disattiva temporaneamente la mappatura delle porte USB e procedi all'identificazione delle porte USB e nel caso aggiusta la mappatura