本文關鍵字：無顯驅vesa方式驅動osx10.14,mojave vga黑屏，云主機的顯示器，非n非a卡黑果，waitting for root device，apfs modules stop 1432,appleexclude.kext，can't determine on the same uuid,qemu virtual display,qemu vga glitch，starting darwin x86就黑屏, osx cascadelake 黑屏, 變色龍 skylake 黑屏

在前面5篇系列文章中，我們講到了云上裝黑果的基礎工作和碰到的前置調試問題，我們采取的是用本地盡可能接近阿里云參數的情況下模擬鏡像在阿里云端可安裝運行（安裝鏡像/安裝，安裝后鏡像/運行）的測試路徑，假設這些工作完成之后，就可能肯定基本離成功在阿里云輕量上運行黑果這個目標很接近了，文1到文5中間做的都是順利的準備工作，除了準備鏡像都是前置啟動故障排解，文章5末尾我們描述的一些1,驅動調試相關的問題和2,虛擬機不黑/輕量云黑屏的特別情況，這些都屬于變色龍啟動后darwin開始接手的地方，屬于后置過程了，進入到機型適配了，被普遍認為是機型適配碰到的BOSS級的問題，本文開始，繼續文5提到的問題排解和調試，其中有一條是在i440fx下我們無法從virtio blk驅動，因此也無法從其中的系統啟動，啟動中出現waitting for root device（我們初步判斷這種問題有可能是前文說的pci功能位不對，也可能往往是驅動加載不正確，啟動不起來，不要動不動就聯系到AppleAHCIPort）。

這是因為文章2-4適配的是安裝后鏡像，是正確的路徑，但到了5我們企圖得到一個安裝鏡像，偏離我們原來的測試路徑，其實，安裝與運行，這二者不能二全，installer鏡像是不含任何virtio和virtualgraphics驅動的，安裝后的鏡像才有，只要我們在qemu配置文章中手動加入功能位，而且使用沒有受破壞的安裝后的鏡像，即，在變色龍啟動完成后的kernel verbose界面保證不出現顯示virtio驅動加載錯誤（如果你強行把virtio,virtgraphics相關和依賴kext丟進E/E或S/L/E，這往往又破壞鏡像加的權限和緩存，照樣會出現apfs modules stop 1432，修復往往不起作用），就可以實現識別virtio blk驅動，從其中啟動的，而cirrus-vga顯卡驅動，在啟動時有花屏，進入系統后卻是可以識別并驅動的（只是是800x600模式的SVGA兼容模式，此模式由VESA為IBM兼容機推出的標準。分辨率為800x600，查看設備為00:02.0 "Class 0300" "1013" "00b8" "1af4" "1100" ，1013 Cirrus Logic，00b8 GD 5446，1af4 1100 QEMU Virtual Machine，這說明virtualgraphic也發揮作用了）

驅動問題并沒有發展到需要patch kext處理顯卡驅動，更沒有涉及到加起QE/CI顯卡加速來，因為我們是云主機無須顯卡加速，但黑屏依然是一個暫時無解的問題，可能是CPU指令集問題，也可能是黑屏與修改edid法修復顯示器參數,dsdt法，但這些都可以作為猜想，都需要慢慢找出問題。

重整理的測試參數

我們重新設計一下測試參數：

創建安裝鏡像cdr:

hdiutil create -o "osxkvminstall10146" -size 8g -layout SPUD -fs HFS+J hdiutil attach "osxkvminstall10146.dmg" -noverify -nomount diskutil partitionDisk disk2 MBR JHFS+ OSXKVMINSTALL R 直接用mbrpatch腳本免Q5Q6，不要手動復制basesystemdmg/s/l/e或pacifist解壓，否則有權限問題，會導致apfs module stop 及時安裝變色龍啟動,這個dmg和cdr卸載后會變成只讀，所以盡早安裝變色龍, hdiutil convert "osxkvminstall10146.dmg" -format UDTO -o "osxkvminstall10146"

創建安裝后鏡像：

