Bros

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