big-sur-micropatcher
big-sur-micropatcher copied to clipboard
barrykn
patch-kext.sh not work on iMac 2011
patch-kext.sh not work on iMac 2011 with --2011 --iMac trows error at kmutil
Probably same error on my iMac 13,2 (late 2012) with patcher v0.4.2:
No patch mode specified on command line; defaulting to --2012. Installing kexts to: /
Volume appears to have a Big Sur installation (build 20A5395g). Continuing. Volume is mounted from device: /dev/disk2s5s1 Mounted device is a snapshot. Will now mount underlying volume from device /dev/disk2s5 at temporary mountpoint: /System/Volumes/Update/mnt1
Checking for KernelCollections backup... Backup found, so not overwriting. Beginning patched IO80211Family.kext installation Installing mojave-hybrid WiFi patch Using kmutil to rebuild boot collection... Using kmutil to rebuild system collection... Copying deferred prelinked kernels in /System/Volumes/Update/mnt1... /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/kext_tools/kext_tools-692.40.7/kc_staging.m.279: Encountered error while inspecting path: Error Domain=NSCocoaErrorDomain Code=260 "The folder “PrelinkedKernels” doesn’t exist." UserInfo={NSFilePath=/System/Volumes/Update/mnt1/Library/Apple/System/Library/PrelinkedKernels, NSUserStringVariant=( Folder ), NSUnderlyingError=0x7fcf36d05b10 {Error Domain=NSOSStatusErrorDomain Code=-43 "fnfErr: File not found"}} /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/kext_tools/kext_tools-692.40.7/kc_staging.m.279: Encountered error while inspecting path: Error Domain=NSCocoaErrorDomain Code=260 "The folder “PrelinkedKernels” doesn’t exist." UserInfo={NSFilePath=/System/Volumes/Update/mnt1/Library/Apple/System/Library/PrelinkedKernels, NSUserStringVariant=( Folder ), NSUnderlyingError=0x7fcf36d0b530 {Error Domain=NSOSStatusErrorDomain Code=-43 "fnfErr: File not found"}} Copying KCs in /System/Volumes/Update/mnt1... System Volume UUID: 9C5D7745-B16A-4602-8670-0E26B9A5198C Volume Group UUID: 834CA517-FD24-4048-B9E8-2CF971E55ED9 Preboot disk: /dev/disk2s2 Preboot volume: /System/Volumes/Preboot Copying: /System/Volumes/Update/mnt1/System/Library/KernelCollections/BootKernelExtensions.kc.elides -> /System/Volumes/Preboot/834CA517-FD24-4048-B9E8-2CF971E55ED9/boot/System/Library/KernelCollections Copying: /System/Volumes/Update/mnt1/System/Library/KernelCollections/BootKernelExtensions.kc -> /System/Volumes/Preboot/834CA517-FD24-4048-B9E8-2CF971E55ED9/boot/System/Library/KernelCollections Creating new root snapshot. Attempting to unmount underlying volume (don't worry if this fails). This may take a minute or two. umount(/System/Volumes/Update/mnt1): Resource busy -- try 'diskutil unmount' Volume Macintosh HD on disk2s5 failed to unmount: dissented by PID 0 (kernel_task) Installed patch kexts successfully.
@AlainBijl I don't see any significant error in your output. (Also, yours is a 2012, which has much simpler patching than the 2011 iMacs.)
@AlainBijl Yes. kcditto tries to copy both KernelCollections and prelinkedkernels, but (for the most part) Big Sur no longer uses the latter, so it shows "File not found" errors even though it's operating normally. (Often, when Apple removes a feature, they wait until the next year's release before they fully remove all of the old code.)
Which Big Sur Micropatcher version? (and what kind of graphics card?)
lastest from 12h ago. am using the Quadro K610M
root cause found:
The updated versions of Whatevergreen and Lilu causes this error. (I could not test these extensions with Beta 10, both upgrades came in parallel, i.e. B9->B10 and Micropatcher 0.4.0 -> 0.4.1/0.4.2 with the new versions of the kext files).
Just used patch-kext from 0.4.2 and got a system not willing to boot any longer. Replacing the new collection with old zipped image from 0.4.0 and re-applying the patches cured the problem.
As I already mentioned: It is time to pull these two files out of the current collection and let the user use them either through open core or with an additional command line flag.
Note: Injection of the same versions of Lilu and Whatevergreen with OpenCore on two other of my Big Sur Beta 10 systems works perfectly. So there is possibly another thing going wrong...
Give me some time to explore this in detail. Reinstalling the extensions one by one gives me a booting system.
@Ausdauersportler It could be a side effect of the fix I did for LegacyUSBInjector. On line 174 (and line 163 to be safe), either comment out or delete the OLD_KMUTIL=YES. See if that makes the crashes go away with the new WhateverGreen and Lilu.
Edit: If it fixes the crashes, I'll look into doing the LegacyUSBInjector fix a different way.
No, it was a badly chosen file in the package, the AppleGraphicsControl.kext. Although I grabbed a recent one (Version 6.1.20) and patched it and put it in my repository I must have mixed up the upload later. Took a while to find the cause, the old one (6.1.18.18) does simply not work.
Took the chance to pull the most recent version from beta 10 (6.1.27) patched it and installed it. Runs fine right now! Did no full install with the patcher, installed all files manually to find the root cause and ended up with the set packed in the zip file attached.
iMac2011Family-highvoltage12v.zip
The unpatch-kext.sh - reboot - patch-kext.sh - reboot loop worked, too. Of course the unpatch-kext.sh does not really delete all the iMac patches. I will look into it, only a few more rm -rf calls. But after the final patch and reboot I have all files installed as expected... Hope this is it for now...
unpatch-kext.sh changes:
please add these four lines in the remove section after line 218 ( rm -rf Tesla ) to achieve a complete deinstallation of all additional kext files possibly installed
echo 'Removing @vit9696 Whatevergreen.kext and Lilu.kext' rm -rf Whatevergreen.kext Lilu.kext echo 'Removing iMac 2011 Nvidia BacklightFixup' rm -rf BacklightFixup.kext
I have attached the complete modified 0.4.2 script as well.
About the AGC:
Basically it is only a plist patching of the current extension supplied with the most recent version of the operating system to enable all display port connectors.
We should for this reason as a long term solution try to implement this patch by only adding the 10 lines below to the plist file.
The patched plist file is
AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/Info.plist
Within this file in the IOKitPersonalities->AppleGraphicsDevicePolicy->ConfigMap
section we need to add the iMac board IDs as shown here
<dict>
<key>IOKitPersonalities</key>
<dict>
<key>AppleGraphicsDevicePolicy</key>
<dict>
<key>ConfigMap</key>
<dict>
key>Mac-942B59F58194171B</key>
<string>none</string>
<key>Mac-942B5BF58194151B</key>
<string>none</string>
<key>Mac-F2268DAE</key>
<string>none</string>
<key>Mac-F2238AC8</key>
<string>none</string>
<key>Mac-F2238BAE</key>
<string>none</string>
</dict>
</dict>
</dict>
</dict>
The last 6 lines provide entries for the iMac 2009/2010 system currently not supported by the Big Sur kernel. We should keep them, who knows...
I have committed the updated Zip file and unpatch-kexts.sh update to the dev-v0.4.3 branch. I'll probably release it in the next day or so. (I want to see if I can improve anything else first.)
root cause found:
The updated versions of Whatevergreen and Lilu causes this error. (I could not test these extensions with Beta 10, both upgrades came in parallel, i.e. B9->B10 and Micropatcher 0.4.0 -> 0.4.1/0.4.2 with the new versions of the kext files).
Just used patch-kext from 0.4.2 and got a system not willing to boot any longer. Replacing the new collection with old zipped image from 0.4.0 and re-applying the patches cured the problem.
As I already mentioned: It is time to pull these two files out of the current collection and let the user use them either through open core or with an additional command line flag.
Note: Injection of the same versions of Lilu and Whatevergreen with OpenCore on two other of my Big Sur Beta 10 systems works perfectly. So there is possibly another thing going wrong...
funny thing is Opencore doesnt seem to inject any kexts into my big sur installation no matter what kext i put thereand eble with opencore cnfigurator it oesn even show up in verbose mod or in systeminformatioon
OpenCore/Catalina Loader on Big Sur iMac 2011:
On my iMac 2011/AMD WX4170/Beta10 (upgraded from 9) I use the Catalina Loader/OC 0.6.2 to spoof the iMacPro1,1 ID and inject Whatevergreen and Lilu. Unfortunately you cannot see this two extensions in the listing on About this Mac->System Report->Extensions. But you see them working by checking the AMD hardware acceleration with VideoProc and by calling ioerg -l | grep board-id - you get back the iMacPro1,1 ID
Did the (v 0.4.2) unpatch-kext.sh (updated unpatch-kext.sh), reboot into Big Sur, used patch-kext.sh (with the updated zip) full loop on one AMD system and got it back bootable and usable with all features as expected (including AMD HW acceleration, Continuity and HandOff). The BT 4.2 card works really OOB.
Fun fact: I upgraded this system some days ago using the B9->B10 jackluke replace method with MC 0.4.1 using the other non working v6.1.18 AGC. So yes, it might be your latest change in the patch-kext.sh....
Fun fact: I upgraded this system some days ago using the B9->B10 jackluke replace method with MC 0.4.1 using the other non working v6.1.18 AGC. So yes, it might be your latest change in the patch-kext.sh....
Thanks for letting me know. If things are working for now with the updated AGC, then I won't change that aspect of patch-kexts.sh for v0.4.3 but I'll look at it for the next release. Edit: Basically, this is probably going to mean replacing the LegacyUSBInjector.kext with a patch for one of the USB kexts which is similar to the AGC patch.
Yes, yes.. it is me again. Honestly it is a lack of concentration when passing such information over. Sorry about this.
Replace in unpatch-kext.sh
echo 'Removing iMac BacklightFixup'
rm -rf BacklightFixup.kext
with
echo 'Removing iMac AppleBacklightFixup'
rm -rf AppleBacklightFixup.kext
Should have tested this, not only added some lines of code.
the changed AGC does not work any longer with the AMD cards, a complete reinstall failed several times until I added these lines to use the stock B10 version (place it right after the same set of code for the AppleBacklight.kext)
echo "Using Big Sur AppleGraphicsControl.kext"
if [ -d AppleGraphicsControl.kext.original ]
then
rm -rf AppleGraphicsControl.kext
mv AppleGraphicsControl.kext.original AppleGraphicsControl.kext
fi
--
I will check today if one could copy the system_profiler to the USB and use it from there in recovery. In this case I will build different zip files for every single file and select automatically using the same type of code as before. This will make the --iMac flag superfluous ....
Unfortunately there is no other way to get the GPU type with a simple command line tool. on macOS. Of course on your write such a tool...
Adding the @jackluke CoreBrightness.framework on my AMD based 2011 system causes the same grey screen problem as having a patched AGC. Started yesterday afternoon with this experiment and tried to recover from this.
A complete new install gave me the grey screen and so I had to search the reason within the patch-kext.sh context. After solving this and sending the former message I tried the CoreBrightness.framework again and it failed with the same symptom - the grey screen and no boot at all.
Recovering from this manually from the USB installer was not that easy: unpatch-kext.sh and patch-kext.sh again...
I will check today if one could copy the system_profiler to the USB and use it from there in recovery. In this case I will build different zip files for every single file and select automatically using the same type of code as before. This will make the --iMac flag superfluous ....
Unfortunately there is no other way to get the GPU type with a simple command line tool. on macOS. Of course on your write such a tool...
I think I tried that at one point, but when it's running under recovery, system_profiler doesn't show any output regarding whether Metal is supported.
There might be a more clever way of using system_profiler to do it under recovery. I'll try to take a look at this again.
Regarding using system_profiler under recovery, now that I'm thinking about it, it might be best to revisit the matter after I try to fix issue #43. The fix for #43 might have the side effect of making system_profiler fully functional under recovery.
chroot $VOLUME does the job...
But the output of system_profiler is somewhat limited...
ioreg -l | grep model
gives at least a line with the GPU cards name like
"model" = <"Nvidia GeForce GTX780M by nikey22">
"model" = <"Radeon RX 460">
which is more complicated than the other solution, we have to maintain a growing list of cards
ioreg -l | grep AGXMetalA12
returns a long line containing this string.
Would be nice to see the output on a non metal system....
That ioreg suggestion is intriguing. I'll test it on a couple of my own systems and report back (maybe tomorrow).
Unfortunately ioreg -l | grep AGXMetalA12 still shows (two) long lines with that string even without a Metal GPU. (Tested on my MacBookPro8,1.)
Maybe keeping a list of non-Metal 2011 iMac cards would be easier than keeping a list of Metal cards. Or maybe an easier fix will be possible after fixing issue #43. (Edit: Yes, this means I'm going to make fixing issue #43 a higher priority, but I still plan to finish v0.4.4 first.)
Before I add the extra lines of code to not patch AGC on AMD Metal GPUs, would you mind commenting out or deleting the OLD_KMUTIL=YES on line 243 of patch-kexts.sh, and seeing if that makes it work again?
I used the IORegistryExplorer App on both of my current systems to check which settings are there....and checked them then on the command line:
ioreg -l | grep AMDBaffinGraphicsAccelerator
or
ioreg -l | grep AMDRadeonX4000_AMDBaffinGraphicsAccelerator
EDIT:
From recovery only this seems to work after the chroot $VOLUME
ioreg -l | grep Baffin
returns a non zero string result for all systems using the AMD (Polaris/Baffin GPU ) type graphics card.
ioreg -l | grep NVDA
or
ioreg -l | grep NVArch
returns a non zero string on systems using the Nvidia (Kepler GPU) type graphics card. The latter call returns a short result...
If you get empty string on both calls there is no metal card installed at all (this is an assumption or educated guess :-) )
At least I can confirm that the first AMD type calls return an empty result on the Nvidia system and vice versa. Did this test on both type of machines and you get an empty string if no AMD Baffin/Polaris or no Nvidia card has been installed.
Note: There are only Nvidia Kepler type GPUs or AMD Baffin/Polaris type CPUs supported. Apple provides drivers with MacOS for both type of systems. No other more recent Nvidia card will be supported by MacOS and the Baffin/Polaris series (2016/17) seems to be the last (laptop graphics) card in MXM style released to the market.
ioreg -l | grep 802.11 | grep ac
returns
| | | | "IOModel" = "Wireless Network Adapter (802.11 a/b/g/n/ac)"
which can be used to decide on --no-wifi
EDIT: confirmed from recovery