Bros

Come anticipavi, @Anto65, l'adeguamento di USBPort.kext con USBmap è stato banale, ma non risolutivo. Nel senso che lo uso tutt'ora con Sequoia 15.7.2 senza problemi ma di far avanzare l'installazione non se ne parla. Anche i vari Whatevergreen.kext non influiscono con il blocco che, a questo punto, incomincio a sospettare risieda altrove. Ma dove? Attualmente mi trovo con "anche" un SSD interno totalmente dedicato a Tahoe, con ii suo bell' EFI che allego e una installazione su disco che non si finalizza. Con un unico pc su cui monto 3 NVMe un disco dati/backup e il suddetto ssd, ho provato aggiornamenti e installazioni pulite, pulite senza i 3 NVMe contenenti Mac, Win, Ubu. Persino senza il disco dati/backup perché ho scoperto solo ora che in fase di installazione va a ravanarci dentro e associa estensioni a/e applicativi che trova in giro, figurarsi account Apple e SMBIOS. Pulito a tal punto che essendosi bloccato per l'ennesima volta e senza possibilità di scelta ho dovuto reinstallare il tutto per tornare qui. L' EFI che allego è sostanzialmente quella che utilizzo normalmente con Sequoia, a cui ho ridotto la GUI (solo Acidanthera) e tolto le modifiche introdotte per il WIFI , almeno per ora. (OCLP che so già non funzionerà correttamente) Ah, già che c'ero ho provato anche la versione debug di OC 1.0.5 nonché entrambe le versioni di OC 1.0.6. Niente. A quanto pare non sortiscono nessun effetto sulla causa del blocco. Il file di Debug OC è allegato assieme allo screenshot del verbose al momento del blocco. EFI.zip opencore-2025-11-03-124252.txt.zip

Ciao @Anto65, seguirò la tua guida per aggiungere il numero della porta alle USB mappate e funzionanti, se ho capito bene. Grazie. Mi fa piacere sapere che SIP non influisce nel crittografare i dati durante l'installazione e che questa possa partire invece in caso di mancata disconnessione dall'account Apple. (nei vari tentativi di installazione questo "errore" mi è costato la reiinstallazione di Sequoia e ripristino di Time Machine per ben due volte. Poiché bloccandosi in fase di installazione l'intero disco risulta inaccessibile!) Comunque,, come puoi vedere, ho due sequoia su due dischi differenti (e due EFI differenti) La seconda copia è installata ex novo senza AppleID e mi permette un aggiornamento di 4 e rotti giga che parte e si riavvia ma, se lanciato da OC, si blocca. All'incirca nel punto in cui Sequoia esita caricando la grafica (se non ho intuito male) Ps il link a limewire mi comprime la cartella esattamente come farebbe Finder (25,4 MB). Non capisco a cosa serva se comunque non posso allegarlo.

Ciao @fabiosun, non capisco cosa intendi chiedendo se la mappatura usb è aggiornata per Sequoia? Volevi dire per Tahoe? Con Sequoia la mappatura per me funziona bene, nel senso che ho 14 porte funzionanti di cui 2 interne (hub doppi) che corrispondono alle 2 usb frontali. Considerando che l'AURA LED non lo uso neanche a Natale e l'ho disabilitato da bios, le porte utili sono 15. (... o 16?) Ho poi provato varie versioni di Whatevergreen , tutte funzionanti su Sequoia, al punto che non saprei distinguere le differenze ma nessuna in grado di portare avanti l'installazione di Tahoe. Come scrivevi in altro post, la rx 580/590 senza whatevergren non funziona. Ma ho anche la 630 integrata del i9 10900k che, volendo, potrei utilizzare se solo bastasse disattivare dal config la scheda rx 590. Francamente non avrei voglia di smontarla fisicamente ma immagino che arriverei a tanto, se fosse necessario a moderare la cocciutaggine che immagino possa sorgere. ... Se serve poi posterei l'EFI completo ma ... anche zippato è troppo grande. Lo faccio a pezzi ? 😀 Per ora grazie dell'interessamento.👍 Sono proprio curioso di scoprire cosa mi sta andando storto. Leggendovi sembrerebbe cosa difficile, ma non impossibile, anche con macchine assai più datate della mia.

Chiedo consiglio. Ho provato ad istallale Tahoe sin dal primo aggiornamento e niente. Si blocca inesorabilmente a metà dopo aver selezionato l'installar di Tahoe tramite OC 1.0.5 Sono ancora fermo su Sequoia 15.7.1 Allego il config con cui avvio ed ottengo regolarmente l'aggiornamento incrementale che mi permette almeno di iniziare l'installazione e accedere ad un avvio che non termina. Ho rimosso OCLP e riattivato SIP per timore del Filevault, provato con e senza Whatevergreen (che avendo una RX590 è d'obbligo, o no?) ma sono fermo. Ps controllando con OCAT i driver risultano "da aggiornare" alla ver. 1.0.5 ma quelli li ho recuperati da Dortania per OC 1.0.6 release https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true&version=1.0.6 . Nel dubbio potessero andare meglio. Tra l'altro, quelli "aggiornati" alla 1.0.5 vanno nello stesso modo. Ps2 Non so se si vedono le specifiche dell PC, le avevo inserite tempo fa e non saprei ora come recuperarle, correggerle e esporle. Sorry. config.plist.zip

