Skocz do zawartości

Czarny ekran po aktualizacji Clovera


Specter
 Udostępnij

Rekomendowane odpowiedzi

Cześć,

 

Próbuje od 2h zaktualizować Clovera z 4334 na najnowszą wersje (4700), żeby zrobić update z 10.13.6 do 10.14 i niezależnie od tego co bym robił, kończy się to czarnym ekranem bez loga Apple i zwisem permanentnym :)

 

Zrobiłem aktualizacje:

1) samego Clovera 

2) kextów - Lilu, WhateverGreen, AppleALC, USBInjectAll

3) driverów 

ogólnie wszystkiego co powinno mi być potrzebne.

 

Sam Clover podnosi się bez problemu, ale systemu już nie odpala, aktualizacji jeszcze nie zrobiłem więc nie wstaje High Sierra - momentalnie blackscreen i zwis bez loga Apple.

 

Walczę z tym od dłuższej chwili, wykluczyłem następujące problemy:

1) złe kexty - przywróciłem stare kexty i to nie pomogło, cofnąłem wersję Clovera na działającą, wrzuciłem nowe kexty bez instalacji nowszego r Clovera - system wstaje na zaktualizowanych w pełni kextach przy Cloverze 4334.

2) złe drivery - kombinowałem na różne sposoby, znalazłem gdzieś w internecie podobny problem, gdzie rozwiązaniem było dorzucenie AptioMemoryFix - u mnie nie pomogło, oraz ApfsDriverLoadera - również nie pomogło. Zresztą mam w swoim configu już apfs.efi oraz OsxAptioFixDrv i OsxAptioFix2Drv (jednocześnie - tak było na UnibootX - to dobrze?) i śmiga na tym stabilnie.

3) zła wersja Clovera - robiłem pierwotnie update do 4700 z Clover Configuratora, później wziąłem 4995 z buildu 314TeRa w dziale o Mojave - na jednym i na drugim dokładnie ten sam efekt.

 

W chwili obecnej mam już zaktualizowane kexty, drivery i ogólnie wszystko, został sam Clover - bootuje z 4334 bez problemu, wystarczy że podmienię sam plik CLOVERX64.efi na ten z 4995 lub 4700 i system przestaje się podnosić. Przywrócenie tego jednego pliku do 4334 powoduje że problem znika :)

Config wzięty z UniBootX i pracowałem dosłownie na stockowym UniBootX pod Z77 z configiem lekko dostosowanym pod mój sprzęt i iMessage.

 

Błąd jaki dostaje na -v widać na zdjęciu, jest to:

ERROR!!! Load prelinked kernel with status (0x80...)
Error loading kernel cache (0x9)

Gdzie popełniam błąd? :)

Dzięki za pomoc.

 

 

post-4093-0-97197400-1539433374_thumb.jpeg

Odnośnik do komentarza
Udostępnij na innych stronach

Nigdzie nie popełniasz błędu. Ostatnią wersją Clovera która działa na komputerze z mojej stopki jest r4658. Późniejsze oficjalne wydania z sf.net powodują dokładnie identyczny objaw jak u Ciebie.

 

r4658 działa

r4674 powoduje zwis od razu w cloverze - tylko migający kursor mam.

 

Przydało by się skompilować wersje pośrednie pomiędzy 4658 do 4674 i zobaczyć która poprawka powoduje ubicie startu systemu, a następnie zgłosić błąd developerom clovera.

Odnośnik do komentarza
Udostępnij na innych stronach

A jednak właśnie rozwiązałem problem. Dla potomnych - może w takim razie się przyda:

 

Clover 4700 w moim przypadku wymagał posprzątania drivers64UEFI i nie chciał wystartować na takim samym zestawie na jakim używałem dotychczas wszystkich wersji do 4334. Gryzły się OsxAptioFixDrv z OsxAptioFix2Drv POMIMO zawarcia tego drugiego w configu w sekcji Disable Drivers.

 

Musiałem usunąć OsxAptioFix2Drv i zostawić wyłącznie jedną wersje drivera czyli w moim przypadku w configu ze stopki jest to OsxAptioFixDrv. O czym w sumie trąbią na lewo i prawo w opisach tych driverów ;) ale wcześniej to działało i wydaje mi się że tak jest wciąż w forumowym bootloaderze UniBootX? 

 