dd if=/dev/zero of=osxkvm10146 bs=512 count=52428800 hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount osxkvm10146 diskutil partitionDisk disk2 MBR fat32 BOOT 100M JHFS+ OSXKVM R （mbr的在安裝后的osx不可動態調整因此沒有必要在尾端保留一個osxinstaller，做成osxkvm,osxkvminstall鏡像為一體，用盡25G） fdisk -e /dev/rdisk3,flag 1,write,yes,quit。 在linux中安裝grub2,syslinux,tcpe,wowpc

用這套安裝,按esc進,用cdr上的啟動就可以避免安裝時osxkvm所在卷不可卸載:

qemu-system-x86_64 -enable-kvm -machine pc-q35-2.8 -cpu Penryn,kvm=off,vendor=GenuineIntel -m 5120 -usb -device usb-kbd -device usb-mouse -device ide-drive,bus=ide.2,drive=MacHDD -drive id=MacHDD,if=none,format=raw,file=./osxkvm10146 -device ide-drive,bus=ide.0,drive=MacDVD -drive id=MacDVD,if=none,snapshot=on,file=./osxkvminstall10146.cdr -boot order=dc,menu=on

用這套啟動安裝后的系統，注意去掉了smp，且其中新手動加的pci插槽和功能位,tcpe下lspci就能看到:

qemu-system-x86_64 -enable-kvm -machine pc-i440fx-2.8 -cpu Penryn,kvm=off,vendor=GenuineIntel -m 5120 -device cirrus-vga,bus=pci.0,addr=0x2 -usb -device usb-kbd -device usb-mouse -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=MacHDD -drive id=MacHDD,if=none,cache=writeback,format=raw,file=./osxkvm10146 -device virtio-net-pci,bus=pci.0,addr=0x3,mac='52:54:00:c9:18:27',netdev=MacNET -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper"chameleon.boot.plist中刪掉： <key>UseKernelCache</key> <string>Yes</string>

啟動的時候一定要手動打上UseKernelCache=Yes，否則還是識別不了virtio,-v 可以看到識別了virtio blk，在Rebuild caches after update，early boot complete,continue后會出現：notice - new kext com.apple.driver.kextexcludelist, v14.0.3 matches prelinked kext but can't determine if executables are the same (no uuids)，等漫長的timeout之后(我等了五分鐘)。可進界面（又是漫長的左上角滾動海浪球），下次啟動不會等這么久。

完成！可順利加載virtio和顯卡驅動進入系統，封裝osxkvm10146為gz，上傳到云主機。你可以把那個第一次進入等待過久的過程固化在鏡像中打包，云機中以后就不用等這么久了。

至于如何讓Applevirtio手動變成一個boot time driver集成在install鏡像或osxkvm鏡像中免去使用這個prelinked kernel(一般情況下避免使用prelinked cache,-f是用來強制重新從磁盤s/l/e加載kext跳過緩存的。但并不會重建prelinked緩存，注意把kext與kernel的緩存分開)，我嘗試把kext提到變色龍或s/l/e,權限修復工具，手動修復，kextcache 實現的幾種方法都無效，KCPM Utility Pro，kext utility 2.6.1這類工具無法給離線系統注入kext，更提示無法給恢復系統注入kext和make cache。都沒有成功。

對cache機制的理解：

The kernel is the first component of the operating system to start. It has no other tools available. In particular there is no way to check code signatures, and all file system access is very hard at this point. Apple therefore decided to prelink the bare kernel with all kernel extensions every time the kernel or one of the extensions is updated, and to start only that prelinked kernel at boot time.

Since the prelinked kernel is on a read-only volume, it cannot be updated directly. Apple had to conceive a new mechanism for updates.

When you reboot or shut down your machine, launchd stops all processes. Then it remounts the system volume in read/write mode. This is possible because launchd has the entitlement com.apple.private.apfs.mount-root-writeable-at-shutdown. Then it runs /var/install/shove_kernels to copy the new kernel. But apparently this doesn’t actually work. So to update a kernel extension you need to disable System Integrity Protection or manually trigger a kernel update after booting into macOS Recovery.

