wujek_bogdan

Ja nie napisałem, że to rozwiązanie jest złe, chodziło mi o to, że nie wiem czemu ta ścieżka do binarki jest wymagana. Inne bootloadery radzą sobie bez tego. Sądzę, że chodzi o wydajność (bootloader nie musi przeczesywać całego drzewa katalogów), ale pewności nie mam.

Można też sprawdzić następujące rzeczy: Wcisnąć F3 - Clover wtedy powinien pokazać wszystkie dyski, włącznie z ukrytymi. Nie widzę powodu dla którego dysk instalacyjny miałby być ukryty, ale spróbować nie zaszkodzi. Na insanelymac znalazłem poradę aby usunąć plik /Volumes/Install/macOS High Sierra/.IAPhysicalMedia https://www.insanelymac.com/forum/topic/333602-clover-does-not-see-high-sierra-installer/ Sądzę, że ten problem może być specyficzny dla nowej wersji Clovera, która nie jest testowana ze starszymi wersjami OSX.

Nie uznałbym tego za wadę. Zgadzam się, że to nieco wydłuża instalację kextów/driverów, ale z drugiej strony te rzeczy robi się raz, podczas wstępnej konfiguracji. Dzięki takiemu podejściu konfig jest jedynym "źródłem prawdy" - jednoznacznie definiuje konfigurację. Dodatkowo, dzięki definiowaniu kextów w konfigu, możemu je włączać/wyłączać bez usuwania ich z katalogu. Jedyne czego nie rozumiem to to, że poza nazwą kexta należy też podać ścieżkę do pliku wykonywalnego jako parametr ExecutablePath. Inne bootloadery same potrafią zidentyfikować plik wykonywalny. Czyżby chodziło o wydajność? Być może dzięki temu bootloader nie musi przeszukiwać drzewa katalogów wewnątrz kexta? Sądzę, że jeśli w ogóle ma to wpływ na wydajność, to jest on na granicy błędu pomiarowego.

Przede wszystkim sprawdź czy pendrive jest wykrywany poprawnie. Sprawdź preboot.log z podłączonym pendrajwem i bez niego. Listę wykrytych dysków znajdziesz w sekcji ScanVolumes. Druga sprawa: czy na pewno utworzyłeś pendrive poprawnie? Pendrive ma tablicę partycji w formacie GUID?

Tylko tryb tekstowy. GUI pewnie powstanie z czasem, podejrzewam, że autor skupia się teraz bardziej na samym core, a na bajery przyjdzie czas gdy projekt się nieco bardziej ustabilizuje.

Podłącz do innego portu, Sprawdź czy na pewno jest przygotowany zgodnie z instrukcją, Sprawdź czy z innym pendrajwem jest ten sam problem https://hamac.pl/topic/15159-unibootx-clover-nie-widzi-pendrive/

Przygotowałeś i włożyłeś do portu USB pendrive instalacyjny z OSX? Clover powinien wykryć ten dysk instalacyjny i pozwolić ci z niego zbootować.

Masz złą nazwę katalogu. Nazwałeś katalog 2 P67A-UD3 zamiast P67A-UD3. Z tego powodu Clover czyta domyślny konfig z katalogu EFI\CLOVER\config.plist, co z resztą widać w logu preboot.log: 2:522 0:038 EFI\CLOVER\config.plist loaded: Success Swoją drogą, tworzenie katalogu specyficznego dla płyty głównej nie jest konieczne, konfig oraz kexty można wrzucać bezpośrednio w EFI/CLOVER. Nie twierdzę, że masz tak robić - chciałbym tylko żebyś wiedział po co tworzy się katalog dla danej płyty głównej i czym skutkuje brak takiego katalogu. Jeśli katalog istnieje, wtedy Clover używa konfiguracji z tego katalogu. Jeśli katalog nie istnieje, wtedy czytany jest konfig z katalogu głównego.

Jeśli podmieniłeś nazwę katalogu na odpowiadającą nazwie twojej płyty głównej odczytanej z preboot.log to wszystko powinno być OK. Clover powinien więc użyć konfigu z tego katalogu. Jeśli tak nie robi, to znaczy, że gdzieś masz błąd. Wrzuć tutaj: preboot.log konfig Clovera Zrzut ekranu, na którym będzie widoczna struktura katalogów na pendrajwie, z którego bootujesz. Dodatkowo upewnij się, że na pewno bootujesz z tego pendrajwa.

np.: https://www.diffchecker.com/ Swoją drogą, to dziwię się, że w podlinkowanym wyżej opisie, poza opisem konfigów dla różnych platform (za co autorzy mają u mnie wielki plus), nie są załączone gotowe konfigi z zaaplikowanymi zmianami. Bardzo ułatwiłoby to tworzenie własnego konfigu. Zasugeruję dodanie tych konfigów twórcy, czyli @khronokernel. // EDYCJA Warto rzucić okiem na inne repozytoria: https://github.com/khronokernel?tab=repositories m.in.: Lista sprzętu jakiego należy unikać: https://github.com/khronokernel/Anti-Hackintosh-Buyers-Guide Przydatne informacje na temat kart graficznych: https://github.com/khronokernel/Catalina-GPU-Buyers-Guide Informacje na temat kart WiFi: https://github.com/khronokernel/Wifi-Buyers-Guide

