OC0.7.0~0.7.4 常見問題彙整(已解決)

前言:

本文章是針對使用OC引導用戶,遇到引導的問題而彙整,希望藉此收集問題找到相對應的解方。社長最近得知OC從0.7以後版本,有新增的功能,但總是可能會影響系統的安裝或是調整,請大家踴躍發言,藉此找出答案。同時也會登載於網站。

Acidanthera 各版本簡易說明

OC0.7.4:

此更新為 macOS 12 提供全面支持,我們預計將於今年秋季推出。請確保刷新您的設置並儘量避免儘早更新關鍵任務系統,以避免像往常一樣出現意外。在顯著的引導加載程序更改中有 Apple Secure Boot 改進,它解決了 macOS Monterey 安裝和更新問題、Linux 引導錯誤修復和改進的文檔以更好地與 Linux 發行版兼容,以及修復舊硬件的問題。對於我們的kext包括其被發現的英特爾冰湖改進@ kingo132和@ m0d16l14n1和貢獻的@ 0xFirewolf到WhateverGreen。此外,更多的兼容性更新CPUTscSync通過@ lvs1974,在VoodooPS2回歸修復由@ 1Revenger1,並通過MacHyperVSupport網絡支持@ Goldfish64。

0.7.3:

OC開發團隊在這個月結束了假期,但在這版本有一些特別的東西要呈現。長期以來,Linux 支持是 OpenCore 中的一個灰色地帶。它起作用了,我們修復了報告的問題,而當它不起作用時。但是,無論是內置的還是閃亮的 OpenCanopy,都需要執行大量的工作才能使 Linux 本地顯示在 OpenCore 引導選擇器中。

今年秋天,這種情況終於改變了。在 OpenCore 0.7.3 中,我們提供了 OpenLinuxBoot.efi 驅動程序的預覽版,它為 OpenCore 提供一流的 Linux 支持,而無需像 GRUB 或 rEFInd 那樣需要任何鍊式加載。@MikeBeaton在這方面做得非常出色。他的驅動程序支持各種發行版,包括blspec兼容性、其他安裝類型/方案的自動檢測,甚至是特別特殊設置的手動配置。在參考手冊以及PR的討論中,有一個關於如何使用它的綜合部分。

雖然到目前為止我們已經獲得了積極的體驗,但我們仍然必須警告您,驅動程序剛剛著陸並且仍處於測試階段。在其他引導加載程序更改中,有幾個穩定性修復程序,@mhaeuser提供的舊硬件的新怪癖,以及@MikhailKrichanov 的安全改進。至於驅動程序,感謝@0xFireWolf,WhateverGreen 獲得了期待已久的英特爾 GPU 背光平滑支持。經過@Goldfish64數月的努力,AppleALC 和 VirtualSMC 現在首次可用於 32 位 macOS 版本,最高可達 10.4。為了添加更多內容,VoodooPS2 還獲得了對觸摸板多路復用器的支持,這要歸功於@1Revenger1。

0.7.2:

隨著假期的進行,OC開發團隊仍繼續為所有產品提供小更新,以提高整體穩定性和兼容性。為了要了解安全的重要性,我們所有的產品都以安全為核心。在此版本中,OpenCore 通過引入堆棧金絲雀支持,變得更加防篡改,感謝@MikhailKrichanov。

此外,我們修復了 macOS 12 Apple Secure Boot 兼容性。作為附帶措施,我們棄用了對 macOS 10.15 及更早版本的 Apple Secure Boot 支持,並使用默認首選項。主要原因是這些操作系統沒有像 macOS 11 及更高版本那樣的高級保護措施,例如根卷身份驗證。要繼續在較舊的操作系統上使用 Apple Secure Boot,需要j137在SecureBootModel參數,但該值將與MacOS的12類似於蘋果不工作的安全引導,驅動有源電力濾波器驗證要求也被撞的MacOS 11和更新,因此需要一個改變MinDate,並MinVersion在有源電力濾波器節中,如果較老版本的MacOS需要推出.在內核方面,@Goldfish64率先支持 32 位內核擴展,將 Lilu、VirtualSMC 和 SMCBatteryManager 兼容性擴展到 macOS 10.4 及更高版本。我們將繼續擴展舊版 macOS 的兼容性,以幫助開發人員在各種配置上測試他們的軟件。