Note: This is fixed in macOS 10.15.1

我用的腳本：

#!/bin/sh sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo rm -Rf /S*/L*/PrelinkedKernels/* sudo rm -Rf /S*/L*/Caches/com.apple.kext.caches/* sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U /

驅動解決，也不用考慮安裝鏡像和安裝問題，接下來只需探索黑屏問題。

云主機變色龍黑屏探索1：cpu兼容

我們在上文說到，在云輕量上，變色龍讀取s/l/e，加載完plist和kext中的可執行文件，直到TMsafetyNet.kext ，從這里開始就黑屏了(控制臺可以看到磁盤和CPU都沒有讀寫，應該是halt了。而不僅是虛擬vnc顯示器沒有信號)，我們上文也講到Wait=Yes不起作用，可能也是在執行wait=yes前就黑了，因此我們有必要修改變色龍源碼，在結束-v所有輸出98%內容后輸出starting darwin kernel前（或許是判斷文件名tmsafetynet后），每條輸出都pause一下，看到底在哪里黑屏了。

上面的qemu啟動配置，就cpu和display沒有真正做到與云輕量對應。如果沒有cpu直通，kvm虛擬出來的是vcpu，客戶機看到的是基于 KVM vCPU 的 CPU 核，而 vCPU 作為 QEMU 線程被 Linux 作為普通的線程/輕量級進程調度到物理的 CPU 核上。

進輕量云，tcpe cat /proc/cpuinfo，對于cpu，我們發現CPU是變化的，有時是Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz（Cascadelake），有時卻是：Xeon Platinum 8163（SkyLake），這是一個1C的主機：processor: 0，physical id: 0，siblings: 1，core id: 0，cpu cores : 1，也可以看到它的feature指令集。

我們cpu設為最基本的客戶機 CPU 模型qemu64,把所有的cpu flags都加上。后面加check,enforce來查看與host的比較情況，最后上面的cpu變成：

-cpu qemu64,kvm=off,vendor=GenuineIntel,+fpu,+vme,+de,+pse,+tsc,+msr,+pae,+mce,+cx8,+apic,+sep,+mtrr,+pge,+mca,+cmov,+pat,+pse36,+clflush,+mmx,+fxsr,+sse,+sse2,+ss,+ht,+syscall,+nx,+pdpe1gb,+rdtscp,+lm,+constant_tsc,+rep_good,+nopl,+pni,+pclmulqdq,+ssse3,+fma,+cx16,+pcid,+sse4_1,+sse4_2,+x2apic,+movbe,+popcnt,+tsc_deadline_timer,+aes,+xsave,+avx,+f16c,+rdrand,+hypervisor,+lahf_lm,+abm,+3dnowprefetch,+fsgsbase,+tsc_adjust,+bmi1,+hle,+avx2,+smep,+bmi2,+erms,+invpcid,+rtm,+mpx,+avx512f,+avx512dq,+rdseed,+adx,+smap,+avx512cd,+avx512bw,+avx512vl,+xsaveopt,+xsavec,+xgetbv1,+xsaves,+arat,check,enforce

放在本地啟動，發現2.8的qemu-kvm -cpu help，Qemu Recognized CPUID flags，是不支持以下的： qemu-system-x86_64: Property '.constant_tsc' not found qemu-system-x86_64: Property '.rep_good' not found qemu-system-x86_64: Property '.nopl' not found qemu-system-x86_64: Property '.tsc_deadline_timer' not found

而且，我的主機cpu是不支持以下的（這并不影響什么，只要qemu支持模擬就對我們的實驗結果沒有影響）： warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: host doesn't support requested feature: CPUID.07H:EBX.mpx [bit 14] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512f [bit 16] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512dq [bit 17] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512cd [bit 28] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512bw [bit 30] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512vl [bit 31] warning: host doesn't support requested feature: CPUID.80000001H:EDX.pdpe1gb [bit 26] warning: host doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] warning: host doesn't support requested feature: CPUID.0DH:EAX.xgetbv1 [bit 2] warning: host doesn't support requested feature: CPUID.0DH:EAX.xsaves [bit 3] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 3] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 4] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 5] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 6] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 7]

