Bros

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.