Przy okazji zrobiłem testy wszystkich pozostałych (nowszych i z tego co rozumiem bardziej polecanych bo wciąż rozwijanych?) wersji czyli OsxAptioFix3Drv i AptioInputFix i taki sam error był w każdym przypadku tak długo jak jedynym driverem nie będzie OsxAptioFixDrv.

 

 

Niestety chwilę później pojawił się kolejny problem przy następnym driverze i Clover w ogóle nie chciał mi wystartować, nawet nie ładował interfejsu - z jakiegoś powodu nie działa u mnie ApfsDriverLoader-64.efi, a próbowałem podmienić go 

zgodnie ze znalezioną gdzieś podpowiedzią. Póki w drivers64UEFI nie było starego apfs.efi Clover również w ogóle nie wstawał!

 

 

Właśnie zrobiłem pomyślnie update do 10.14 i zdaje się że wszystko działa stabilnie jak wcześniej, używam Clovera r4700 a w drivers64UEFI mam pliki takie jak w załączniku. Kexty w najnowszych wersjach, ale wydaje mi się że w przypadku tego problemu nie miały nic do gadania :)

 

 

@314Ter - zerknij na swoje drivers64UEFI i sprawdź czy nie masz tam kilku driverów AptioFix bo dokładnie takie same objawy miałem przez długi czas testowania tego na przestrzeni ostatnich dwóch dni :) a wydaje mi się, że właśnie na Twoim configu bazowałem swojego Clovera. 

post-4093-0-36741200-1539527199_thumb.png

Odnośnik do komentarza
Udostępnij na innych stronach

Są 4-ry drivery do "połączenia" UEFI Aptio z macOS:

  1. OsxAptioFixDrv
  2. OsxAptioFix2Drv
  3. OsxAptioFix3Drv
  4. AptioMemoryFix

Oryginalnie zaprojektowane przez team clovera: #1 i #2 są dość stare i od dawna nie rozwijane. #1 i #2 nie uruchamiają zapisu do NVRAM w większości komputerów, a od ~Haswella praktycznie w ogóle nie odpalają NVRAM.

#3 został poprawiony na bazie #2 o zapis do NVRAM jak została odnaleziona przyczyna jego braku, przy czym i tak jego rozwój został porzucony na rzecz #4.

#4 - obecnie jedyne rozwiązanie konieczne do odpalenia macOS na płytach z Aptio. Rozwijane przez vit9696 i jako takie je stosuję od dawna.

 

W configach zawsze stosuję blokadę ładowania driverów #1, #2 i #3, dlatego ładowany jest tylko #4:

<key>DisableDrivers</key>
<array>
  <string>CsmVideoDxe</string>
  <string>DataHubDxe</string>
  <string>DumpUefiCalls</string>
  <string>EmuVariableUefi</string>
  <string>FSInject</string>
  <string>OsxAptioFix2Drv</string>
  <string>OsxAptioFix3Drv</string>
  <string>OsxAptioFixDrv</string>
  <string>OsxLowMemFixDrv</string>
  <string>PartitionDxe</string>
  <string>VBoxHfs</string>
</array>

Jeśli wstaje Ci tylko na #1, to oznacza, że najprawdopodobniej jest błąd w cloverze lub sterownikach #2,#3 i #4 wprowadzony po wersji r4658.

 

Wspomniany przez Ciebie: AptioInputFix służy do zupełnie czegoś innego.

 

Temat wciąż jest nierozwiązany, ponieważ stosowanie sterownika na którym NIE działa NVRAM i który powoduje problemy z ładowaniem sterowników webowych nvidii dla mnie nie jest rozwiązaniem.

 

Tak samo blokada ładowania sterowników MUSI działać. Trzeba sprawdzić log z startu clovera (F2) i zobaczyć które sterowniki są ładowane a które nie. Może faktycznie jest jakiś błąd np w w/w blokadzie a nie sterownikach aptio/cloverze.

Odnośnik do komentarza
Udostępnij na innych stronach

314TeR, jak zwykle doskonale wszystko tłumaczysz i bardzo Ci dziękuje, zawsze dużo dowiaduje się z Twoich postów.

 