Ja jeszcze chwilę poczekam. Sam autor twierdzi, że jest to wersja mocno rozwojowa i zachęca do używania tylko ludzi, którzy rzeczywiście chcą testować nowe narzędzie, podkreślając że nie jest to oprogramowanie do codziennego użytku. Z drugiej strony fakt czy aplikacja jest stabilna czy rozwojowa to w dużej mierze kwestia uznaniowa, bo przecież to autor decyduje o tym w jaki sposób wersjonuje swoją aplikację. Jeden za wersję stabilną uzna zabugowany bubel, a drugi będzie przez lata zwlekał z wypuszczeniem wersji 1.0.0 (przypominam, że taki Gmail przez lata był nazywany wersją beta podczas gdy miał już miliony użytkowników). Widzę natomiast potencjał i podoba mi się bardzo otwarty sposób rozwoju tego bootloadera, podoba mi się to, że ma świetną dokumentację i że jego rozwój jest bardzo dynamiczny. Minęło ledwo kilka miesięcy od ogłoszenia pierwszej publicznej wersji, a wygląda już na całkiem dojrzały produkt. Wierzę więc, że będzie godnym następcą Clovera i prędzej czy później stanie się domyślnym bootloaderem dla hackintosha. Od jakiegoś czasu używam VirtualSMC. Mam zainstalowane pluginy: SMCProcessor.kext oraz SMCSuperIO.kext (zabijcie mnie, ale nie pamiętam do czego służy ten drugi ;)) oraz HWMonitorSMC2 do odczytu temperatur. Działają mi następujące odczyty: Temperatura CPU wyświetla się poprawnie z podziałem na poszczególne rdzenie. CPU Proximity również (domyślam się, że to jest temperatura otoczenia procesora) Prędkość wszystkich 3 wiatraków Napięcia CPU oraz GPU Temperatura GPU Temperatura wszystkich 3 dysków Jedyne co nie działa to prędkość wiatraków GPU, ale nie szukałem rozwiązania, więc być może trzeba doinstalować jakiś plugin.

Dzięki. Dobra robota! Przetestuję gdy będę miał chwilę. Czy możesz napisać, czym są, jak je wygenerowałeś i co robią dodatkowe pliki w katalogu ACPI? Domyślam się, że są to jakieś łatki na ACPI. // Edycja: Znalazłem odpowiedź: https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/config.plist/haswell#acpi Fajnie by było gdybyś mógł napisać co zostało w twoim konfigu zmienione względem bazowego konfigu OpenCore dla Z87/Z97 opisywanego tutaj: https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/config.plist/haswell

Miałem kiedyś podobny problem, w logach również widziałem wtedy komunikat Wake reason: RTC (Alarm) z tym, że w moim przypadku system dodatkowo wieszał się przy próbie wybudzenia: https://hamac.pl/topic/12391-aktualizacja-do-el-capitan-asrock-z87-pro4-gtx960-brak-autosleep#comment-116266 Nie udało mi się znaleźć przyczyny, ale uważam, że problem związany był w jakiś sposób, z ustawieniami zarządzania energią ponieważ udało mi się go przypadkiem rozwiązać grzebiąc w ustawieniach zasilania. Z tym, że to mógł być zupełny zbieg okoliczności. Płyty głównej, na której ten problem występował, nigdy nie udało mi się w pełni okiełznać. Spróbuj przywrócić domyślne ustawienia za pomocą: pmset restoredefaults

Myślę, że prędzej czy później to nastąpi, bo ciągnięcie całego tego długi technologicznego jaki niesie x86 nie ma sensu. Swoją drogą Windows 10 na ARM już jest, tylko aplikacji jak na lekarstwo, a ze sterownikami jeszcze gorzej. W przypadku macOS jest dużo łatwiej, bo to Apple produkuje sprzęt i dba o to, żeby sterowniki do każdego produkowanego sprzętu znalazły się w systemie. MS ma dużo większy problem bo produkuje tylko system. Dlatego sądzę, że Windows, nawet jeśli wersja na ARM się spopularyzuje, to i tak przez długie lata będzie dostępny jeszcze na x86. Czemu tak uważasz? W obu przypadkach: PowerPC → x86 oraz x86 → ARM mamy do czynienia ze zmianą architektury. Chodzi o to, że PowerPC jest łatwiej emulować (ktoś jeszcze pamięta Rosetę?) na x86 niż x86 na ARM? A to ciekawe. Nie zdawałem sobie z tego sprawy. Ale gdy się nad tym zastanowić, to tak musi być, bo wirtualna maszyna nie jest przecież emulatorem - nie potrafi "tłumaczyć" instrukcji pomiędzy różnymi architekturami.