Ciao @dany anche a me si blocca l'installazione di Tahoe da Sequoia aggiornamento e, dopo vari tentativi, ho lasciato perdere, per ora. Mi incuriosisce però il tuo "l'ho fatto e inserendo a metà installazione il file di Fabio: WhateverGreen.kext.zip" In che modo? Al suo riavvio non hai selezionato l'installer di Tahoe ma hai avviato Sequoia, modificato la EFI di avvio con il file di Fabio e riavviato l'installazione di Tahoe?

Sono ancora qui perché di installazione non se ne parla proprio. Ho eseguito un aggiornamento da Sequoia 15,7 a Tahoe 26,0 immediatamente dopo il suo rilascio, settimane fa. (considerazioni mie: con l'aggiornamento e il medesimo SMBIOS, anche se su hd differenti, le versioni condividono un ambiente che se compromesso, manda tutto all'aria. OCLP era ancora attivo e nulla sapevo di temporanee disattivazioni di WhateverGreen, AppleALC e eventuali mappature USB extra. Così ... bello fresco come appena sveglio!🙂) Si è avviato e ha installato su un "nuovo hd" i suoi file ma al riavvio si bloccava inesorabilmente a metà. Tra l'altro mi ha incasinato anche il boot di tutti i File System installati. ho dovuto scollegarli e riavviarli uno alla volta. Ieri ho provato da chiavetta il full Installer su "nuovo hd". Ovviamente OCLP assente, con la mia EFI di Sequoia a cui ho disattivato WhateverGreen e AppleALC. Come previsto non si avvia, ma leggo ora che mi manca l'impostazione "disattivi i kext brmc, block etc, o imposti" la cui mancanza pregiudica l'avvio. (solo relativamente ai kext IOSkywalkFamilyLegacy) Quindi riprovo e se almeno si installa passo altrove per risolvere gli inevitabili problemi con lei sorti.

Scusa un attimo, ma se installo Tahoe da chiavetta, con su il mio attuale EFI modificato, che necessità ho di disattivare OCLP su Sequoia e abilitare SIP se l'installazione è pulita su hd vuoto? A meno che OCLP non modifichi (patch) OpenCore.efi , dato che il resto dei file restano immutati dopo la sua attivazione. In quel caso carico OpenCore.efi dalla release e ho già eliminato le patch e la presenza di OCLP senza toccare la mia attuale istallazione di Sequoia ... o no? A tentativo avviato mi sposto sotto [Release] macOS Tahoe 26.0.1