WhatGreen 獲得了對 AMD 卡的設備 ID 欺騙支持,讓更新的 RX 6900 GPU 運行起來沒有任何麻煩。RestrictEvents 變得更加可配置,並獲得了一些小改進,以更好地與 macOS 10.15 及更早版本兼容。

0.7.1:

很高興看到我們繼續推進另一個 macOS 迭代,為我們去年看到的重大改革帶來穩定性。macOS 12 與我們所經歷的相比是一個全面的積極變化,因為它修復了相當多的錯誤並帶來了相當少的棄用,在表面上帶來了幾個新功能而在後台幾乎沒有變化。另一件事是 Windows,我們的許多用戶都依賴它,它的新版本具有新的系統要求。正如你們大多數人所注意到的,OpenCore 0.7.0 在 macOS 12 和 Windows 11 上都可以正常工作,在正常情況下沒有任何特殊變化。

對於 macOS,需要解決一些細微的差別。一些怪癖壞了(例如ProvideCurrentCpuInfo或PowerTimeoutKernelPanic),我們修復了它們。SMBIOS 標識符也更新了,我們同步了我們的數據庫。由於@MikeBeaton細心的眼睛,除了修復某些設置中發現的一些問題外,還更新了 OpenCanopy 風味建議。為了幫助在較新的硬件設置上識別和診斷硬件,@PMheart在 SysReport OpenCore 功能中包含了 CPU MSR 和 PCI 設備信息。對於 Windows 11,我們提供了一份文檔,概述了要求和解決這些問題的潛在途徑,希望避免任何未來的誤解。

除此之外,我們創建了一個名為 的新工具,TpmInfo它可以幫助每個人了解有關固件 TPM 的英特爾硬件功能。時間會證明我們是否可以找到在 OpenCore 中模擬 Windows 11 請求的某些功能的資源,但這不是我們目前的優先事項,因為幾乎所有後 Skylake 系統都兼容,只有 8 歲的系統會選擇需要仿真。提醒一下,請注意,任何系統都需要有UEFI 安全啟動已啟用功能以正確支持 Windows 11。OpenCore 完全支持此功能已有一段時間,並且所有說明都已包含在 OpenCore 參考手冊的相應部分中。我們稍後將發布更易於遵循的 Dortania 指南。在內核方面,有幾個非常重要的變化。Lilu 獲得了一個全新的 kext 補丁程序,它統一了從 macOS 10.6 到 macOS 12 的所有操作系統的方法,避免了我們之前的許多黑客行為並使我們的 QC 更加可靠。像往常一樣,所有插件都需要更新以支持 macOS 12,我們已經對我們自己的大部分插件進行了更改,這些插件也包含在此更新中。

許多插件現在也支持 macOS 10.6(64 位模式),包括 AppleALC、VirtualSMC、SMCBatteryManager 和 WhateverGreen。所有這些都是@Goldfish64大量工作的結果。經過與@dhinakg 的一些研究我們能夠在 macOS 12 上找到藍牙問題的解決方案,它作為名為 BlueToolFixup 的獨立 kext 登陸。為了按原樣保持更多連續性功能可用,@khronokernel為SidecarFixup帶來了更多補丁,使其擴大對 Mac、Universal Control 等的 AirPlay 支持。

0.7.0:

有三個主要亮點,第一個是 OpenCanopy。我們努力從用戶界面中了解美術師的需求,並儘最大努力以與 OpenCore 架構不矛盾的最佳方式將其集成。通過此更新,OpenCanopy 中出現了一個新的圖標概念。雖然以前的主題僅限於一小部分預定義的圖標名稱,但新引入的風格允許不依賴於 OpenCore 代碼且可由社區維護的任意圖標名稱。第二個:討論的是虛擬機。虛擬機是我們日常工作流程的重要組成部分。那些不直接使用它們的人可能會間接運行它們。這可能是一些不常見的知識,但現代 Windows 將自身作為虛擬機運行. 對於最終用戶來說,這意味著每個現代操作系統都帶有虛擬化堆棧。

Linux 和 macOS 帶有加速器:相應的 Hypervisor.framework 和 KVM。需要有第三方軟件可以利用這些機制來運行虛擬機,例如 VMware 或 QEMU。Windows 附帶一個多合一的解決方案 — Hyper-V。由於 Windows 用戶數量持續增長,我們一致認為必須能夠在 Windows 上安裝帶有內置管理程序的 macOS。因此發布 Goldfish64 實現了 MacHyperVSupport 中的所有基礎知識第三個:對 Z590 平台的持續測試。

