Bros

Certo, la pazienza è la virtù dei forti! Ma va anche agevolata. Pedante mente. (ottimo esercizio di pazienza) Ognuno procede con la lunghezza delle proprie gambe. Aragorn, Legolas ... Gimli 😀 Chi è il vero eroe della saga? ... Il piccolo hobbit, Frodo (!?)

A proposito di stranezze dovute a boot da dischi/EFI differenti - con alcuni che vanno e altri no - seppur "uguali" ... M'è capitato pure questo. Avevo 2 istantanee differenti nel volume di Sequoia (ovviamente non accessibili ne rimovibili con Utility Disco) come causa di mancate corrispondenze e avvii. Cosa che mi si è resa nota solo reinstallando Tahoe (full) da Sequoia, altrimenti avevo voglia a cercare! Suppongo che la causa sia il backup automatico di Time Machine che imperterrito salva istantanee di tentativi infruttuosi da me effettuati, sommando disastro a disastro. Disabilitando TM e un paio di riavvii di sicurezza e le istantanee sono sparite. ... ma va bene così!

@dany mi permetto di offrirti un suggerimento che è l'ammissione di quel che stai concludendo ora anche tu: Tahoe necessita di 2 EFI distinte. Una per l'installazione (pulita o meno che sia) un'altra per il post installazione. Distinzione che è opportuno fare con metodo, iniziando praticamente col dar loro 2 indicazioni nel nome ( a piacere) che le distinguano. Questo per evitare confusioni che ragionevolmente si fanno quando si "sbrocca" con ripetuti tentativi e fallimenti. A suo tempo mi sono dedicato nel realizzare la prima EFI, snella il più possibile affinché le probabili incompatibilità sw si riducano al minimo. (per quelle hw son dolori) Questo permette una installazione(e reinstallazione😀) assai più rapida e priva di sorprese, oltre alla noia di ripeterla. La mia assomiglia molto a quella che usavo prima di Sonoma, Priva di quel che è stato necessario poi per patchare il WiFi (non ti dico come fare, c'è chi è molto più bravo di me) L'ho chiamata "EFI Leggera" e salvata sul desktop oltre ad averla già sul disco di boot di Tahoe. Male che vada da li Tahoe (monco) si avvia ed è pronto per nuovi tentativi. La seconda "EFI Completa" è la copia della prima "EFI Leggera" salvata nella ESP di un altro disco che seleziono all'avvio del BIOS e su cui ho applicato i consigli di @Anto65 modificandola. (anche quì è inutile che li ripeta. I suoi sono ottimi e funzionano) Questo "perfezionamento" effettuato sino al funzionamento completo l'ho fatto solo ed esclusivamente su questa seconda EFI lasciando intonsa e distinta quella che, non si sa mai, mi fa ripartire "Tahoe liscio", senza patch ovvero così come la mia macchina lo ha consentito sino a Sonoma. ... Alla fine ho semplicemente invertito le EFI sui dischi. Pedante, dirai? Si! Ma è stato il metodo che mi ha permesso di cestinare le innumerevoli EFI che si accumulavano sul desktop, facendo chiarezza e focalizzando i mezzi e l'obiettivo. Riassumendo. Se hai la prima EFI sei a cavallo. Tahoe prima o poi lo cavalchi. Quando lo sai montare cambia EFI (cavallo) e sperimenta. Quel che sai già è che se i tentativi non sortiscono l'effetto desiderato o addirittura bloccano l'avvio, hai l'EFI Leggera con cui avviare senza dover reinstallare tutto da capo e poter cosi modificare la EFI Futura, che continua a risiedere su altro disco sino a che non raggiungi l'obiettivo che ti prefissi. So di essere Off-topic, così come gli altri post. Scusa la mia intrusione se questa ti disturba.

Mal comune è mezzo gaudio. @fabiosun 👍 Vorrà dire che si aspetta amfipass.kext versione light e nel frattempo si cambia browser.