Full Installer già scaricato e su chiavetta. ... Disattivo OCLP (revese) e ripristino SIP, sostituisco appleAlc con Voodoohda o MyKextInstaller. Le porte mi sembrano mappate correttamente, devo fare altro per fargliele attivare? Weg va disattivato per l'installazione? Poi va ripristinato? ... ?

Ripulendo \EFI\Boot e sostituendo boot.efi, Windows riparte e dopo una lunga attesa si avvia. Zorin si avvia. OC no! ...scherzo.😂 SI è risolto tutto come doveva essere sin dal principio. Grazie ancora @Anto65. E' importante avere un confronto con qualcuno che ti aiuta, specie se competente.! ps. volendo tentare un'installazione pulita di Tahoe piuttosto che una installazione dall'aggiornamento di Sequoia 15.7.1, quale link mi consigli?

Grazie @Anto65, la mia versione è la 25h2 aggiornata a ieri e fino a ieri si avviava con la EFI senza entries. Poi con l'entries .../\EFI\Boot\bootx64.efi ha smesso di avviarsi (bootx64.efi scritto da Zorin?) ma riparte con .../\EFI\Microsoft\Boot\bootmgr.efi.

Ciao @Anto65, ti aggiorno degli sviluppi. Ho rimosso tutti gli NVMe lasciando solo Zorin. Questo ha una EFI con la tua stessa struttura. Si avvia da bios, come immaginavo. Ho aggiunto l'NVMe di Sequoia con EFI modificata e il tuo config (hai cambiato anche il PikerAttributes a 144, 145 mi era stato consigliato da chris1111) e ... magia, Zorin si avvia come faceva prima senza entries. Questo a bontà della procedura che mi hai proposto. Ho investigato un po' e con OpenShell ho notato che ora FS0: è Ubuntu, non più Windows! (bella scoperta 🙂) La cosa mi ha fatto pensare. Avendo fatto da OC l'aggiornamento alla versione Pro di Zorin, - obbligatoriamente da chiavetta - e avendo lasciato fare a lui le opzioni di boot (come te) ma tenendo buona senza formattare solo la /root e tutti i dati contenuti nella /home, mi è venuto in mente che l'installer abbia generato il boot nella EFI che riteneva corretta cioè la prima del primo disco FS0: che corrispondeva a Windows. !!! Controllando le EFI salvate noto che quella di Windows e quella di Zorin hanno gli stessi file nella cartella boot, cosa che mi lascia supporre che ci sia in minimo di fondamento alla supposizione precedente. Ora mi viene qualche dubbio (ignorante) : E' possibile rimuovere dal Boot di Windows fbx64.efi e mmx64.efi senza danni? ... e bootx64.efi è quello giusto per Windows o è, come immagino, quello di Zorin? Non vorrei che, reinstallando l'NVMe di Windows, Zorin torni a cercare il suo boot su quest'ultimo. Ovvero alla situazione di partenza. Comprensibile quindi che il precedente /\EFI\BOOT\bootx64.efi avesse qualche problema. Cosa che verificherei se trovassi un bootx64.efi per windows che potesse andare anche qui. (Uno qualsiasi di windows andrebbe bene?) Non mi arrischio per ora in modifiche e attendo lumi.

Cambiando la directory di boot di Windows, finalmente si avvia!!! 🥂🍾 (bootx64.efi non andava bene? ...perchè?) mentre Zorin è sostanzialmente inaccessibile dal config così modificato. (con quello precedente e i driver idonei si) In realtà quel che è cambiato da Zorin a Linux è il logo sull'immagine del disco. (flavour 🙂) Proverò a crearmi una Live di Zorin dal suo interno per reinstallarlo dopo aver rimosso i due NVMe - ovvero senza OC - per poi ricollegarli successivamente. Questo però mi genera il dubbio che un aggiornamento di versione avviato da OC possa pregiudicare, un domani, l'avvio di Zorin. ??? ...Vediamo. Grazie ancora @Anto65, 👍 a meno che tu non sia a conoscenza di un diverso launcher per ubuntu che sia in grado di correggersi , tipo "EFI/BOOT/BOOTX64.EFI" 🙂, non credo ci sia molto altro da aggiungere. Tra poco, in altra discussione, ti chiederò di USB e Tahoe. Mi è parso di capire che li ci potrebbero essere problemi.