I tu jest właśnie pies pogrzebany, bo Wine, to aplikacja pisana głównie z myślą o Linuksie, fakt, że działa na macOS to miły skutek uboczny. Dzięki pozycji i dzięki temu, że głównie celują w rynek komputerów osobistych. Gdyby celowali też w rynek enterprise (jak Microsoft) to nie mogliby sobie na to pozwolić. Mimo wszystko trzeba przyznać, że mają jaja bo rezygnacja z 32 bitów i tak jest niczym w porównaniu do rewolucji jaką zrobili lata temu gdy zupełnie zmienili architekturę systemu (z PowerPC na x86) - to było bardzo ryzykowne posunięcie.

Nawet jeśli odblokuje się w ten sposób obsługę aplikacji 32-bitowych, to nadal nie będą one działać (albo nie będą działać wszystkie), bo z systemu zostały usunięte różne 32-bitowe biblioteki, które mogą być przez te aplikacje wymagane, więc trzeba by było je przywrócić kopiując je ze starszych wersji systemu. Dodatkowo to rozwiązanie wymaga dostępu do roota i modyfikacji argumentów przekazywanych do bootloadera. Tak więc twórcy Wine na pewno z tego nie skorzystają. W podlinkowanym wyżej wpisie na blogu CrossOver jest w skrócie opisane jakiej techniki chcą użyć aby sprawić, żeby Wine znowu działało na macOS. Prędzej czy później i tak trzeba to będzie zrobić. Na hacku jeszcze nie aktualizuję, wstrzymam się pewnie do wersji 10.15.2 albo 10.15.3. Na razie zaktualizowałem system tylko na MacBooku.

Właśnie na własnej skórze się przekonałem, że po aktualizacji do 10.15 przestało działać Wine i nic nie wskazuje na to, żeby miało się to zmienić w najbliższej przyszłości Dzieje się tak ponieważ Wine jest aplikacją 32-bitową - a te nie uruchamiają się już na 10.15. Od teraz system obsługuje jedynie aplikacje 64-bitowe. Dyskusja na forum Wine: https://forum.winehq.org/viewtopic.php?t=32590 Post na stronie CodeWeavers (twórcy CrossOver): https://www.codeweavers.com/about/blogs/jschmid/2019/9/10/so-we-dont-have-a-solution-for-catalinayet

Śledzę rozwój OpenCore i uważam, że jeszcze jest trochę za wcześnie na migrację, zbyt dużo się tam dzieje jak na razie. Sam autor nie zaleca migracji podkreślając, że OC jest obecnie w fazie rozwoju. Nie jest to nawet wersja alpha. Z drugiej strony OC jest już w pełni funkcjonalny, więc jeśli komuś nie przeszkadza, że podczas apdejtów mogą się pojawić niespodzianki, to jak najbardziej można tego bootloadera używać.

Jeśli uda ci się znaleźć to weź MSI Gaming X RX 580, jest cichsza i jednocześnie chłodniejsza.

A coś jest nie tak z popularnym, również w linuksowym świecie, driverem ntfs-3g? btw, jeśli chcemy mieć bezproblemową wymianę danych między macOS a Windowsem to najlepiej sformatować partycję (jeśli nie jest to partycja systemowa) w exFAT - to system plików wywodzący się z Fat32, ale w przeciwieństwie do niego nie ma śmiesznego ograniczenia rozmiaru pliku do 4GB. Odczyt i zapis działa bez żadnej konfiguracji w macOS i pod Windows.

Taki mały offtopic. W Ubuntu (gdzieś w okolicach wersji 6.x) była kiedyś śmieszna wtopa w polskim tłumaczeniu. Dyski w menadżerze plików były podpisane "Głośność". Ktoś musiał przeoczyć kontekst tłumacząc słowo "Volume"

To wrzuć konfig i listę kextów. Może komuś się przyda. // edycja Widzę, że już wrzuciłeś

Nie bardzo rozumiem co masz na myśli pisząc "partycje wietualne. Z tego co piszesz wynika, że nie są to są normalne partycje, z tym że system maskuje ten fakt, zapewne tworząc zwykłe dowiązania/dowiązania symboliczne.

Jak to wygląda w praktyce? Dzieje się to transparentnie, bez wiedzy użytkownika, podczas aktualizacji, czy mamy wpływ na rozmiar tych partycji?

Do tego co napisałeś wyżej warto dodać jeszcze jedną informację. Nasz forumowy Bootloader UnibootX Clover ma OsxAptioFix3Drv w sekcji DisableDrivers. Tak więc po aktualizacji Clovera, który zastępuje AptioMemoryFix driverem OsxAptioFix3Drv mamy problem ponieważ żaden AptioFix nie zostanie załadowany. Trzeba albo ten wpis usunąć, albo przywrócić AptioMemoryFix. AptioMemoryFix można pobrać ze zarchiwizowanego repozytorium: https://github.com/acidanthera/AptioFixPkg/releases Driver co prawda nie jest już rozwijany ale i tak jest nowszy niż OsxAptioFix3Drv, więc nie widzę powodu żeby używać OsxAptioFix3Drv.