Scusate l'intrusione, mi era parso di leggere che a qualcuno Firefox su Tahoe si blocca rallentando eccessivamente. Non mi riesce di trovare nei post precedenti come avete risolto, se si è risolto. Su internet il problema non riesco ad inquadrarlo, prospettandosi innumerevoli soluzioni che a me paiono eccessive. Nel mio caso Avviando Sequoia o Tahoe con stessa EFI, senza o con OCLP 2.4.1 Firefox funziona. Avviando Sequoia o Tahoe con stessa EFI, senza o con OCLP 3.0.0 Firefox non funziona e rallenta sino a bloccarsi. PS: l'EFI con OCLP (2.4.1 o 3.0.0) NON E' la stessa che utilizzo senza OCLP (2.4.1 o 3.0.0) 😉 Per questo suppongo che nell'installare OCLP 3.0.0 il config contenga qualcosa che nella 2.4.1 non c'era ( o viceversa). Ma cosa? Sarei propenso a incolpare AMFI ( kext o boot-arg) ma non vorrei incasinare le EFI che cn sforzo e molta attenzione sono riuscito a mantenere distinte e distanti.

Ottima dritta @Anto65 👍 E' andato tutto via liscio, dopo i tuoi suggerimenti.

Come immaginavo ... cosa ti fa supporre che potrebbe/dovrebbe funzionare il built-in su Tahoe, senza WoodooHDA o MyKextInstaller ? Così per curiosità.

@Anto65 scusa la curiosità, ma ti riferisci all'audio HDMI ?

@ldp48 a questo punto ha la possibilità di scegliere se proseguire in tentativi di "accomodamento" della EFI per far funzionare Tahoe, rimanendo nel frattempo senza un macOS funzionante o se ripristinare Sequoia avendo la necessità di accedere ai dati in esso contenuti. Mi scuso con lei nel caso in cui l'avessi involontariamente contrariata e la lascio ai suggerimenti certamente competenti di @Anto65 Buona giornata e buone cose.

Buongiorno @Anto65 apprezzo il suggerimento a R-DRIVE Image che da anni vedo essere usato da molti, qui, per "clonare" dischi di sistema. Per pigrizia non l'ho mai considerato, anche perché non faccio un uso così intenso rispetto a installazioni/reinstallazioni, smanettamenti etc. del mio unico pc che, proprio perché tale, è aspicabile funzioni"quotidianamente" senza troppi intoppi. Proprio considerando quanto tempo è passato da giovedì 25/11 a ieri sera che mi sono permesso di suggerire una "banale e ignorante" soluzione che ha l'indubbio vantaggio di risolvere in qualche ora. (OK, non minuti, ma qui son passati giorni!!!) Che Tahoe sia praticamente già installato e probabilmente funzionante con le dovute modifiche è evidente anche a me. Così come lo è il fatto che se è un problema realizzare una USB di Recovey, lo sarà di meno effettuare una mappatura delle porte USB che funzioni su Sequoia e Tahoe? (non per te ma per ldp48 ) Da qui la "botta di fortuna" che è auspicabile tutti abbiano nella vita. Questo per dire che non sempre l'indicazione "squisitamente tecnica" è il percorso migliore per la situazione che si sta considerando. A meno che non la si voglia liquidare in termini di "Domanda-Risposta" e ... avanti il prossimo. PS: ho sempre apprezzato sino ad ora l'approccio qui manifestato, e la cosa ha permesso di "evolvere" le mie conoscenze, stimolandole. Ma comprendo come questo iter possa essere frustrante e infruttuoso, anche per me, qualora si ricevano risposte "essenziali" ma telegrafiche la cui traduzione avrebbe bisogno di più di "qualche ora" per essere assimilata. (caso in cui la banale e ignorante soluzione risulta salvifica, pur lasciando a posteriori la possibilità di recuperare alternative assai più pertinenti ed efficaci)

All'avvio del Recovery dovrà selezionare Utility Disco per inizializzare il volume (APFS) in cui ora c'è Tahoe (dovrà sparire Tahoe-Data e svuotarsi) altrimenti non avrà un disco su cui reinstallare Sequoia poiché l'installer trova il disco già occupato. Ma se vuole conservarsi questa installazione di Tahoe per una eventuale botta di fortuna, e ha spazio sul disco, può aggiungere un volume APFS e usare questo come disco per l'installazione. Dopo di che, in un paio di ore al massimo reinstalla e ripristina il disco al ultimo backup di TM.