Ciao @Anto65, non dubitavo che a te andasse! 🙂 Questo che allego è la map dei soli 3 NVMe installati. Il copia-incolla si facilita ma, ho riprovato e ... il risultato è identico. Per mia curiosità e maggior chiarezza ho prodotto questo screenshot. map_table.text.zip

Stacco l'HDD e lascio solo i 3 NVMe così lo screenshot di EfiShell è più chiaro nei rimanenti FSx: Dopo rifaccio il map e lo allego. Per ora i 2 Config (prima e dopo) e quel che conferma anche MountEFI (clover/oc) Archivio.zip

Grazie @Anto65, procedo.

Dopo vari tentativi falliti per non so ancora quale perché, sono passato da così a così. Esteticamente è quello che desideravo, solo che ne Windows ne Zorin si avviano, pur avviandosi se selezionati dal boot bios. L'avvio di Windows è mentre quello di Zorin è Da quest'ultimo si intuisce che grub fa riferimento ad una efi correttamente individuata e allegata al config, pur senza avviarsi. Cosa che lascia presumere che anche il riferimento alla efi di windows sia corretto, cosi come map-table.text suggerisce. ... per ora ricarico il disordinato ma funzionante config precedente e aspetto lumi. (lo ScanPolicy potrebbe centrare?... e OpenLinuxBoot.efi è ancora necessario?)

Allora... Ho provato e recuperato gli FS opportuni. Tutto fila sino a map > map-table.text La shell risponde che non è possibile reindirizzare e ... non avendo i percorsi giusti da copiaincollare nel config che faccio? Lo screenshot della shell con f10 non va. Me li ricopio a mano col rischi di disastri? Provo con OpenShell.efi di OC 1.0.5 , hai visto mai.

Buongiorno @Anto65, grazie per l'aiuto che almeno dal tuo screenshot allegato riassume quello che intendevo ottenere. 👍 Sperimenterò fiducioso nel pomeriggio la procedura da te suggerita e ti anticipo che questo aggiustamento "estetico" in realtà ne prelude uno prossimo con l'installazione di Tahoe che, con la attuale EFI, ( OC 1.0.5 - Sequoia 15.7.1 - OCLP) fallisce miseramente l'aggiornamento proposto da Apple. Tornerò a chiedere la tua assistenza. Ma per ora grazie ancora.

Ciao, mi decido solo ora a chiedere in che modo riordinare la GUI di OpenCore per posizionare macOS, Windows e Linux in questo ordine e non come si presentano in foto. Tra l'altro, cancellerei volentieri il disco OC NO NAME che non esiste e blocca l'avvio se selezionato. Ricordo qualcosa di simile con Clover, molto tempo fa, e ci sarà probabilmente qualcosa di più recente in queste pagine ma non riesco a trovarlo.

Buongiorno @Anto65 , anche io ieri ho provato ad istallare Tahoe usando la EFI funzionante per Sequoia 15.7, non come aggiornamento ma su ssd separato e ... niente. Si blocca a metà installazione. Suppongo vada modificato l'avvio con Opencore e, avendo trovato in rete varie discussioni che trattano "frammentariamente e forse in modo troppo specifico", mi risulta difficile assemblarle tutte in maniera organica. In tal senso ho trovato una guida che potrebbe semplificarmi la vita ma, da non esperto, sarei curioso di sapere la tua opinione a riguardo. ... Non so se è consentito pubblicare qui il link (?) https://kextcache.com/macos-tahoe-hackintosh-guide/ Come ultima versione di macOS per processore Intel sarebbe interessante produrre una release che sintetizzasse l'ottimizzazione del bootloader per l'ultima piattaforma supportata da Apple, la Comet Lake, che anche @Giaccaz tenta di configurare. A futura memoria di un appassionato impegno.

