314TeR

Raczej masz obraz z aplikacją Install macOS a nie obraz do instalacji z USB. Dopiero tę aplikacje musisz przerobić do formatu kompatybilnego. Opis masz e poradniku do instalacji 10.12, to się tak samo robi.

Etap wstępny masz połowicznie ogarnięty - to znaczy Clovera masz mniej więcej ogarniętego ponieważ pokazuje właściwą tapetę. Zastanawia mnie czemu nie widzi Ci drugiego pendrive z instalacją systemu. Sprawdziłeś inne porty USB?

Standardowe pytanie ustalające - ile na raz monitorów może obsłużyć ta konkretna VEGA? Sprawdzałeś czy w Windows działa tak jak oczekujesz? W macOS zawsze miałeś na stałe zdefiniowane układy wyjść w sterownikach do VGA ATI/AMD - może nie pokrywa się układ wyjść w Twojej VGA z tym co jest w sterownikach? Takie oczywiste oczywistości jak dane SMBIOS itp są zgodne z sprzętem?

Coś tam mi dzwoni w głowie (ale zaznaczam, że nie pamiętam na 100%), że przy płytach Gigabyte pod Sandy Bridge NIE mających BIOSów UEFI trzeba było nanosić poprawki DSDT. Ten Unitek Y-7509 - to karta Ethernet na PCI-E - korzystasz z niej bo pokładowa nie działa? Pokładowa jest do odpalenia w macOS. Sprawdź na jakim układzie jest ten Unitek Y-7509 - możliwe że jest na jakimś kompatybilnym z macOS.

Mało tego - ja to widzę jako prostą drogę do zrobienia np OEM.plist w której będzie prosta droga do zrobienia uniwersalnego bootloadera (zreplikowania funkcjonalności OEM z Clovera). OEM.plist może zawierać definicja BOARD (np Z97-XYZ) -> Config_Z97-XYZ. Dzięki takiemu podejściu NIE musisz stosować osobnych katalogów do osobnych płyt a w nich tych samych kextów po 30 razy. Wystarczy 1 kext na cały bootloader bez względu na to ile configów będziemy mieli. Ogólnie podejście NIE ładujemy nic z automatu jest jak najbardziej słuszne. Przy logice Clovera można było wielokrotnie się pogubić. Konieczność posiadania kextów w danych katalogach 10.11, 10.12 10.13 itd... Mi się podoba założenie - NIE ma w configu NIE ładuje się. Nie przesadzajmy - robiąc config wystarczy np w konsoli zrobić cd (i myszką przeciągnąć folder) aby wyświetliła się ścieżka. Zaznaczyć stosowną część CMD+C i CMD+V i po sprawie. Owszem troszkę więcej pracy niż wrzucanie bezmyślnie kexta - ale TYLKO to raz się robi.

Przeczytaj poniższy fragment, potem odszukaj w dokumentacji sekcje których używałem i popatrz co one robią. Na 100% dogadasz się z configiem i logo będzie tak jak powinno być na macOS.

Szczerze? Na tym etapie to wg mnie nie ma sensu. Czemu? Bo OpenCore dość dynamicznie się zmienia i każda nowa wersja np 0.5.0, 0.5.1 i obecna 0.5.2 wprowadza zmiany dość istotne i do składni i w ogóle pojawiają się nowe opcje. Poradnik jest z głową opisany i wystarczy użyć tej wkładki między uszami aby w parędziesiąt minut zrobić sobie samemu wsad. Jak przygotujesz gotowca, to zwalniasz z myślenia ludzi. W przyszłości jak składnia się co nieco wyklaruje i ustabilizuje to można będzie przygotować gotowce. Mi samemu nie bardzo się chce przygotowywać pod inne platformy, bo pracy raz że jednak jest sporo, a bez dostępu do sprzętu ciężko weryfikować i dopieszczać. Zresztą zobacz jaki jest odzew w tym wątku. 12 poprań przez 4-ry dni z czego odpisało 2 stałych bywalców.

Powinno dać się odpalić w pełni macOS. Aczkolwiek maks 10.13.6 ze względu na VGA. Karty sieciowej nie znam, na jakim jest chipsecie? Czy ta płyta ma już BIOS UEFI czy jeszcze legacy?

Config jest zrobiony na basie sampla dostarczanego z OpenCore. Najprościej różnice wyłapać otwierając domyślny config i w/w w jakimś programie do porównywania składni i porównać configi. Ja używam do tego BBEdit. Natomiast różnic względem tego co jest opisane w podlinkowanej instrukcji jest niewiele. Głównie są to poprawki do wyświetlania poprawnie trybu tekstowego i graficznego ładowania OpenCore.

Wiem. Wystarczy np dodać tablicę SSDT.aml z konfiguracją portów USB i kabum... wylatuje licencja. Podobnie spoof MAC addressu karty sieciowej - puf i po licencji. Tylko bez paniki - po prostu po odpaleniu Windows z OpenCore pyszczy on, że nie został aktywowany. Odpalenie go bezpośrednio z BIOS jest OK i jest aktywowany.

