A23SS4NDRO

Tasto destro su Bootinstall_x64.tool, mi chiede il numero del disco, poi gli do la password Ho anche visto il tuo tutorial, procedimento identico (ma la password la chiede appena prima di usare dd) Posso provare a metterci sudo prima...

Dici che serve che apra un issue su bugtracker?

Ho provato esattamente come hai detto, ma non gli piace... Finora funziona solamente legacyboot (utility di OpenCore) quando punto alla usb (disk3s1) ma non c'è modo per portare paro paro quello che funziona sulla USB, sull'SSD (almeno non con il tool fornito da acidanthera)

Dal momento che il pkg di clover riesce a sfruttare l'ESP dell'SSD per caricare CloverX64.efi, è possibile ripetere gli stessi procedimenti descritti qui per farlo puntare a OpenCore.efi o Bootx64.efi che fa il chainloading a OpenCore.efi? Installation.txt.zip

Si forse... non so quanto siano utili Comunque la coda è la più dura da scorticare, vi descrivo in breve il problema Come sapete, nel pacchetto di OpenCore è presente dentro Utilities > LegacyBoot se uso l'utility BootInstall_X64.tool sulla USB, crea il bootsector sulla ESP (il cosiddetto file "boot") che funziona benissimo quando premo F12 per selezionare la USB dal bootmenu Se ripeto lo stesso identico procedimento con l'SSD, non gli piace e rimane ad aspettare in eterno che un bootsector funzionante sia per i suoi gusti (nonostante quando si usa il tool bootinstall_ X64.tool seleziono disk0s1, che appunto è l'ssd SATA)

Ok ha funzionato, bastava ReleaseUSBOwnership (anche se su clover funzionava senza, ma penso che intervenisse di volontà sua anche se non era specificato da config.plist) Messo On su OpenCore e le USB vanno Mando un ioreg da avvio OpenCore 0.6.5, la EFI è molto minimalisitica come potete vedere (tra l'altro avvia anche senza DSDT custom) iMac11,2.zip

Ciao, ho visto la EFI che mi hai girato, ha delle kext che non mi permettono di avviare (come Lilu, difatti avvio senza, solo con FakeSMC+RealtekRTL8111 per la rete) ho tentato cambiando a partire da questa qui: EFI.zip aggiungendo ReleaseUSBOwnership = True Le usb sono questi controller qui (da Clover):

il prodotto è stato venduto, è possibile chiudere il topic

Buonasera a tutti, dagli ultimi commit fatti da PMHeart sul repository di OpenCore, abbiamo un ordine preciso (e aggiornato) di quello che è l'ordine di caricamento delle kexts: Molto probabilmente siccome è implementato in OCvalidate, farà la verifica lui stesso in base a questo ordine KEXT_PRECEDENCE mKextPrecedence[] = { { "VirtualSMC.kext", "Lilu.kext" }, { "WhateverGreen.kext", "Lilu.kext" }, { "SMCBatteryManager.kext", "VirtualSMC.kext" }, { "SMCDellSensors.kext", "VirtualSMC.kext" }, { "SMCLightSensor.kext", "VirtualSMC.kext" }, { "SMCProcessor.kext", "VirtualSMC.kext" }, { "SMCSuperIO.kext", "VirtualSMC.kext" }, { "AppleALC.kext", "Lilu.kext" }, { "AirportBrcmFixup.kext", "Lilu.kext" }, { "BrightnessKeys.kext", "Lilu.kext" }, { "CpuTscSync.kext", "Lilu.kext" }, { "CPUFriend.kext", "Lilu.kext" }, { "CPUFriendDataProvider.kext", "CPUFriend.kext" }, { "DebugEnhancer.kext", "Lilu.kext" }, { "HibernationFixup.kext", "Lilu.kext" }, { "NVMeFix.kext", "Lilu.kext" }, { "RestrictEvents.kext", "Lilu.kext" }, { "RTCMemoryFixup.kext", "Lilu.kext" }, { "VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Keyboard.kext", "VoodooPS2Controller.kext" }, { "VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Mouse.kext", "VoodooPS2Controller.kext" }, { "VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Trackpad.kext", "VoodooPS2Controller.kext" }, }; fonte: https://github.com/acidanthera/OpenCorePkg/blob/7a569d7d7a5c48b7de5a21b1a12dd3527e58c816/Utilities/ocvalidate/KextInfo.c#L20-L42

Ahi, su IM ci sono altri utenti che hanno avuto conseguenze da ciò sulle loro build? btw, opinione personale, se si vuole andare di AMD, con tutti questi problemi e senza supporto ufficiale da parte di acidanthera, a me personalmente dà sempre l'impressione di qualcosa che ha sempre dei problemi anche grossi (e.g. non avvii, sacrifichi performance per avere l'audio, adobe che è broken, pm non nativo...) Se era una build per giocare ok, altrimenti se l'ha presa solo per usare macOS, eviterei di cercare di fare arrampicare pesci su degli alberi ecco

È possibile fare dei test nvram con il classico metodo? Poi mi chiedo, come mai il secondo errore riguardo ad APFS? Com'è stato formattato il disco?

Strano che su AMD ci siano problemi di Kaslr, avevo sentito di problemi con le regioni e mmio ma quasi mai di kaslr, (frecciatina: AMD mi stupisce sempre 😄 ) Vedendo gli errori in basso, leggo: efi-boot-device is not set disk is not convertible to APFS, you may not install to this volume because it is not convertible to Apple File System (APFS) Tried to remove quarantine bit for /Volumes/macOS Base System 1 Domanda, Catalina è stato installato in passato oppure è una prima volta?

Da molto tempo utilizziamo filesystem HFS+ per poter avviare la Recovery o la USB, e finora per avere un'esperienza di avvio decente avevavmo bisogno di utilizzare driver come HFS+, purtroppo closed source Qui sul forum è presente un topic che colleziona un version control delle differenti versioni di quel driver (e delle sue diverse provenienze): https://www.macos86.it/topic/2328-driver-uefi-nuovo-hfsplusefi/?tab=comments#comment-59064 Il team acidanthera l'aveva segnalato già da tempo che quel driver non era il massimo: https://github.com/acidanthera/bugtracker/issues/659 finalmente è in arrivo un driver open source che (probabilmente) sarà meglio di quelli attuale, e (speriamo) migliore di VboxHfs.efi https://github.com/acidanthera/OpenCorePkg/pull/177 Per chi fosse interessato a testare, (N.B. farlo con avvio USB, così si fa sicuramente su un filesystem HFS, perché se si ha Big Sur la recovery non è in HFS, ma in APFS) rilascio una build fatta poco fa P.S: se si vuole testare la velocità di avvio rispetto a HFS+, farlo con test analoghi, per esempio se si avvia con HfsPlus.efi di acidanthera la USB, allora usate FswHfsPlus.efi paragonandolo su avvio USB, se si vuole testare i tempi di avvio della recovery di Catalina, fare lo stesso test prima con HfsPlus.efi, misurare il tempo, e poi rifare lo stesso con FswHfsPlus.efi FswHfsPlus.efi-RELEASE.zip FswHfsPlus.efi-DEBUG.zip

Il decompilatore (o il compilatore) si "dimentica" di alcune external references immesse, semmai poi lo segnalo ad acpica sul loro repository Quelle che non vengono mantenute nel processo di compilazione/decompilazione, sono LPC0.EC0, LPCB.EC0, ECDV ed H_EC Tuttavia queste aggiunte che ho fatto sopravvivono al processo di compilazione/decompilazione, non risultando più come "Illegal forward references" tra cui: External (_SB_.PCI0.IMEI, DeviceObj) External (_SB_.PCI0.LPCB.PMCR, DeviceObj) External (_SB_.PCI0.LPCB.EC__, DeviceObj) External (_SB_.PC00.LPC0.EC__, DeviceObj) sono quelle che non danno più problemi Prima: (8 errors) Dopo: (4 errors)

pensavo di fare una cosa gradita dal momento che queste external references che sono presenti anche nell'SSDT originale immagino abbiano lo stesso ruolo delle aggiunte che ho fatto...

Aggiornamento: Dagli ultimi update di iasl, se mancano le External reference sui metodi _STA, il compiler si lamenta e li tratta come errori (non come warnings) Ho aggiunto le mancanti external references qui, ovviamente corretta con l'ultima versione di iasl Poi riguardo ad _ADR o _HID di PLNF, come sul repository di OpenCore, ho commentato _ADR Dopo la modifica: SSDT-Basic.dsl.zip

Oi grazie mille per la risposta, ho rivisto il topic solo ora. Questo fine settimana se tutto va bene penso di provare Le modifiche che contiene quella che hai girato sopra, sono solo su USBOwnership oppure hai aggiunto altro?

Penso di si, perché si basa su BCM94360CS2 Link: https://dortania.github.io/Wireless-Buyers-Guide/types-of-wireless-card/pcie.html

yes ho sempre avuto il file "boot" aka MBR sulla USB da cui avviato Certo, potrei controllare per prendere spunto Il motivo per cui EUSB ed USBE non compaiono con OC, sebbene siano native con Clover, mi è ancora sconosciuto

Ho aperto un issue su bugtracker, sperando che rispondano https://github.com/acidanthera/bugtracker/issues/1398 Poi penso di poter allegare quando possibile anche dei logs di OpenCore se li chiedono

Se lo fai per divertimento, giocaci pure, se ti serve la stabilità/performance, lo sconsiglio, specialmente con quell'integrata li che dubito sia supportata

Ricorda un po' Windows update...

Quindi è tutto normale? Succede a tutti? Dispiace un po' che ci sia poca trasparenza sotto questo punto di vista, soprattutto per chi magari al posto di una connessione gigabit ha connessioni dati limitate, e il fatto che vengano scaricati dati all'insaputa dell'utente mi irrita un po' Sarebbe bello in un mondo utopistico, un macOS che informa l'utente in base a quello che deve fare, e che non sia sempre l'utente a dover "domare" la macchina, a volte anche invano

Buongiono a tutti, mentre sono su 11.1 20C69 ho notato che anche in idle si mette a scaricare della roba non richiesta, senza che abbia servizi attivi come iCloud (mai avuto e mai lo avrò), o altri servizi di sincronizzazione: eseguendo: sudo lsof | grep nsurl Riesco a vedere cosa sta effettivamente facendo/scaricando... Ecco a voi i risultati Pochi secondi dopo... Gli piace scaricarsi tutti gli update del firmware di tutto il cucuzzaio dei mac esistenti... e sinceramente non ho capito il perché Addirittura macbook air 7.1

@carlo_67 mi sembra di aver visto qualche tempo fa che usavi opencore su una vecchia p5, che per caso hai qualche idea a riguardo?