Bros

Ammetto di essere stato incuriosito dal lunghissimo map-table.text allegato, avendo affrontato di recente, con il valido aiuto di @Anto65, il discorso entries di OC. E più cercavo di comprenderci qualcosa e più la cosa mi incuriosiva. Perché? Ecco, questa era ed è tutt'ora a domanda che mi ha spronato alla curiosità. Da quel che mi è parso capire dal map-table allegato, nell'istante in cui l'ha prodotto, aveva installato 7 dischi: 1 disco USB contenente Windows 4 dischi Sata di cui il primo contenente Windows e i rimanenti 3 contenenti 5 versioni di Ubuntu (Linux generico) 1 nel secondo, 3 nel terzo e 1 nel quarto. 2 dischi NVMe. Presumibilmente contenenti MacOS e ancora Windows. (purtroppo la sua shell interrompe l'investigazione a FS21: [recovery di windows su USB] pur avendo FS22:, FS23:, FS24: da considerare, essendo in map-table.) 8 partizioni Fat32 contenenti EFI varie 9 versioni differenti di SO di cui 3 di windows, 5 di Ubuntu e almeno 1 di MacOS ...Con cifre del genere la curiosità aumenta. Se mi trovassi in una situazione del genere (?) innanzi tutto pulirei le 8 EFI in modo che ognuna avvii il suo SO, possibilmente stand alone. Fatto questo avrei una EFI per ogni disco (7 dischi per 7 versioni di SO) e un'altra EFI (ottava) sul 3° disco Sata con Ubuntu x 3 versioni. Fortunatamente questo a me non accade. Le auguro quindi ... buona fortuna e molta attenzione nel manipolare le partizioni EFI.

Stringa eliminata. Ora provo a reinstallare il Lexar, che sino a Sequoia non è mai stato oggetto di panic e vedo se Tahoma lo digerisce. Certamente il layout-id 01000000 ad un controller NVMe è qualcosa dall'esito misterioso. 🙂

Ora che guardo meglio l'elenco PCIe di Hackintool, vedo che alle tre porte radice PCI Express (#21,#17,#9) sono collegati i miei 2 NVMe Sabrent mentre la terza (#17) è senza l'NVMe (Lexar) che ho rimosso. Ma controllando in Device Properties noto che la porta #17 ha, da suggerimento Dortania, un layout-id 01000000 (???) riferito all'audio (?) Che sia questo il problema che ha impallato l'installazione di Tahoe con il controller del NVme Lexar?

Grazie ancora @Anto65, anticipi anche quelle che sarebbero state le mie intenzioni. 🙂 Effettivamente quella di avere un solo EFI per entrambi i sistemi era il mio obiettivo iniziale che ho rimandato per i problemi avuti con l'NVMe. Per quanto riguarda l'inserimento delle proprietà delle periferiche tratte da Hackintool in Device Properties, quali tra tutte è possibile inserire e quali no? Suppongo che possano/debbano essere inserite quelle che riguardano i controller delle periferiche installate fisicamente nei vari slot PCI e NVMe. Escludendo quelle di classe Bridge di stretta pertinenza della mobo/processore. Immagino che anche il controller USB, quello Ethernet e Audio possano essere inseriti ma non so con che benefici. Essendo onboard la loro presenza dovrebbe essere segnalata ed esposta nel DSDT.

Rispondo alla mia stessa domanda: Niente, è sufficiente riavviare più volte e attendere che consideri finalmente le periferiche installate. Prima o poi ci azzecca. Infatti al terzo riavvio senza scheda, Sequoia s'è accorto della sua assenza. Reinstallandola e riavviando OCLP anche la scheda appena inserita ritorna a funzionare, come se niente fosse!!! Ma si può? 😮 Ps: Grazie @Anto65, proverò ad aggiungerlo alla dotazione standard. Anche se la cosa mi lascia molte perplessità su OS mac.

@fabiosun " @Brosse fai revert ti riattiva il pulsante?" No. @Anto65 "Ma il Wi-fi non ti va' ? " Non va. Avendo constatato come possano influire anche piccoli dettagli hardware, ho pensato di rimuovere la scheda WiFi e reinstallarla. (Ho dovuto rimuoverla più volte per accedere al sottostante e mal digerito - da Tahoe - NVMe Lexar di windows ) Con mia non più grande meraviglia, nonostante assente, la scheda risulta presente in "Informazioni di Sistema" sia sotto WiFi che Bluetooth. Ovviamente, in questo caso, OCLP mi restituisce la precedente informazione: "No patches required" . Come posso "sciacquare" la configurazione riportandola a periferiche realmente installate e non presunte? (Il reset NVRAM non funziona)

Dopo aver installato Tahoe su disco separato ho ripreso l' EFI precedente. Quello che utilizzavo (e utilizzerei) per Sequoia con OCLP e WiFi attivi. Per Tahoe ho dovuto disinstallare OCLP da Sequoia e rimuovere nella nuova EFI quel che avevo aggiunto per OCLP. Quindi reinstallando OCLP su Sequoia mi sarei aspettato di vederlo funzionare con la vecchia EFI. Solo che, con mia grande sorpresa, OCLP mi restituisce questo senza abilitare nulla. Sapete se rimovendo e reinstallando OCLP si generano problemi? C'è la probabilità che abbia modificato qualcosa inavvertitamente ma non trovo nulla di errato. L' EFI è copiaincollata dalla scrivania e solamente aggiornata alla ver 1.0.6 senza ulteriori modifiche. Ho usato più volte l'uninstaller.pkg e successiva installazione, ma il risultato è lo stesso. ☹️

La RTL8111 torna a fare il suo lavoro abilitando DisableIOMapper. AudioHDA e WiFi sono ancora acerbi, a quanto mi pare di capire. A meno che non ci siano dritte efficaci converrebbe attendere tempi migliori. Sbaglio?