Rozumiem idee i co masz na myśli, i ją bardzo mocno wyznaję. Z takiego powodu właśnie powstał UniBootX, nie po to aby było skomplikowanie, ale po to aby skomplikowaną czynność jak tworzenie zestawu startowego sprowadzić do paru niezbędnych czynności. Moja wypowiedź jest tożsama tylko do tego szczególnego wypadku OC i OCC. W obu wypadkach i tak aby cokolwiek wprowadzić, musisz wiedzieć co wprowadzasz. W OpenCore jeszcze większy jest na to położony nacisk, ale ułatwia to świetna dokumentacja. Taki konfigurator to front end do jakiegoś configu. Tu aby cokolwiek zrobić i tak musisz mieć bazę i to najlepiej zbliżoną do posiadanego sprzętu wypadku. W obu konfiguratorach NIE da się zbudować configu od zera. D;atego uważam, że te programy są świetne, ale w praktyce ułatwiają głównie początkującym użytkownikom zapoznanie się i wprowadzenie zmian. Zaawansowany użytkownik szybciej okiełzna taki config wspomagając się zwykłym edytorem pilnującym składni XML jak np PlistEdit, niż w CC/OCC. OC i OCC to klikacz, żeby np zdublować jakiś wpis, musisz wpierw dodać wiersz (+), potem wpisać w kolumnę A, potem B, potem C, potem D... ufff następny wiersz, kiedy to w PlistEdit robisz CMD+C-->CMD+V i zmieniasz tylko to co potrzeba. Nie wierzysz, spróbuj wpisać "z ręki" chociaż 3, 4 wiersze w patchach do USB jak wyjdzie nowy system i będziesz musiał dodać wpisy dla nowej wersji kernela. Ale żeby nie tylko narzekać a coś sprawdzić odpaliłem przed chwilą OCC i sprawdziłem co robi. Ogólnie nie jest źle, aczkolwiek niestety są drobne błędy. Najpoważniejszy to samodzielna zamiana wpisu: <key>ConsoleBehaviourOs</key> <string>ForceGraphics</string> na <key>ConsoleBehaviourOs</key> <string>ForceText</string> Druga rzecz - to zrobienie lekkiego bałaganu w sekcji PlatformInfo - Oprócz istniejącej sekcji Generic jak jest pokazane w dokumentacji, OCC pododawał sam z siebie sekcje DataHub, PlatformNVRAM, SMBIOS z zdublowanymi danymi z Generic. Tu zaznaczam, że trzeba się zapoznać z dokumentacją co te sekcje robią, bo są powielone SNy czy MLB, etc... trzeba się dowiedzieć, która sekcja za co odpowiada, bo być może te działanie ma sens którego obecnie ja nie znam. Poza tym nie podoba mi się, że OCC usuwa wszystkie klucze których wartość jest NULL. Ja osobiście wolę mieć klucz i wartość NULL, ponieważ jak będę potrzebował dodać wartość do klucza, to nie muszę wpierw dodawać klucza, szukać gdzie on powinien być, jak się nazywa itp itd. Jak jakiś klucz w configu jest to niech on zostanie. Tu widać, że autor/autorzy OCC stawiają na swoją logikę i do takiego zachowania CC i OCC najbardziej mam zastrzeżenia.

Inaczej - bo faktycznie moja wypowiedź wygląda jakbym siał jakimś defetyzmem. Jeszcze raz od początku. OpenCore i Clover Configurator to narzędzie ułatwiające początkującym użytkownikom ogarnięcie skomplikowanych configów w formacie XML. Zwalniają one przede wszystkim z znajomości składni XML a wiec i popełnienie potencjalnych błędów technicznych składni jak i merytorycznych. Niestety te programy obsługują parametry takie jakie zaprogramuje im autor tej aplikacji. Jeśli składnia jakiegoś parametru się zmieni, zostanie dodana lub usunięta to OCC/CC musi te zmiany uwzględniać. Tu niestety nie jest tak pięknie. Nawet dla znanego od lat Clovera CC nie wspiera wszystkich parametrów. Podobnie może być dla OpenCore o czym uprzedzają autorzy którzy testowali tę aplikację. Nie mniej autor OC Configuratora wciąż nad nim pracuje i jest dynamicznie rozwijany. Jakiś miesiąc temu OC Configurator wspierał wersje 0.0.x kiedy były już 0.5.0 i 0.5.1. Dziś widzę, że wspiera już 0.5.2. Być może już moje słowa i autorów OC dotyczące psucia składni są nieaktualne. Nie mniej OpenCore się dynamicznie rozwija i paradoksalnie bezpieczniej wziąć przykładowy config i go poprawić ręcznie. I to najlepsze wyjście i paradoksalnie takie podejście jest o wiele prostsze niż z Cloverem. Zasadniczą różnicą takiego podejścia jest to, że przykładowy config z clovera jest sieczką, a przykładowy config z OpenCore jest bardzo logicznie poukładany i paradoksalnie dostosowanie do naszych potrzeb sampla OpenCore jest o wiele prostsze niż sampla Clovera. Na dziś najlepiej edycję configu z OpenCore polecam robić jakimś edytorem XML podpierając się dokumentacją dostarczoną z OpenCore. Przed użyciem OCC zrobić kopie, sprawdzać, czy coś nie uciekło. Szybko i wygodnie porównać 2 pliki można w np BBEdit.

A może wpisały Ci się jakieś śmieci do NVRAM/BIOSu gdzie są ustawienia do wybudzania z ACPI. Spróbuj przeflashować BIOS od zera.

OC Configurator nie jest w pełni kompatybilny z aktualnymi wersjami OpenCore - nawet autorzy OpenCore ostrzegają! W większości wypadków psuje config.plist. Uważajcie co robi!

Power Nap wyłączone? Budzenie przy dostępnie przez sieć też?