Miałem na myśli oczywiście AptioMemoryFix nie AptioInputFix, czyli chodzi o #4 z którym system również nie wstawał. Nie rozumiałem różnic między tymi driverami, teraz sprawa jest dla mnie dużo jaśniejsza.

 

Jednak - jestem prawie pewien, że NVRAM działa w moim przypadku poprawnie na #1, nie jestem pewien czy dobrze identyfikuje jego działanie ale - aktualizacja przeszła pomyślnie, z 10.13.6 do 10.14 przebiegła bezproblemowo i bez mojego udziału - w Cloverze automatycznie bootował się najpierw instalator, a potem sam system bez żadnej mojej ingerencji. Pamięta wybieraną ostatnio partycje po restarcie i bootuje z niej bez problemu. FaceTime i iMessage działają bez przeszkód, ustawienia wszystkie również pamięta. W takiej sytuacji chyba mogę wykluczyć niedziałający NVRAM?

 

Webdrivery Nvidii również nie są dla mnie problemem, bo specjalnie robiąc upgrade glitchującej 660 zakupiłem GTX 780 który jako chyba ostatni działa na natywnym sterowniku systemowym :)

Czy w takiej sytuacji mogę spokojnie zostać na r4700/#1, czy powinienem mimo wszystko cofnąć się do r4658 i spróbować odpalić system na #4?

 

Oprócz tego nie rozumiem - dlaczego wyłączać działanie tych sterowników w DisableDrivers zamiast po prostu usunąć je z drivers64UEFI? Efekt będzie ten sam, prawda?

 

Zastanawia mnie również kwestia apfs.efi vs ApfsDriverLoader-64.efi. Czy dobrze rozumiem, że oba drivery robią to samo tylko drugi jest znacznie nowszy i poleca się jego użycie? Tak jak napisałem, przy załadowanym ApfsDriverLoader-64.efi Clover 4695/4700 u mnie w ogóle nie startował (zarówno z apfs.efi obok jak i bez niego). Partycja systemowa jest u mnie przekonwertowana na APFS. 

 

No i wreszcie - co dokładnie przetestować żeby się przydać? :) mogę wrzucić OsxAptioFixDrv z powrotem do DisableDrivers i spróbować uruchomić system. Jeśli blokowanie działa to nie powinien się podnieść, jeśli wstanie to znaczy że faktycznie problem jest w działaniu tej blokady i to będzie pierwszy trop - czy tak?

Ewentualnie może lepiej nawet - dorzucić do driverów wszystkie pozostałe i wpisać je do blokowanych, powinno wtedy wstać bez żadnych zmian jeśli ta blokada działa poprawnie. Jeśli nie wstanie, to znaczy że trop był dobry i tutaj coś jest nie halo, wtedy zerknąć na logi i szukać potwierdzenia?

Odnośnik do komentarza
Udostępnij na innych stronach

314TeR, jak zwykle doskonale wszystko tłumaczysz i bardzo Ci dziękuje, zawsze dużo dowiaduje się z Twoich postów.

Dziękuję, zawsze miło jest słyszeć takie opinie. :)

 

Miałem na myśli oczywiście AptioMemoryFix nie AptioInputFix, czyli chodzi o #4 z którym system również nie wstawał. Nie rozumiałem różnic między tymi driverami, teraz sprawa jest dla mnie dużo jaśniejsza.

AptioMemoryFix jest obecnie jedynie "słusznym" rozwiązaniem.

 

Jednak - jestem prawie pewien, że NVRAM działa w moim przypadku poprawnie na #1, nie jestem pewien czy dobrze identyfikuje jego działanie ale - aktualizacja przeszła pomyślnie, z 10.13.6 do 10.14 przebiegła bezproblemowo i bez mojego udziału - w Cloverze automatycznie bootował się najpierw instalator, a potem sam system bez żadnej mojej ingerencji. Pamięta wybieraną ostatnio partycje po restarcie i bootuje z niej bez problemu. FaceTime i iMessage działają bez przeszkód, ustawienia wszystkie również pamięta. W takiej sytuacji chyba mogę wykluczyć niedziałający NVRAM?

Nie bardzo. Tu masz jak sprawdzić działanie NVRAM: http://hamac.pl/topic/9672-natywny-zapis-wartości-do-nvram/

Zacznij od PKT 4

 