隨著越來越多的測試者,發現了更多的新問題,或者說可能性:由於大多數 Z590 闆卡具有 USB 音頻,因此我們構建了一個輕量版的音頻補充驅動程序 — AppleALCU。該驅動程序只有數字音頻補丁,推薦用於這些設置。

許多華碩主板由於某種原因未能在 NVMe SSD 和 GPU 上啟用 ASPM。其結果是一個需要注入pci-aspm-default與<02 00 00 00>值到相關的設備和它們的父橋樑,當未觀察低2位,以修正錯誤。禁用IGPUvia disable-gpu屬性可能還不夠,因為它可能會晚點發生。這可能會導致睡眠中斷或 DRM 問題。要解決一個可以注入class-code與<FF FF FF FF>價值,並name具有”unused”價值。華碩主板使用 ASMedia USB HUB 來拆分 USB 端口(例如 1 到 4),當在 USB 3.x 模式下首次睡眠嘗試時,可能會在睡眠後立即喚醒系統。這個看起來非常隨機,可能是某些特定板的錯誤,但至少可以將其強制為 2.0 模式作為一種解決方法。以上這是OC開發團隊在0.7版本最新的更新說明。

發現錯誤:

最近一個月以來,在編輯config.plist 引導文件時,無論嘗試使用不同的版本,按照教學文章逐一的設定,並再三確認設定值沒有錯誤,仍出現以下錯誤:

  • 卡在EB
  • 可以順利引導到系統、但無法作為安裝使用
  • 跑碼出現Err 錯誤訊息
  • 發現CPU名稱不見了、記憶體訊息不見了、顯卡訊息不見了、序號也不見了USB端口定制跑掉了等等錯誤訊息
  • 硬解失效

所使用的編輯工具有XCode、OCC、ProPteTree、OC-Gen、PlistEdit Pro等等,無論是使用何種工具編輯,失敗的機率非常的高!過去使用這些編輯工具很少有出錯的情形,但自從OC進入0.7版本之後,問題就不斷的出現,直到OC0.7.5版,問題更極為明顯。尤其是OC0.7.2~OC0.7.3更是如此。

OC073:UEFI/Drivers. 設置已改變。

《OC0.7.0~0.7.4 常見問題彙整(已解決)》
OC引導文件差異圖

所以,OC EFI 打從0.7.x版本以後,config.plist 的設置,以過往的版本來看,似乎已無法採用過扁集的方法。因為在編輯config.plist 文件中,很難察覺該文件被工具軟體給修改了,一旦造成了錯誤,該文件很容易引導失敗,甚至失去了許多參數值。

OCAuxiliaryTools

首先要感謝來自中國也是本社團好朋友 Saangmou Poon提出了建言,並告知有套編輯工具軟體 QtOpencoreConfig  ,目前已改為 OCAuxiliaryTools。這套編輯工具供非常強大,目前除了win/mac 版本以外,同時也有 Linux 版本,除了ProPreTree 以外,又多了個可跨平台編輯OC引導文件的好囧。

這套編輯軟體個人去年也曾下載嘗試過,但BUG仍是很多,如今該軟體卻來卻強大,並且受到了OC開發團隊唯一認可的OC引導編輯工具。OCAuxiliaryTools 除了可以使用最新版OC文件,同時也擁有許多SSDT的修護欓、Kext 等等。但最主要的是,當你在編輯config文件時,他有一個可以即時檢測的裝置,一旦該文件有了錯誤,該文件就算是『壞了』。

《OC0.7.0~0.7.4 常見問題彙整(已解決)》
OC驗證

這個OC驗證功能,可以即時告訴你你的config文件編輯錯誤,同時也能快速的知道錯誤訊息。這是我觀察許久所得知的,原本我的做法是透過ACPI Add 模塊、Kext 模塊等等,在不同的OC版本中移植到最新版,過去的作法似乎完全不受影響,但是在OC0.7.x 版本,這樣的方法不管用了,因為很容易就破壞了原本config文件的屬性與結構,既使你設定的值完全正確,一旦運行起來就會出現從未發生過的錯誤訊息。

結論

OC引導文件的編輯方式已改變了,若是真的要繩及,也得病需要具備有修改能力的技能,尤其是作為工作機的用戶,沒事別亂升級。黑蘋果正常運行,避免造成許多無謂的困擾。個人也會盡快針對OC引導編輯教學找出最快適合的方法,寫出一個比較完善教學文章。

点赞
Share