Ciao Anto65, ora mi è più chiaro cosa intendevi con "revert" di OCLP (che non ho mai fatto!) confondendolo con il solito "start root patching". 👍 Le altre curiosità le sperimento tornato dal lavoro. Grazie ancora!

Buongiorno Anto65, ti garantisco che ho letto "sopra" tutto quel che si poteva leggere, ma a questo punto suppongo che ci sia anche un "sotto" (che ignoro) da tener da conto. Il quesito è : come mai Apple mi propone un aggiornamento (simile al tuo) ma ho dovuto scaricare un package 10 volte più grande? (o meglio, al pari di Open Core, si considera "Release" la versione definitiva o altro?) poi aggiungerei anche qualche altro ... mistero, di cui chiedo spiegazione: - Perché non mi compare l'icona di Sequoia ma solo la generica scritta mac OS, cosa che avviene anche nella gui di OC? - Come mai l'ultima versione di OC risulta essere, anche con OCLP da te consigliato la 1.0.4, mentre la tua è la 1.0.5 ... (Release)? (questo sino a pochi minuti fa!) Come avrai capito, sono solo curiosità che non pregiudicano l'effettivo funzionamento, la cui spiegazione non urge, ma sarei più contento se sapessi anche il perché. Grazie.

dal blog Kingston: SATA M.2 SSD Iniziamo col dire che nel mese di dicembre 2022 abbiamo venduto l’ultimo dei nostri SSD M.2 SATA, il modello A400 M.2. Non produciamo più SSD M.2 con interfaccia SATA e in futuro tutti i nostri SSD M.2 saranno di tipo NVMe. Ma all’epoca, gli SSD M.2 SATA utilizzavano l’interfaccia SATA con una velocità di trasferimento dati massima pari a 6Gbps. Si tratta di un'interfaccia lenta rispetto ad altre più recenti (per saperne di più, si veda più avanti). Gli SSD SATA stanno in fondo alla classifica per prestazioni, in quanto utilizzano la stessa interfaccia dei dischi rigidi. Tuttavia, gli SSD SATA offrono una larghezza di banda da tre a quattro volte superiore rispetto ai tradizionali dischi rigidi . Gli SSD SATA erano anche maggiormente diffusi ed economici rispetto agli SSD NVMe. Gli SSD M.2 SATA rappresentavano un’ottima alternativa agli SSD da 2,5” se non si disponeva dello spazio per questi ultimi nel proprio computer. SSD NVMe M.2 Gli SSD NVMe M.2 utilizzano il protocollo NVMe, specificamente progettato per gli SSD. Quando abbinati a un bus PCIe, gli SSD NVMe offrono i più recenti livelli di prestazioni e velocità ottenibili. Gli SSD NVMe comunicano direttamente con il processore, o CPU, attraverso le corsie PCIe. Essenzialmente, consentono alla memoria flash di operare come SSD direttamente attraverso le prese PCIe, anziché dover utilizzare i driver di comunicazione SATA, che sono notevolmente più lenti rispetto a quelli NVMe.

Installazione della release 15.5(24F74) conclusa con applicazione delle patch OCLP 2.4.0 Questo per dire che qualunque sia la differenza, l'aggiornamento è andato a buon fine. Resto ancora ignorante sul perché il mio aggiornamento ha scaricato 15 giga e rotti, contro un decimo del tuo. ?

Scusa l'eventuale banalità della mia perplessità ... ma com'è che visualiziamo due descrizioni e due dimensioni di download differenti?