Bros

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?

Avendo sperimentato una situazione simile tempo fa, ti consiglierei di creare una partizione EFI su un supporto che la scheda madre identifica all'avvio, e installare il SO su NVMe. Io allora usavo un piccolo SSD per il bootloader (Clover e/o OC) e l'adattatore PCIe 4x per NVMe Sabrent. E' stato l'unico modo possibile per realizzarlo e il perché è palese nelle tue stesse parole. Il bootloader, quale esso sia, deve risiedere su un supporto che la MB identifica nativamente tramite BIOS. Se l'ultima versione del Bios della tua scheda è ancora troppo datata per supportare l'NVMe devi caricare il bootloader da quel drive che la scheda madre di permette. Poi, se il bootloader supporta NVMe ti consentirà vederlo disponibile all'avvio assieme agli atri sistemi che eventualmente hai a disposizione. Ps. già che c'era e per non lasciarlo inoperoso, sull'SSD ho effettuato il backup con TM.

Ti ringrazio @Anto65, ho tralasciato di aggiornare i kext che OCAT non considera supponendo erroneamente che andassero bene così. Con la sostituzione tutto è tornato a funzionare, wifi compreso, dato che la patch fatta in precedenza era corretta ma non avviava col SIP disabilitato e la AMFI vecchia. Grazie ancora! 👍

Non sono stato chiaro, la EFI-OCLP è rimasta la stessa, senza modifiche, da quando ho installato sonoma con la patch per il wifi. E' sempre andata e mi ha sempre permesso gli aggiornamenti con i necessari ripatchamenti vari. Per questo mi sono fidato e ho fatto l'aggiornamento di versione, riuscita anch'essa, sempre con la stessa EFI-OCLP. Questa volta però OCLP mi ha chiesto se volevo aggiornare anche la sua versione alla 2.1 e dopo il suo aggiornamento ho patchato il wifi. ... Al riavvio tutto si blocca. Sempre con la stessa EFI-OCLP che ho sempre usato. ... Aggiornamento: Riportando csr-active-config a 00000000 sequoia parte regolarmente, senza wifi. Lanciando OCLP mi segnala, ovviamente, che SIP è abilitato e si interrompe. Il quesito ora è questo. Allego il config per chi riesce a trovarci anomalie, magari pregresse. (ricordo che con sonoma avevo anomalie nelle librerie per una scheda nvidia che montavo con high sierra) config.plist.zip

Avrei una curiosità che mi deriva dall'aver aggiornato sonoma 14.7.1 funzionante con oclp 2.1. => sequoia 15.1. Aggiornamento eseguito correttamente (senza wifi ! ) e la finestra di oclp che mi avverte della necessità di patchare la scheda broadcom, così come mi ha sempre fatto ad ogni aggiornamento. Ora però, al riavvio si ferma nel caricamento e non va più avanti. (con la mela e 1/3 di avanzamento) La cosa che mi genera ignorante perplessità è vedere come l'installazione di sequoia sia funzionante (senza wifi) se avviata da una EFI identica ma ripulita da oclp, che ho su chiavetta... Il quesito: è possibile disinstallare oclp da sequoia con una EFI che non è quella con cui è stato installato , senza danni per la EFI stessa?

"...upgrade dopo upgrade il sistema inesorabilmente si trascina anche la spazzatura, tra i bug innati dei vari sistemi / aggiornamenti e le schifezze che non ricordi di aver inserito, che diventano difficili da ritrovare appunto se non hai esperienza ti ci vuole la sfera di cristallo." Così articolata la metafora acquista aderenza. 🙂 In sostanza e volendo riassumere, la risposta alla mia precedente è : NO! Risposta che da una parte giustifica il mio aver voluto mantenere tutto, e dall'altra alimenta le perplessità per tale scelta. Ottimo, va bene così!