暫時先在上面的cpu指令集中刪掉以上4條。正常啟動Qemu，果然，這個cpu下發生了黑屏，跟云機表現一致,重新在deepin15編譯qemu高版本，QEMU 3.1.0 in added the Cascadelake-Server CPU,我們下載的4.2.0：

sudo apt install libpixman-1-dev bison flex libsdl2-dev(不加這個會卡在vnc server) ./configure —prefix=/usr —target-list=x86_64-softmmu —enable-sdl make install

cat /usr/share/libvirt/cpu_map.xml |grep Cas -A100，發現有Cascadelake-Server，但是我們不把cpu指定為cascade lake-Server，我們更相信指定具體的指令集，刪掉的4條可以加上了，重新運行qemu，可以運行，但依然會出現host cpu缺失指令集warning，虛擬機表現同樣黑屏，跟云機一致。

看來，這個CPU太先進了，只能嘗試CPUID fix了（如https://www.insanelymac.com/forum/topic/335650-kernelandkextpatches-1013x1014x1015x-x99x299/），就跟處理前面的msrs一樣，變色龍集成了一部分cpu patch，但需要我們做更多工作。不能確定是哪個指令集缺失或什么其它原因導致的問題，多開幾臺不同CPU的云主機試試，或者在本地不斷調整指令集參數作Clear Test測試，然后在相關kext處作patching針對解決。

云主機變色龍黑屏探索2：虛擬顯示器注入

在探索1提到，驅動和顯示器問題可能并不是黑屏的原因(nv_diable讓vesa生效沒用,radvesa沒用，刪s/l/e驅動讓Vesa生效也沒用，一般不必也導致權限問題，resolustion915 fix也不是)。安裝過程中花屏和vnc中glitch現象（https://ostanin.org/2014/02/11/playing-with-mac-os-x-on-kvm/）是24位與36位混亂形成的，但不影響進入系統(想到這里，突然也記起以前用向日控控的時候，筆記本有屏幕，需要拔掉，才能那個網絡界面中顯示,控控對臺機好用自配屏的筆記本不行)。但為了完善我們的測試過程，我們還是考慮可能的顯示器edid問題：

The EDID (Extended display identification data) data structure have all the info of your graphic card and other video sources. EDID是由VESA——視頻電子標準協會定義的，并在1994年和DDC標準1.0版一起推出了1.0版本，qemu也支持以下虛擬顯示器：

-display sdl - Display video output via SDL (usually in a separate graphics window). -display curses - Displays video output via curses. -display none - Do not display video output. This option is different than the -nographic option

• display vnc, 這就是我們云機支持的，

再看幾條爬貼參考：

https://www.tonymacx86.com/threads/black-screen-after-boot-menu.165117/

https://www.tonymacx86.com/threads/guide-general-framebuffer-patching-guide-hdmi-black-screen-problem.269149/

新版本的qemu支持edid，但是云主機的qemu是我們無法控制的。考慮這條方向上的嘗試不實用。總之探索2最好在探索1完成后再進行。

—————

也許我們以后要深度修改變色龍源碼，把usekernelcache固化進變色龍，或加入云專用的kexts，定制一下whatevergreen之類的東西與云主機適配，修改resolustion src為cirrus logic vga所用。盡量避免動到鏡像本身。還有那個msr ingore問題，希望在變色龍端徹底解決：msr 0x35 which qemu/kvm not implemented yet then ..mojave和catalina都越來越大了，未來精簡osx為更小的鏡像比如至僅命令行。據說還有mojave，AppleQEMUHID.kext…

(此處不設回復和更新，點擊GIF掃碼到微信參與留言或獲取資源) 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的windows上dmg转换cdr_云主机装黑果实践（6）：处理云主机上变色龙启动后置过程：驱动和黑屏...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。