Modificando i 2 identificativi nel info.plist del kext - grazie @Anto65👍 - sul EFI-MacPro7,1 Tahoe mi concede l'accesso e finalmente grazie al vostro supporto l'installazione è andata a buon fine. Facendo un calcolo dei danni, 2 Sabrent su tre NVMe sono installati e tollerati da Tahoe. Il terzo, Lexmar con Win 😀, ha un controller che non sopporta/supporta e per ora è smontato. Vi ringrazio, quindi, per i consigli forniti, la cui bontà è provata dl fatto che una volta trovato il problema di compatibilità hardware l'installazione si è conclusa e, con mia grande soddisfazione, ora si avvia sia con EFI-MAcPro7,1 che con EFI-iMAc20,2 Lasciandomi la possibilità di sperimentare Tahoe con uno e continuare ad utilizzare il mio account Apple con l'altro. Resta poi il problema già esposto da @Giaccaz di Ethernet, WiFI e Audio che nonostante siano rilevate non vengono attivate come prima. Senza approfittare troppo della vostra tolleranza, cercherò di far tesoro di quanto già esposto per vedere se "me la cavo" . Altrimenti son qui. Sicuro! 😀

in pratica ... no. L'avvio di Sequoia con la sua solita EFI, modificata solo da iMAc20,1 a MacPro7,1 si avvia ma non abilita nessuna porta USB lasciandomi fermo al login. La mappatura funzionante in Sequoia e corretta come da suggerimento di @Anto65 con il nuovo SMBIOS non va. Vale la pena di provare l'installazione di Tahoe con una simile EFI? Ovvero, la mappatura rifatta per Tahoe e funzionante sotto Sequoia con iMac20,2 ma non con MacPro7,1 ... sarà poi funzionante con Tahoe?

Provo SMBIOS MacPro7,1 Ma la configurazione per iMac20,2 della EFI andrà bene lo stesso?

Buongiorno @Giaccaz capiti a "fagiolo" con la tua installazione di Tahoe, poichè il tuo sistema è molto simile al mio che, come avrai notato dai post precedenti, non si avvia. Molto probabilmente non ho colto l'esatta sequenza con cui hai applicato i consigli di @Anto65 Molto probabilmente la tua EFI di partenza, per quanto "simile" alla mia, in realtà si adatti meglio. Questo mi induce a supporre che la mia EFI di partenza vada ritoccata affinché i benefici consigli suggeriti sortiscano l'effetto desiderato. Per questo ti chiedo, nel caso l'avessi già pubblicata, il link ad una copia della tua EFI da cui sei partito nella modifica. Proverei a testare le differenze con la mia per vedere se ci cavo qualcosa di buono. (ottimista!)

Niente da fare! Sono ancora in cerca di una soluzione che mi consenta di installare Tahoe senza la necessità di rimuovere i dischi e modificare il SMBIOS. (iMac 20,2) L'aggiornamento provato più volte si blocca e mi costringe a reinstallare da capo Sequoia. L'installazione completa da usb si blocca. L'unica a procedere almeno un minimo è l'installazione completa da Sequoia . Inizia a copiare le varie directory (che da Sequoia appaiono in Tahoe- Data) e si prepara al reboot. Purtroppo anche in questo caso al riavvio si blocca. Come modifico la EFI per far finire l'installazione senza blocchi? USB e WeG 1.7.1d corretti già installati (provati anche nel fortuito successo precedente mai più riprodotto) EFI.zip

PS. una altra soluzione, la migliore se fosse risolutiva, potrebbe essere: avviare l'NVMe di Sequoia con la EFI con cui ho installato Tahoe (senza Wifi ma con Audio) e provare se da li l'aggiornamento incrementale si finalizza. Avrei risolto alla grande senza la necessita di un altro SSD per Tahoe!

Alla fine ci sono riuscito anche io! Ma rimangono ancora molte perplessità sulla stabilità di questa versione così installata. Come immaginavo nella precedente l'ininfluenza delle varie WeG era dovuta a problemi, a me ancora sconosciuti, che anticipavano il blocco alla finalizzazione a avvio di Tahoe. In particolare ad una immagine disco criptata che mi porto nel sistema a seguito della attivazione della firma elettronica con lettore. Ho dovuto piallare anche questa immagine con utility disco seppur non sappia neanche dove sia archiviata fisicamente. Suppongo nell'Nvme che utilizzo di solito con Sequoia 15.7.2 ma che non ho collegato. Suppongo che il Panic sia dipeso da qualche controller NVMe a cui l'installar tentava di accedere per "preservare" un'immagine disco che considerava importante. (???) Rimosso il quale l'installazione è proseguita sino al blackscreen della scheda video che mi ha avvisato che il WeG di serie andava sostituito con la versione 1.7.1d7 Questo riguardo l'installazione. Infatti, oltre alla mancanza di WiFi e Audio c'è il ricorrente blocco all'avvio che anche il solo collegamento del disco Dati/Backup comporta. Tutto identico a quel Panic che mi veniva segnalato quando tentavo di installare il SO. In sostanza Tahoe funziona solo se è solo soletto a gestire il sistema, non tollerando i "miei dischi". L'unica soluzione che mi viene in mente è quella di sostituire il SMBIOS con quello che ho sempre usato, provare ad accedere con la mia AppleID e se va bene al suo riavvio (e successivi) provare a ricollegare il famigerato disco nella speranza che non blocchi l'avvio avendo riconosciuto lo stesso sistema e lo stesso utente in grado di validare questa immagine criptata dei miei dati. 😱 Qualcuno ha avuto mai esperienze mistiche di questo tipo? Non so proprio come cavarmela nel caso in cui non funzioni.

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.