Webdrivery Nvidii również nie są dla mnie problemem, bo specjalnie robiąc upgrade glitchującej 660 zakupiłem GTX 780 który jako chyba ostatni działa na natywnym sterowniku systemowym :)

Czy w takiej sytuacji mogę spokojnie zostać na r4700/#1, czy powinienem mimo wszystko cofnąć się do r4658 i spróbować odpalić system na #4?

Nie zakładał bym tak. Do startu macOS potrzebny jest pomost pomiędzy UEFI płyty głównej a macOS. U nas najczęściej mamy na płycie UEFI Aptio, więc musimy uzyć któregoś z w/w sterowników od #1 do #4. Obecnie jedynym rozwijanym jest AptioMemoryFix. W przyszłości jak np macOS 10.4.? będzie czegoś nowego wymagał to zmiany trafią tylko do AptioMemoryFix. Jeśli na nim nie działa wstawanie systemu, to warto się tematowi przyjrzeć bliżej i zgłosić problem developerom clovera.

 

 

Oprócz tego nie rozumiem - dlaczego wyłączać działanie tych sterowników w DisableDrivers zamiast po prostu usunąć je z drivers64UEFI? Efekt będzie ten sam, prawda?

Efekt ma być taki, aby sterowniki na liście NIE ładowały się. Owszem skasowanie ich daje dokładnie to samo... tylko co w wypadku jak np za parę miesięcy będziesz musiał zaktualizować clovera, użyjesz instalatora a on Ci wrzuci ponownie sterowniki które skasowałeś? System najprawdopodobniej nie wstanie, a nie o to chodzi aby pamiętać o wszelkich zależnościach, a żeby zrobić pancerny config nie wymagający pamiętania o takich rzeczach. Dodatkowo jak na jednym kluczu chcesz mieć konfiguracje do więcej niż jednej platformy (np UniBootX), to jak załatwisz temat jeśli config A wymaga serownika który gryzie się z configiem B?

 

 

Zastanawia mnie również kwestia apfs.efi vs ApfsDriverLoader-64.efi. Czy dobrze rozumiem, że oba drivery robią to samo tylko drugi jest znacznie nowszy i poleca się jego użycie? Tak jak napisałem, przy załadowanym ApfsDriverLoader-64.efi Clover 4695/4700 u mnie w ogóle nie startował (zarówno z apfs.efi obok jak i bez niego). Partycja systemowa jest u mnie przekonwertowana na APFS.

Aby wystartować macOS, musisz UEFI płyty "dodać" sterownik do systemu plików, a jest to HFSPlus.efi albo apfs.efi. Oba są obligatoryjne aby w ogóle system wstał. Wcześniej HFSPlus w ogóle się nie zminiał, natomiast apfs ciągle ewoluuje i co wersja systemu dostajesz nowy sterownik apfs. Aby wreszcie mieć z głowy problem z ciągle zmieniającym się tym sterownikiem, został stworzony ApfsDriverLoader (notabene też przez autora AptioMemoryFix), który "wciąga" z zainstalowanego macOS przed startem aktualny apfs.efi i go ładuje, aby Clover mógł dalej wystartować macOS.

 

No i wreszcie - co dokładnie przetestować żeby się przydać? :) mogę wrzucić OsxAptioFixDrv z powrotem do DisableDrivers i spróbować uruchomić system. Jeśli blokowanie działa to nie powinien się podnieść, jeśli wstanie to znaczy że faktycznie problem jest w działaniu tej blokady i to będzie pierwszy trop - czy tak?

Ewentualnie może lepiej nawet - dorzucić do driverów wszystkie pozostałe i wpisać je do blokowanych, powinno wtedy wstać bez żadnych zmian jeśli ta blokada działa poprawnie. Jeśli nie wstanie, to znaczy że trop był dobry i tutaj coś jest nie halo, wtedy zerknąć na logi i szukać potwierdzenia?

Zrób sobie klucz USB z Cloverem, configiem i eksperymentuj. Zapisuj logi startowe - preboot.log "F2" w cloverze i obserwuj. Ważne aby znaleźć przyczynę, albo powtarzalną sekwencję którą będzie można przekazać developerom clovera.

Odnośnik do komentarza
Udostępnij na innych stronach