Sino a martedì 25 scorso aveva 4 EFI-OC variamente mischiate con altri bootloader. (FS3: FS8: FS11: FS13: da map-tablet.text) Mercoledì 26 ne aveva solo una, FS13:, mentre le altre risultano "ripulite", a volte anche troppo. (Non ne ha conservata neanche una integra, senza modifiche poi consigliate?) Controlli nelle varie EFI che dispone che Config.plist abbia una data anteriore o uguale a 25/11/2025. Nel caso va bene anche OldConfig.plist , purché con data modifica non superiore al 25/11 (in questo caso lo rinomini in Config.plist) e provi la EFI nel Recovery Sequoia 15.7.2 che ha creato su USB. Con l'aggiornamento a Tahoe ha sovrascritto le partizioni di macOS che si avviavano con la EFI di Sequoia , compresa quella di Recovery che eredita gli stessi problemi di avvio di Tahoe. Ma se non recupera una EFI precedente e funzionante con Sequoia ora non può fare altro che rifare a ritroso, da Windows, le modifiche da lei effettuata a partire da giovedì 27/11 dietro suggerimento richiesto, per riportare la EFI allo stato in cui era quando ha avviato l'aggiornamento, ovvero funzionante con Sequoia. Rileggendo però le sue richieste e i suoi commenti a partire da venerdì 28/11 spero che riesca in questa impresa, anche se le premesse non sono delle migliori. Male che vada comprima l'ultima EFI e la pubblichi nella speranza che qualcuno di molto più competente di noi due sia in grado di pulirla quanto basta per il Recovery. E chi lo sa? Forse qualcuno qui è in grado di renderla funzionante anche su Tahoe che ha installato . PS: leggo ora il suo aggiornamento. Nella schermata della Gui di OC non c'è traccia della USB di Recovery ma soltanto quella che l'aggiornamento a Tahoe ha preinstallato sovrascrivendo la precedente versione. Come le dicevo prima, quella non va al pari di Tahoe. La lasci perdere. Selezioni al boot del BIOS l'avvio da USB !!! (F1-F2-F12 ... Del/Canc) E' l'unico che può risolvere il suo impasse.

Mi rispondo "da me" Ho dovuto rintracciare il manuale delle vecchie cuffie BT, da allora associate ai vari macOS susseguitesi , per riassociarle a Sequoia, dato che, inspiegabilmente collegate a Tahoe (senza associazione) si sono dissociate da Sequoia (??? .. ma va bene così!) Così come, disattivato RestrictEvents.kext al riavvio è sparita la notifica dell'aggiornamento a Tahoe 26.1 e OpenCore Legacy Patcher ha proseguito come al solito senza problemi. (??? .. ma va bene così!) Ma in che modo OCLP è a conoscenza di un altra installazione (tahoe) o controlla l'eventualità di un aggiornamento, che comunque non è detto venga fatto? (??? .. ma va bene così!) 🙂

Essendomi capitolo più volte questo problema, più altri di uguale valenza sull'installazione, non sono riuscito a fare altro che reinstallare Sequoia e tutti i dati con Time Machine. Alla fine la cosa era talmente "abituale" che mi consentiva di risparmiare tempo su tentativi inutilmente frustranti. Ma fate voi.

Il mio Lexar NM620 SSD M.2 NVME è indubbiamente incompatibile con Tahoe. Questo dopo innumerevoli tentativi. Non ne consente l'installazione ne il suo avvio. Anche se reinserito successivamente, a installazione effettuata. Sostituito con altro Sabren. Ora Tahoe va senza altri problemi, oltre a quelli noti di WiFi e Audio. -> Perplessità: l'audio con cuffie BT va alla grande! <- Ma su Sequoia, che avvio con la stessa EFI, mi accade questa cosa strana Il BT risulta attivo ma non riesce a connettersi con nessun dispositivo (l'esatto opposto di Tahoe) e OCLP, già attivo, mi consente di patchare Sequoia. (?) C'è qualcosa da correggere per far sì che torni il BT in Sequoia e non lo levi a Tahoe, essendo l'unica fonte audio a mia disposizione? Ovvero: sarei tentato a lanciare lo Start Root Patching - che probabilmente funzionerà come sempre in Sequoia dove comunque posso utilizzare l'audio AppleALC - ma che voi sappiate, OCLP agisce sull'avvio, comune, o sulla installazione della versione su cui viene eseguito? (Sequoia) Ps: OCLP mi dice che devo finire di aggiornare Sequoia a Tahoe poichè ha un conflitto di versioni installate ... (o OCLP tiene una traccia nel bootloader comune (SystemVersion.plist) o macOS recupera dal SMBIOS registrato con AppleID il già citato SystemVersion.plist e lo aggiorna in fase di avvio)

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! 😀