Dodam od siebie, że ja na swoim zabytkowym już Sandy Bridge doświadczam tych samych problemów co kolega Specter.

Jedynym driverem na którym system się podnosi jest OsxAptioFixDrv. Ja już ten problem mam od samego początku - tzn u mnie nawet wersja druga nie podnosiła systemu i  potem każda kolejna tak samo.

Natomiast po upgrade do Mojave doświadczyłem czarnego ekranu Clovera (tzn. nawet nie pojawiał się ekran wyboru dysków) przez nie współpracujący ApfsDriverLoader-64.efi. Musiałem go skasować i wrócić do starej metody z aktualizowaniem apfs.efi ręcznie kopiując go z systemu plików.

Czy AptioMemoryFix w jakiś sposób współpracuje z ApfsDriverLoader? Może Ci którzy nie mogą używać tego pierwszego muszą także uważać na szopki, które mogą się pojawiać w związku z tym drugim.

Odnośnik do komentarza
Udostępnij na innych stronach

Ale moment. Czy to nie jest tak, że to ApfsDriverLoader jest tu problemem? Mam Clover 4695 i wszystko jest ok, system wstaje. Tylko musiałem wyrzucić ApfsDriverLoader i wrzucić aktutalne apfs.efi.

Clover przestał mi się ładować właśnie przez to.

Natomiast jeśli chodzi o OsxAptioFixDrv to tylko na pierwszej wersji ładuje się system, na innych zatrzymuje się zaraz na poczatku na jakimś błędzie Aptio.

Flagi Slide=0 nie mam w configu.

Odnośnik do komentarza
Udostępnij na innych stronach

Wow! 

I ja również dziękuję za wskazówkę. Działa z AptioMemoryFix :D

W sumie już byłem pewien, że to jest tak od zawsze, ale faktycznie kiedyś chyba miałem na stałe ustawione slide=0, a teraz od pewnego czasu już nie.

Widocznie jak jeszcze próbowałem, jak wyszedł AptioMemoryFix to jeszcze flaga była.

Sorry za offtop, ale się przy okazji wyjaśniło.

 

Ciekawe, czy Ci z apfs.efi zadziała. U mnie właśnie to było przyczyną czarnego ekranu Clovera. Coś się we współpracy Mojave z Cloverem w wersji 4569 wzwyż zmieniło chyba, co udaremnia ApfsDriverLoader załadowanie apfs.efi z systemu. Tak to ja odczytałem, więc wróciłem do starej metody.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 3 tygodnie później...

Od dziś testuję najnowszą oficjalną kompilację clovera - r4741 i jak na razie wszystko działa. NVRAM działa, ApfsDriverLoader-64.efi działa i "wyciąga" aktualny apfs.efi z instalacji. 10.12.6 i 10.13.6 wstają, zrobiłem też aktualizację 10.13.6 do najnowszej kompilacji (zainstalowałem security update).

 

Wygląda, że problem został rozwiązany.

Odnośnik do komentarza
Udostępnij na innych stronach

Potwierdzam :) działa też z Mojave i właśnie zrobiłem update do 10.14.1.

 

Clover r4741 wstaje wreszcie na ApfsDriverLoader-64.efi, dłużej walczyłem z AptioMemoryFix - ale rozwiązanie podane przez 314TeR wyżej pomogło, też miałem w configu slide=0 i usunięcie tego parametru spowodowało pomyślne uruchomienie systemu :) 

 

Dla porządku i ostatecznego potwierdzenia, w załączniku wrzucam aktualne drivers64UEFI - sporo z tym grzebałem i mieszałem na przestrzeni ostatniego miesiąca, obecnie wydaje mi się że wygląda tak jak powinno ale chciałbym to potwierdzić - czy któregoś z tych driverów mogę albo powinienem się jeszcze pozbyć, czy to rzeczywiście optymalna lista? Nie używam FileVault więc wydaje mi się, że kilka z tych driverów mógłbym jeszcze skasować - tylko czy ma to w ogóle sens?

System wydaje się działać dobrze i stabilnie ale będę uważnie testował ;) 

post-4093-0-57731900-1541622696.png

Odnośnik do komentarza
Udostępnij na innych stronach

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

Ładowanie
 Udostępnij

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystanie z tej witryny, wymaga zakceptowanie naszych warunków Warunki użytkowania.