RehabMan Posted February 6, 2018 Share Posted February 6, 2018 And now I force to uncheck this driver because I install for 10.11+ systems. It must be optional! We should check it by default but not mandatory. Why not just leave it there? It does no harm when booting a macOS/OS X that doesn't need it (eg. ML and later). Are you serious???? Jesus. That's a terrible message for any commit, like what on Earth does that mean? There is no commit review feature on sourceforge without implementing very complex hooks methods, at least I don't think. Maybe it may be time to go over to github so commits can be reviewed.... I don't know though, that's a lot of work... Yeah... I know. The commit comment makes more sense for the other change that was part of the same commit, which does have something to do with some CPU related stuff. EDIT: You can go to a file and click history in the upper right on sourceforge and it will tell you every time the file was changed. That can make it easier to trace a change you know where it is. In this case, I had no idea what file the change might have happened in. In fact, initially I didn't understand that the Clover installer was removing a file, and then older versions were adding it back. Not until I started using diff to compare EFI/Clover from working vs. non-working did I discover the difference in the drivers64UEFI content... Given I didn't know where the change was, just that it was broken between r4369 and r4380 (those two builds were on sourceforge), I was looking at the commit log for meaningful commit comments... Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586214 Share on other sites More sharing options...
Philip Petev Posted February 6, 2018 Share Posted February 6, 2018 I'm not sure that works 100%. I looked at that, I wonder what the output of each of those commands is, and if it truly removes everything installed before. I can assure you, it works perfectly as intended. Even tested it with the OsxFatBinary driver: two installs, one with checked driver, the next one without it. The driver was removed on the second install. Of course, reverted the mandatory driver list to the one without OsxFatBinary and created a new install package so there won't be any doubts. BTW you see the excluding grep at the end of the first line? I've added it several months ago to prevent all those filesystem drivers to be removed. As you know, the Build_Clover.command script can add them to the Clover package and installing them with it will create receipts for them. After that, it's a matter or using any official package (without them in it) or the custom package (but without checking any or all of them) for you to get them deleted. Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586227 Share on other sites More sharing options...
Badruzeus Posted February 7, 2018 Share Posted February 7, 2018 latest Package Clover 4405 not mount EFI partition in Mac OS X Snow Leopard bellow 4398 is ok Yeah, a same issue with r4406 built; installed using 10.11.6 (Legacy-GPT). It doesn't even mount my EFI Partition (disk0s1), or pre-mounted 1st but the problem is still there. So on post-install I need to manually copying some stuffs from my "/" root partition to the EFI, just similar to GCC built under Ubuntu with no Installer package. Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586265 Share on other sites More sharing options...
chris1111 Posted February 7, 2018 Share Posted February 7, 2018 Yeah, a same issue with r4406 built; installed using 10.11.6 (Legacy-GPT). It doesn't even mount my EFI Partition (disk0s1), or pre-mounted 1st but the problem is still there. So I need to manually copying some stuffs from my "/" root partition to the EFI, just similar to GCC built under Ubuntu with no Installer package. So its not only Snow and Lion ! Lots of more old macOS is affected 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586266 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 I can assure you, it works perfectly as intended. Even tested it with the OsxFatBinary driver: two installs, one with checked driver, the next one without it. The driver was removed on the second install. Of course, reverted the mandatory driver list to the one without OsxFatBinary and created a new install package so there won't be any doubts. BTW you see the excluding grep at the end of the first line? I've added it several months ago to prevent all those filesystem drivers to be removed. As you know, the Build_Clover.command script can add them to the Clover package and installing them with it will create receipts for them. After that, it's a matter or using any official package (without them in it) or the custom package (but without checking any or all of them) for you to get them deleted. Ohhhhh... That's why then, makes more sense now why I thought it wouldn't work for all because it doesn't. But it should delete everything that it installed, period. What if the next time I run the installer I uncheck that driver? It's does not get removed, but it should have because I didn't want it installed anymore. But if you install with the same built installer, which I'm assuming most people are either going to build it themselves or use the official, those will still be selected and installed, or never removed even if wanted. That's eventually going to create conflicts when people start using different packages and end up with a bunch of different drivers that might conflict, or they thought were deleted but are still present... Also another thought, check to make sure the previous options are all in the package. You can then even warn that it's not the same installer source as a previous installation, attempt to select the same selections and warn if there are unavailable ones giving the option whether or not to delete them. That is if there are any options unavailable, it's still fine if they are all available still. That's some work and no idea if it could be done but it is a better method to solve the problem of packages with different options than to just ignore some of the files. You moved the OsxFatBinary from mandatory to optional? Awesome. EDIT: You could probably generate a list of the selections from the previous install no longer present in the running installer pretty easily, then use osascript in the preinstall to build a dialog to popup listing them and asking whether or not to remove those selections. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586316 Share on other sites More sharing options...
Sherlocks Posted February 7, 2018 Share Posted February 7, 2018 10.13.4 beta2 back diskutil for apfs Clover EFI installer log - Wed Feb 7 14:43:20 KST 2018 Installer version: v2.4k r4394 EFI bootloader ====================================================== /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *256.1 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 90.1 GB disk0s2 3: Microsoft Basic Data Windows 7 110.1 GB disk0s3 4: Apple_HFS Macintosh HD 25.9 GB disk0s4 5: Microsoft Basic Data Win Data 29.5 GB disk0s5 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +90.1 GB disk1 Physical Store disk0s2 1: APFS Volume Macintosh HD 34.9 GB disk1s1 2: APFS Volume Preboot 21.5 MB disk1s2 3: APFS Volume Recovery 517.3 MB disk1s3 4: APFS Volume VM 4.3 GB disk1s4 Target volume /Volumes/Macintosh HD on disk1 is APFS on physical store disk0s2 ====================================================== Backing up EFI files Backing up /Volumes/Macintosh HD/EFIROOTDIR/EFI folder to /Volumes/Macintosh HD/EFI-Backups/r4394/2018-02-07-14h43/EFI ====================================================== Installing BootSectors/BootLoader Stage 0 - Don't write any of boot0af, boot0md, boot0ss to / Stage 1 - Don't write any of boot1h2, boot1f32alt, boot1xalt to / Removing drivers64UEFI/VBoxHfs-64.efi driver because HFSPlus driver present ====================================================== Installing RC Scripts Installing RC scripts on target volume '/' ====================================================== =========== Clover EFI Installation Finish =========== old package installation is no problem 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586350 Share on other sites More sharing options...
Guest Posted February 7, 2018 Share Posted February 7, 2018 Hi coders/devs Clover R4392 Motherboard bios with MSR 0xE2 locked KernelXCPM enabled sytem reboots on +++++++ phase it seems that this kernel Patch is not injected if MSR0xE2 is locked f 554889e5 41574156 41554154 53504189d64889fb 85f60f84 84000000 r c39089e5 41574156 41554154 53504189d64889fb 85f60f84 84000000 comment xcpm_program_msrs © Pike R. Alpha Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586368 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 Hi coders/devs Clover R4392 Motherboard bios with MSR 0xE2 locked KernelXCPM enabled sytem reboots on +++++++ phase it seems that this kernel Patch is not injected if MSR0xE2 is locked f 554889e5 41574156 41554154 53504189d64889fb 85f60f84 84000000 r c39089e5 41574156 41554154 53504189d64889fb 85f60f84 84000000 comment xcpm_program_msrs © Pike R. Alpha Make sure you have the patches KernelAndKextPatches/KernelPm=true and KernelAndKextPatches/AppleIntelCPUPM=true. That's where MSR 0xE2 is used as well. Set KernelAndKextPatches/Debug=true to see if your patches are being applied or failing. Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586370 Share on other sites More sharing options...
Guest Posted February 7, 2018 Share Posted February 7, 2018 Sorry apianti my request of help maybe it is not complete Usually I boot fine in my rig with only a fakecpuid for my unsupported CPU (Broadwell EP), with Pike patch and a kext to patch by Brumbaer (com.apple.iokit.IOPCIFamily) No kernel Pm flagged Or other you mention When a new os/beta come I do some test to verify if something new is on Apple kernel And for this I did some test disabling things useful previously to boot (and kernel XCPM helps (usually) to solve if I have problem in this case it seems no ps I am now trying your advice (but usually I don't use those patch In clover to boot) Grazie Make sure you have the patches KernelAndKextPatches/KernelPm=true and KernelAndKextPatches/AppleIntelCPUPM=true. That's where MSR 0xE2 is used as well. Set KernelAndKextPatches/Debug=true to see if your patches are being applied or failing. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ACPI</key> <dict> <key>DSDT</key> <dict> <key>Debug</key> <false/> <key>DropOEM_DSM</key> <false/> <key>Name</key> <string>DSDT.aml</string> <key>Patches</key> <array> <dict> <key>Comment</key> <string>Change XHCI to XHC</string> <key>Disabled</key> <true/> <key>Find</key> <data> WEhDSQ== </data> <key>Replace</key> <data> WEhDXw== </data> </dict> <dict> <key>Comment</key> <string>Rename ALZA to HDEF</string> <key>Disabled</key> <true/> <key>Find</key> <data> QUxaQQ== </data> <key>Replace</key> <data> SERFRg== </data> </dict> <dict> <key>Comment</key> <string>change EHC1 to EH01</string> <key>Disabled</key> <true/> <key>Find</key> <data> RUhDMQ== </data> <key>Replace</key> <data> RUgwMQ== </data> </dict> <dict> <key>Comment</key> <string>change EHC2 to EH02</string> <key>Disabled</key> <true/> <key>Find</key> <data> RUhDMg== </data> <key>Replace</key> <data> RUgwMg== </data> </dict> </array> <key>ReuseFFFF</key> <false/> </dict> <key>DropTables</key> <array> <dict> <key>Signature</key> <string>DMAR</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>Cpu0Ist</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>CpuPm</string> </dict> </array> <key>SSDT</key> <dict> <key>DropOem</key> <false/> <key>Generate</key> <dict> <key>CStates</key> <false/> <key>PStates</key> <false/> <key>PluginType</key> <false/> </dict> </dict> <key>smartUPS</key> <true/> </dict> <key>Boot</key> <dict> <key>Arguments</key> <string>-v darkwake=8 npci=0x2000</string> <key>Debug</key> <false/> <key>DefaultLoader</key> <string>BOOTX64.efi</string> <key>DefaultVolume</key> <string>LastBootedVolume</string> <key>Legacy</key> <string>LegacyBiosDefault</string> <key>Secure</key> <false/> <key>Timeout</key> <integer>25</integer> <key>XMPDetection</key> <false/> </dict> <key>CPU</key> <dict> <key>BusSpeedkHz</key> <integer>100000</integer> <key>QPI</key> <integer>100</integer> <key>Type</key> <string>0x0a02</string> <key>UseARTFrequency</key> <false/> </dict> <key>Devices</key> <dict> <key>Audio</key> <dict> <key>Inject</key> <string>1</string> </dict> <key>USB</key> <dict> <key>FixOwnership</key> <false/> <key>Inject</key> <false/> </dict> </dict> <key>GUI</key> <dict> <key>Language</key> <string>en:0</string> <key>Mouse</key> <dict> <key>DoubleClick</key> <integer>500</integer> <key>Enabled</key> <false/> <key>Mirror</key> <false/> <key>Speed</key> <integer>8</integer> </dict> <key>ScreenResolution</key> <string>3840x2160</string> <key>Theme</key> <string>ios7</string> </dict> <key>Graphics</key> <dict> <key>Inject</key> <dict> <key>ATI</key> <false/> <key>Intel</key> <false/> <key>NVidia</key> <false/> </dict> <key>NvidiaSingle</key> <false/> </dict> <key>KernelAndKextPatches</key> <dict> <key>AppleIntelCPUPM</key> <false/> <key>AppleRTC</key> <false/> <key>Debug</key> <false/> <key>FakeCPUID</key> <string>0x040674</string> <key>KernelCpu</key> <false/> <key>KernelLapic</key> <false/> <key>KernelPm</key> <false/> <key>KernelToPatch</key> <array> <dict> <key>Comment</key> <string>xcpm_assert_perf_max (c) okrasit</string> <key>Disabled</key> <false/> <key>Find</key> <data> idjB4AhIY9A= </data> <key>MatchOS</key> <string>10.13.x</string> <key>Replace</key> <data> uAD/AABIY9A= </data> </dict> <dict> <key>Comment</key> <string>xcpm_program_msrs (c) Pike R. Alpha</string> <key>Disabled</key> <false/> <key>Find</key> <data> VUiJ5UFXQVZBVUFUU1BBidZIifuF9g+EhAAAAA== </data> <key>MatchOS</key> <string>10.13.x</string> <key>Replace</key> <data> w5CJ5UFXQVZBVUFUU1BBidZIifuF9g+EhAAAAA== </data> </dict> <dict> <key>Comment</key> <string>xcpm_idle patch by Pike R. Alpha</string> <key>Disabled</key> <true/> <key>Find</key> <data> vgMAAAAx0uhy/P// </data> <key>Replace</key> <data> vgMAAAAx0pCQkJCQ </data> </dict> </array> <key>KernelXCPM</key> <false/> <key>KextsToPatch</key> <array> <dict> <key>Comment</key> <string>10.12-10.13::IOPCIConfigurator for X99, (credit Brumbear)</string> <key>Disabled</key> <false/> <key>Find</key> <data> SIH7AAAAQA== </data> <key>Name</key> <string>com.apple.iokit.IOPCIFamily</string> <key>Replace</key> <data> SIH7AAAAgA== </data> </dict> <dict> <key>Comment</key> <string>Change 15 port limit to 24 in XHCI kext 10.13</string> <key>Disabled</key> <false/> <key>Find</key> <data> g32MEA== </data> <key>MatchOS</key> <string>10.13.3</string> <key>Name</key> <string>com.apple.driver.usb.AppleUSBXHCIPCI</string> <key>Replace</key> <data> g32MHQ== </data> </dict> <dict> <key>Disabled</key> <false/> <key>Find</key> <data> AEFQUExFIFNTRAA= </data> <key>Name</key> <string>IOAHCIBlockStorage</string> <key>Replace</key> <data> AAAAAAAAAAAAAAA= </data> </dict> <dict> <key>Comment</key> <string>limit 10.13.4</string> <key>Disabled</key> <false/> <key>Find</key> <data> g32UDw+DlwQAAA== </data> <key>MatchOS</key> <string>10.13.4</string> <key>Name</key> <string>com.apple.driver.usb.AppleUSBXHCI</string> <key>Replace</key> <data> g32UD5CQkJCQkA== </data> </dict> </array> </dict> <key>RtVariables</key> <dict> <key>BooterConfig</key> <string>0x28</string> <key>CsrActiveConfig</key> <string>0x03</string> </dict> <key>SMBIOS</key> <dict> <key>BiosReleaseDate</key> <string>12/08/2017</string> <key>BiosVendor</key> <string>Apple Inc.</string> <key>BiosVersion</key> <string>IMP11.88Z.0064.B30.1712081714</string> <key>Board-ID</key> <string>Mac-7BA5B2D9E42DDD94</string> <key>BoardManufacturer</key> <string>Apple Inc.</string> <key>BoardSerialNumber</key> <string>xxxxx</string> <key>BoardType</key> <integer>10</integer> <key>BoardVersion</key> <string>1.0</string> <key>ChassisAssetTag</key> <string>iMacPro-Aluminum</string> <key>ChassisManufacturer</key> <string>Apple Inc.</string> <key>ChassisType</key> <string>0x09</string> <key>Family</key> <string>iMac Pro</string> <key>FirmwareFeatures</key> <string>0xFD8FF53E</string> <key>FirmwareFeaturesMask</key> <string>0xFF9FFF3F</string> <key>LocationInChassis</key> <string>Part Component</string> <key>Manufacturer</key> <string>Apple Inc.</string> <key>Mobile</key> <false/> <key>PlatformFeature</key> <string>0xFFFF</string> <key>ProductName</key> <string>iMacPro1,1</string> <key>SerialNumber</key> <string>xxx</string> <key>Version</key> <string>1.0</string> </dict> <key>SystemParameters</key> <dict> <key>CustomUUID</key> <string>xxx</string> <key>InjectKexts</key> <string>Yes</string> <key>InjectSystemID</key> <true/> <key>NvidiaWeb</key> <true/> </dict> </dict> </plist> @apianti with those two kernel patches system boots fine I think in clover conditional choice could be some error for my rig when KernelXCPM is set MSR0xE2 Unlocked & Broadwell EP Unsupported cpu MSR0xE2 Locked & Broadwell EP Unsupported cpu system boots with config.plist posted here with MSR0xE2 Unlocked & Broadwell EP Unsupported cpu system boots fine with only KernelXCPM flag set with MSR0xE2 Locked & Broadwell EP Unsupported cpu system boots fine with KernelXCPM and those two patches you mention So was thinking some thins are broken in conditions choice Clover does for my rig sorry for so simple explanation I am only a user Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586373 Share on other sites More sharing options...
Sherlocks Posted February 7, 2018 Share Posted February 7, 2018 It's /Library/Preferences/com.projectosx.clover.installer.plist. @Philip Petev i have a question. like you said, installation info of user's setting was saved in com.projectosx.clover.installer.plist but after installed clean high sierra, and i installed clover without any driver check of driver64uefi(never check). ex. there was EmuVariableUefi-64.efi. this file was optional. then enter clover package again, checked EmuVariableUefi-64.efi in package, and unchecked. then EmuVariableUefi-64.efi was automatically removed. so i want to cleanup installation info like clean installation of high sierra i removed com.projectosx.clover.installer.plist like you said. clover package option is default again. but still clover package automatically remove EmuVariableUefi-64.efi file. is there another save part? i don't know exact clover package behavior why happen. If it is an option file, why is the clover package removing only certain files without erasing all previous option files in the driver64uefi folder? In the case I mentioned above, fat-64 always exists, with or without checking. The current code is not clean. This is because only certain files show this phenomenon. EDIT1. you need to test between fat-64 and EmuVariableUefi. you can surely see this phenomenon EDIT2. never touch any driver64uefi in clover package after install fresh hs. clover package don't touch user's uefi driver. but once after checked driver in clover package and install clover. clover package saved user's setting. then clover package again. uncheck checked driver. then clover package removed this file. then removed com.projectosx.clover.installer.plist. clover package is default option. but still automatically removed after manually added driver. why not back "never touch any driver64uefi in clover package after install fresh hs, clover package don't touch user's uefi driver."? Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586392 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 Sorry apianti my request of help maybe it is not complete Usually I boot fine in my rig with only a fakecpuid for my unsupported CPU (Broadwell EP), with Pike patch and a kext to patch by Brumbaer (com.apple.iokit.IOPCIFamily) No kernel Pm flagged Or other you mention When a new os/beta come I do some test to verify if something new is on Apple kernel And for this I did some test disabling things useful previously to boot (and kernel XCPM helps (usually) to solve if I have problem in this case it seems no ps I am now trying your advice (but usually I don't use those patch In clover to boot) Grazie <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ACPI</key> <dict> <key>DSDT</key> <dict> <key>Debug</key> <false/> <key>DropOEM_DSM</key> <false/> <key>Name</key> <string>DSDT.aml</string> <key>Patches</key> <array> <dict> <key>Comment</key> <string>Change XHCI to XHC</string> <key>Disabled</key> <true/> <key>Find</key> <data> WEhDSQ== </data> <key>Replace</key> <data> WEhDXw== </data> </dict> <dict> <key>Comment</key> <string>Rename ALZA to HDEF</string> <key>Disabled</key> <true/> <key>Find</key> <data> QUxaQQ== </data> <key>Replace</key> <data> SERFRg== </data> </dict> <dict> <key>Comment</key> <string>change EHC1 to EH01</string> <key>Disabled</key> <true/> <key>Find</key> <data> RUhDMQ== </data> <key>Replace</key> <data> RUgwMQ== </data> </dict> <dict> <key>Comment</key> <string>change EHC2 to EH02</string> <key>Disabled</key> <true/> <key>Find</key> <data> RUhDMg== </data> <key>Replace</key> <data> RUgwMg== </data> </dict> </array> <key>ReuseFFFF</key> <false/> </dict> <key>DropTables</key> <array> <dict> <key>Signature</key> <string>DMAR</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>Cpu0Ist</string> </dict> <dict> <key>Signature</key> <string>SSDT</string> <key>TableId</key> <string>CpuPm</string> </dict> </array> <key>SSDT</key> <dict> <key>DropOem</key> <false/> <key>Generate</key> <dict> <key>CStates</key> <false/> <key>PStates</key> <false/> <key>PluginType</key> <false/> </dict> </dict> <key>smartUPS</key> <true/> </dict> <key>Boot</key> <dict> <key>Arguments</key> <string>-v darkwake=8 npci=0x2000</string> <key>Debug</key> <false/> <key>DefaultLoader</key> <string>BOOTX64.efi</string> <key>DefaultVolume</key> <string>LastBootedVolume</string> <key>Legacy</key> <string>LegacyBiosDefault</string> <key>Secure</key> <false/> <key>Timeout</key> <integer>25</integer> <key>XMPDetection</key> <false/> </dict> <key>CPU</key> <dict> <key>BusSpeedkHz</key> <integer>100000</integer> <key>QPI</key> <integer>100</integer> <key>Type</key> <string>0x0a02</string> <key>UseARTFrequency</key> <false/> </dict> <key>Devices</key> <dict> <key>Audio</key> <dict> <key>Inject</key> <string>1</string> </dict> <key>USB</key> <dict> <key>FixOwnership</key> <false/> <key>Inject</key> <false/> </dict> </dict> <key>GUI</key> <dict> <key>Language</key> <string>en:0</string> <key>Mouse</key> <dict> <key>DoubleClick</key> <integer>500</integer> <key>Enabled</key> <false/> <key>Mirror</key> <false/> <key>Speed</key> <integer>8</integer> </dict> <key>ScreenResolution</key> <string>3840x2160</string> <key>Theme</key> <string>ios7</string> </dict> <key>Graphics</key> <dict> <key>Inject</key> <dict> <key>ATI</key> <false/> <key>Intel</key> <false/> <key>NVidia</key> <false/> </dict> <key>NvidiaSingle</key> <false/> </dict> <key>KernelAndKextPatches</key> <dict> <key>AppleIntelCPUPM</key> <false/> <key>AppleRTC</key> <false/> <key>Debug</key> <false/> <key>FakeCPUID</key> <string>0x040674</string> <key>KernelCpu</key> <false/> <key>KernelLapic</key> <false/> <key>KernelPm</key> <false/> <key>KernelToPatch</key> <array> <dict> <key>Comment</key> <string>xcpm_assert_perf_max (c) okrasit</string> <key>Disabled</key> <false/> <key>Find</key> <data> idjB4AhIY9A= </data> <key>MatchOS</key> <string>10.13.x</string> <key>Replace</key> <data> uAD/AABIY9A= </data> </dict> <dict> <key>Comment</key> <string>xcpm_program_msrs (c) Pike R. Alpha</string> <key>Disabled</key> <false/> <key>Find</key> <data> VUiJ5UFXQVZBVUFUU1BBidZIifuF9g+EhAAAAA== </data> <key>MatchOS</key> <string>10.13.x</string> <key>Replace</key> <data> w5CJ5UFXQVZBVUFUU1BBidZIifuF9g+EhAAAAA== </data> </dict> <dict> <key>Comment</key> <string>xcpm_idle patch by Pike R. Alpha</string> <key>Disabled</key> <true/> <key>Find</key> <data> vgMAAAAx0uhy/P// </data> <key>Replace</key> <data> vgMAAAAx0pCQkJCQ </data> </dict> </array> <key>KernelXCPM</key> <false/> <key>KextsToPatch</key> <array> <dict> <key>Comment</key> <string>10.12-10.13::IOPCIConfigurator for X99, (credit Brumbear)</string> <key>Disabled</key> <false/> <key>Find</key> <data> SIH7AAAAQA== </data> <key>Name</key> <string>com.apple.iokit.IOPCIFamily</string> <key>Replace</key> <data> SIH7AAAAgA== </data> </dict> <dict> <key>Comment</key> <string>Change 15 port limit to 24 in XHCI kext 10.13</string> <key>Disabled</key> <false/> <key>Find</key> <data> g32MEA== </data> <key>MatchOS</key> <string>10.13.3</string> <key>Name</key> <string>com.apple.driver.usb.AppleUSBXHCIPCI</string> <key>Replace</key> <data> g32MHQ== </data> </dict> <dict> <key>Disabled</key> <false/> <key>Find</key> <data> AEFQUExFIFNTRAA= </data> <key>Name</key> <string>IOAHCIBlockStorage</string> <key>Replace</key> <data> AAAAAAAAAAAAAAA= </data> </dict> <dict> <key>Comment</key> <string>limit 10.13.4</string> <key>Disabled</key> <false/> <key>Find</key> <data> g32UDw+DlwQAAA== </data> <key>MatchOS</key> <string>10.13.4</string> <key>Name</key> <string>com.apple.driver.usb.AppleUSBXHCI</string> <key>Replace</key> <data> g32UD5CQkJCQkA== </data> </dict> </array> </dict> <key>RtVariables</key> <dict> <key>BooterConfig</key> <string>0x28</string> <key>CsrActiveConfig</key> <string>0x03</string> </dict> <key>SMBIOS</key> <dict> <key>BiosReleaseDate</key> <string>12/08/2017</string> <key>BiosVendor</key> <string>Apple Inc.</string> <key>BiosVersion</key> <string>IMP11.88Z.0064.B30.1712081714</string> <key>Board-ID</key> <string>Mac-7BA5B2D9E42DDD94</string> <key>BoardManufacturer</key> <string>Apple Inc.</string> <key>BoardSerialNumber</key> <string>xxxxx</string> <key>BoardType</key> <integer>10</integer> <key>BoardVersion</key> <string>1.0</string> <key>ChassisAssetTag</key> <string>iMacPro-Aluminum</string> <key>ChassisManufacturer</key> <string>Apple Inc.</string> <key>ChassisType</key> <string>0x09</string> <key>Family</key> <string>iMac Pro</string> <key>FirmwareFeatures</key> <string>0xFD8FF53E</string> <key>FirmwareFeaturesMask</key> <string>0xFF9FFF3F</string> <key>LocationInChassis</key> <string>Part Component</string> <key>Manufacturer</key> <string>Apple Inc.</string> <key>Mobile</key> <false/> <key>PlatformFeature</key> <string>0xFFFF</string> <key>ProductName</key> <string>iMacPro1,1</string> <key>SerialNumber</key> <string>xxx</string> <key>Version</key> <string>1.0</string> </dict> <key>SystemParameters</key> <dict> <key>CustomUUID</key> <string>xxx</string> <key>InjectKexts</key> <string>Yes</string> <key>InjectSystemID</key> <true/> <key>NvidiaWeb</key> <true/> </dict> </dict> </plist> @apianti with those two kernel patches system boots fine I think in clover conditional choice could be some error for my rig when KernelXCPM is set MSR0xE2 Unlocked & Broadwell EP Unsupported cpu MSR0xE2 Locked & Broadwell EP Unsupported cpu system boots with config.plist posted here with MSR0xE2 Unlocked & Broadwell EP Unsupported cpu system boots fine with only KernelXCPM flag set with MSR0xE2 Locked & Broadwell EP Unsupported cpu system boots fine with KernelXCPM and those two patches you mention So was thinking some thins are broken in conditions choice Clover does for my rig sorry for so simple explanation I am only a user No problem, whenever MSR 0xE2 is detected as locked, those configuration keys are automatically enabled but you set those to false which disabled them and they are needed for locked MSR 0xE2. @Philip Petev i have a question. like you said, installation info of user's setting was saved in com.projectosx.clover.installer.plist but after installed clean high sierra, and i installed clover without any driver check of driver64uefi(never check). ex. there was EmuVariableUefi-64.efi. this file was optional. then enter clover package again, checked EmuVariableUefi-64.efi in package, and unchecked. then EmuVariableUefi-64.efi was automatically removed. so i want to cleanup installation info like clean installation of high sierra i removed com.projectosx.clover.installer.plist like you said. clover package option is default again. but still clover package automatically remove EmuVariableUefi-64.efi file. is there another save part? i don't know exact clover package behavior why happen. If it is an option file, why is the clover package removing only certain files without erasing all previous option files in the driver64uefi folder? In the case I mentioned above, fat-64 always exists, with or without checking. The current code is not clean. This is because only certain files show this phenomenon. EDIT1. you need to test between fat-64 and EmuVariableUefi. you can surely see this phenomenon EDIT2. never touch any driver64uefi in clover package after install fresh hs. clover package don't touch user's uefi driver. but once after checked driver in clover package and install clover. clover package saved user's setting. then clover package again. uncheck checked driver. then clover package removed this file. then removed com.projectosx.clover.installer.plist. clover package is default option. but still automatically removed after manually added driver. why not back "never touch any driver64uefi in clover package after install fresh hs, clover package don't touch user's uefi driver."? Yes, I agree I don't think that the package removes/keeps drivers like a user would want. But are you saying that there is also a case where the installer removes manually placed drivers that weren't installed through the installer? Or are you just confirming the previous that it does not delete everything previously installed? Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586439 Share on other sites More sharing options...
Sherlocks Posted February 7, 2018 Share Posted February 7, 2018 Yes, I agree I don't think that the package removes/keeps drivers like a user would want. But are you saying that there is also a case where the installer removes manually placed drivers that weren't installed through the installer? Or are you just confirming the previous that it does not delete everything previously installed? I saw some difference. 1. In fresh macos status(never install clover package) Already i have efi(clover) before install fresh macos. Then just install clover package without never checked any driver64uefi. Then clover package don't touch any optional files(i have previous files). 2. Then reinstall clover package again. Next next then check example fat-64(already i have before). Then next and completed installation of clover. And there was fat-64 efi in driver64uefi. Then clover package again. Next next uncheck checked fat-64. Then next, and completed installation of clover. And fat-64 was removed. Clover package saved users setting plist. So i removed plist to reset clover package option(default). Then i added fat-64.efi manually in driver64uefi and i did case1 process above. But clover package still remove fat-64.efi automatically. As result, when case1, there is no problem but case2, its not good. In case2, is there another part to save option(to auto-remove fat-64)? Thanks in advance 나의 LG-F800S 의 Tapatalk에서 보냄 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586557 Share on other sites More sharing options...
Philip Petev Posted February 7, 2018 Share Posted February 7, 2018 I made some tests today. It's all about this part: # Remove files of old revision.pkgs=$(/usr/sbin/pkgutil --volume "$DEST_VOL" --pkgs | /usr/bin/grep -iE '@CLOVER_PACKAGE_IDENTITY@.' | /usr/bin/grep -Ev 'ntfs|apfs|hfsplus')for pkg in $pkgs; do # Get where the files where installed from volume destination location=$(/usr/sbin/pkgutil --volume "$DEST_VOL" --pkg-info $pkg 2>/dev/null | sed -n 's/^location: *//p') pkgutil --volume "$DEST_VOL" --files $pkg 2>/dev/null | \ xargs -I @@ echo "$DEST_VOL/$location/@@" | \ /usr/bin/grep -iE 'EFI/CLOVER/(drivers\w+)/' | \ xargs -I @@ rm -rf '@@' rm -f "$DEST_VOL"/Library/Receipts/"$pkg".{plist,bom}done First line determines all installed packages with identifiers, starting with org.clover, excluding the identifiers of the filesystem drivers if anyone have them installed with custom package. Nothing unusual. Now, the "for" cycle is the interesting part - for each identifier in the list, got by the first line, the install location is being determined and the next long command finds and deletes all files, installed by the EFI drivers subpackages. That's right, the long command deletes only EFI drivers and nothing else! This part of the command, /usr/bin/grep -iE 'EFI/CLOVER/(drivers\w+)/, is used to append the path to the files, because it seems the bom files (the install receipts) for those subpackages contain only the filename they install and not the full path to it, like other subpackages like the Clover prefpane or the Clover Theme Manager. This is pretty short explanation of what this whole line does, those who a interested can check the xargs man page. The last command removes the package receipts corresponding to those identifiers. And here we have a problem: it actually removes nothing, at least not in the recent macOS version. There was indeed a time when that folder (/Library/Receipts) contained the receipts, but at some point they were moved in /var/db/receipts and /Library/Receipts is not being used for this purpose anymore. So, with a receipt, still present in that folder, it's a matter of time any EFI driver (installed manually or not) do magically disappear. All this seems to me like a bad design. The right approach would be a preinstall script in every EFI driver subpackage that will remove the old driver ONLY if the driver has been selected for installation. About fat-64.efi - this driver is not mandatory, ebuild.sh copies it in drivers-Off/drivers64UEFI, so it appears as a separate option in the Drivers64UEFI submenu. @Sherlocks, try to remove your ~/src/edk2 folder and also make sure you have the latest Build_Clover.command script (if you use it). Made several packages during last two days and none of them auto-installs fat-64.efi when the option is not selected. I think Micky pushed a commit about that these days... 3 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586685 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 I made some tests today. It's all about this part: First line determines all packages with identifiers, starting with org.clover, excluding the identifiers of the filesystem drivers if anyone have them installed with custom package. Nothing unusual. Now, the "for" cycle is the interesting part - for each identifier in the list, got by the first line, the install location is being determined and the next long command finds and deletes all files, installed by the EFI drivers subpackages. That's right, the long command deletes only EFI drivers and nothing else! This part of the command, /usr/bin/grep -iE 'EFI/CLOVER/(drivers\w+)/, is used to append the path to the files, because it seems the bom files (the install receipts) for those subpackages contain only the filename they install and not the full path to it, like other subpackages like the Clover prefpane or the Clover Theme Manager. This is pretty short explanation of what this whole line does, those who a interested can check the xargs man page. The last command removes the package receipts corresponding to those identifiers. And here we have a problem: it actually removes nothing, at least not in the recent macOS version. There was indeed a time when that folder (/Library/Receipts) contained the receipts, but at some point they were moved in /var/db/receipts and /Library/Receipts is not being used for this purpose anymore. So, with a receipt, still present in that folder, it's a matter of time any EFI driver (installed manually or not) do magically disappear. Ok the last part is what is really causing an issue, the receipts are invalid or not there? Are the receipts not named well enough that you can figure out they are from which selection or contain any other information besides the names? EDIT: I see that the first line actually tells you which selection they were from right? I don't agree that the filesystem drivers should be excluded. I may want to remove HFSPlus and go back to VBoxHFS, or don't need APFS or NTFS anymore because I don't have those filesystems. You are being forced to manually go in and remove drivers, even if you unselect them - thinking they will be removed, like the rest kinda are.... EDIT2: This means that the installer needs to determine the OS version to determine where the receipts are, and what version did they move? All this seems to me like a bad design. The right approach would be a preinstall script in every EFI driver subpackage that will remove the old driver ONLY if the driver has been selected for installation. Yeah, that's probably why it's coming up, lol. However, I think you have it backwards, if the new one is being installed then it doesn't really need removed as it will be (most likely) overwritten (otherwise you wouldn't be able to delete it anyway cause of permissions). The only things that should be removed were installed before but are now unselected or aren't part of the source of the running installer and the user was asked and decided not to keep them. EDIT: I should be more clear, everything should be deleted that can be reinstalled from the running installer. Anything else from previous package, the user should be asked to remove or keep each selection. EDIT2: Are these receipts removed if an option is then unselected? Or does it just stay there forever? About fat-64.efi - this driver is not mandatory, ebuild.sh copies it in drivers-Off/drivers64UEFI, so it appears as a separate option in the Drivers64UEFI submenu. @Sherlocks, try to remove your ~/src/edk2 folder and also make sure you have the latest Build_Clover.command script (if you use it). Made several packages during last two days and none of them auto-installs fat-64.efi when the option is not selected. I think Micky pushed a commit about that these days... No, he's saying he installed the driver, then uninstalled the driver. That worked fine. But then removed the package plist and he manually installed the driver, and after running the installer again, the driver was not checked but was removed even though the package plist was removed before running the installer. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586787 Share on other sites More sharing options...
bronxteck Posted February 7, 2018 Share Posted February 7, 2018 can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586893 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder No, forever no. It's not needed. It won't work. Legacy clover already sets up everything EFI appropriately for macOS. EDIT: Why are you putting AptioFix on a legacy machine??? Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586907 Share on other sites More sharing options...
bronxteck Posted February 7, 2018 Share Posted February 7, 2018 because it loads fine according to my boot log and works? all it needs added are the Rc scripts. no emu. machine in sig. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586917 Share on other sites More sharing options...
chris1111 Posted February 7, 2018 Share Posted February 7, 2018 can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder It can be ad, you need to put the Drivers in /drivers-Off /drivers64 in your case for Legacy it will be appears on package selection Drivers64 Edit ** But for each compilation or Update, the DriversOff are deleted and replace so you have to put it back to see it in your package 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586929 Share on other sites More sharing options...
bronxteck Posted February 7, 2018 Share Posted February 7, 2018 would it not be simpler to add it in the official clover installer in the first place? edited Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586947 Share on other sites More sharing options...
chris1111 Posted February 7, 2018 Share Posted February 7, 2018 would it not be simpler to add it in the installer in the first place? its the same, Mandatory Drivers are deleted and replace for each Update Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586953 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 because it loads fine according to my boot log and works? all it needs added are the Rc scripts. no emu. machine in sig. Nope, actually it's doing nothing. EmuVar is already part of the legacy firmware..... You need the RC scripts because you don't have native NVRAM because aptiofix doesn't do anything with legacy firmware.... It can be ad, you need to put the Drivers in /drivers-Off /drivers64 in your case for Legacy it will be appears on package selection Drivers64 Edit ** But for each compilation or Update, the DriversOff are deleted and replace so you have to put it back to see it in your package This is pointless, there is absolutely NO benefit to this. DO NOT DO THIS. Do not use AptioFix with legacy firmware, period. would it not be simpler to add it in the official clover installer in the first place? edited No, because it's not needed and using it is wasting time, and putting it in the installer to install in legacy is an even bigger waste of time. its the same, Mandatory Drivers are deleted and replace for each Update I think that may not always be the case, as per the discussion happening around this one.... EDIT: Oh, you mean when making the installer, then yes, it erases all the drivers and rebuilds them for each build. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586974 Share on other sites More sharing options...
Philip Petev Posted February 7, 2018 Share Posted February 7, 2018 Ok the last part is what is really causing an issue, the receipts are invalid or not there? Are the receipts not named well enough that you can figure out they are from which selection or contain any other information besides the names? EDIT2: Are these receipts removed if an option is then unselected? Or does it just stay there forever? The receipts are not being removed. Ever. There is no such practice in the macOS Install framework. The only way to remove them is to delete them manually from /var/db/receipts or /Library/Receipts. That's what this preinstall script is trying to do, but as I said, it's not a good idea and a bad practice, in such cases a preinstall script is being used for every subpackage to remove the older version of the files before deploying the new one. I think to look at this problem when I get some free time (probably this weekend). EDIT: I see that the first line actually tells you which selection they were from right? I don't agree that the filesystem drivers should be excluded. I may want to remove HFSPlus and go back to VBoxHFS, or don't need APFS or NTFS anymore because I don't have those filesystems. You are being forced to manually go in and remove drivers, even if you unselect them - thinking they will be removed, like the rest kinda are.... The reason I suggested that change was the complaints from the user, losing the HFSPlus.efi driver. Because using the custom package (that includes the proprietary drivers) and using the official one (without them) leads to such consequences. Unlike the other drivers, HFSPlus.efi, NTFS.efi and apfs.efi are not part of the Clover/edk2 distribution and like @RehabMan said, it won't hurt if they stay there. You can change them manually whenever you want. EDIT: I should be more clear, everything should be deleted that can be reinstalled from the running installer. Anything else from previous package, the user should be asked to remove or keep each selection. Such functionality may be possible through Installer plugins, but someone has to write them. Not familiar with them as never needed them, even when I maintained the HP ProBook Installer package. No, he's saying he installed the driver, then uninstalled the driver. That worked fine. But then removed the package plist and he manually installed the driver, and after running the installer again, the driver was not checked but was removed even though the package plist was removed before running the installer. Makes perfectly sense to me. The current package doesn't remove anything from /var/db/receipts and considering the fact the first install has added a receipt for it, the file is being deleted, because the Installer reads the receipt. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2586980 Share on other sites More sharing options...
apianti Posted February 7, 2018 Share Posted February 7, 2018 The receipts are not being removed. Ever. There is no such practice in the macOS Install framework. The only way to remove them is to delete them manually from /var/db/receipts or /Library/Receipts. That's what this preinstall script is trying to do, but as I said, it's not a good idea and a bad practice, in such cases a preinstall script is being used for every subpackage to remove the older version of the files before deploying the new one. I think to look at this problem when I get some free time (probably this weekend). So maybe all the previous receipts should be removed in postinstall? Or is that too late and the new receipts are there already? The previously installed stuff should definitely be removed, with caveats that the user needs to choose to remove stuff that doesn't exist in the running installer. The reason I suggested that change was the complaints from the user, losing the HFSPlus.efi driver. Because using the custom package (that includes the proprietary drivers) and using the official one (without them) leads to such consequences. Unlike the other drivers, HFSPlus.efi, NTFS.efi and apfs.efi are not part of the Clover/edk2 distribution and like @RehabMan said, it won't hurt if they stay there. You can change them manually whenever you want. I understand the change, I just suggest making a different one. Also having HFSPlus and VBoxHFS causes issues. I also think most people think that if they uncheck something it will be removed, I know I do. I expect that. Such functionality may be possible through Installer plugins, but someone has to write them. Not familiar with them as never needed them, even when I maintained the HP ProBook Installer package. I gave you a way to do it, check the current package for the same stuff as the receipts, if not found in the package, use osascript to generate a dialog. I have no idea if there is anyway to add options after the package is already made but that would be a much cleaner solution... Makes perfectly sense to me. The current package doesn't remove anything from /var/db/receipts and considering the fact the first install has added a receipt for it, the file is being deleted, because the Installer reads the receipt. Yeah, we should maybe remove them in postinstall like pkgutil --forget @CLOVER_PACKAGE_IDENTITY@ But is that going to remove the currently installing package or the previous.... IDK. EDIT: Actually we can run that at the end of the preinstall, because even if the script ends up failing after, all those files were removed so it's safe to remove the receipts. EDIT2: Actually it's not safe because then the next time the installer is run the choices won't be selected, so it must be in postinstall. EDIT3: Thought of something crazy, don't actually build the package. Put all the components to build into the package, then when installer is run, build a package from the components and missing stuff through receipts. Then run that installer from the current one. Ridiculously that should work.......... 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2587015 Share on other sites More sharing options...
Trung_Nguyen Posted February 8, 2018 Share Posted February 8, 2018 Hello, I'm using AptioInputFix with Clover timeout=0 to FileVault 2 to work. But the problem is that I couldn't enter Clover GUI by holding a key. Key combinations like(cmd+v/shift/cmd+s/...) also don't work. So it kind of lock me into a scenario that no EFI Shell, no Recovery boot. Is there any walk-around except set clover timeout to higher volume? Thanks Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2587255 Share on other sites More sharing options...
Philip Petev Posted February 8, 2018 Share Posted February 8, 2018 So maybe all the previous receipts should be removed in postinstall? Or is that too late and the new receipts are there already? The previously installed stuff should definitely be removed, with caveats that the user needs to choose to remove stuff that doesn't exist in the running installer. I understand the change, I just suggest making a different one. Also having HFSPlus and VBoxHFS causes issues. I also think most people think that if they uncheck something it will be removed, I know I do. I expect that. I gave you a way to do it, check the current package for the same stuff as the receipts, if not found in the package, use osascript to generate a dialog. I have no idea if there is anyway to add options after the package is already made but that would be a much cleaner solution... Yeah, we should maybe remove them in postinstall like pkgutil --forget @CLOVER_PACKAGE_IDENTITY@ But is that going to remove the currently installing package or the previous.... IDK. EDIT: Actually we can run that at the end of the preinstall, because even if the script ends up failing after, all those files were removed so it's safe to remove the receipts. EDIT2: Actually it's not safe because then the next time the installer is run the choices won't be selected, so it must be in postinstall. EDIT3: Thought of something crazy, don't actually build the package. Put all the components to build into the package, then when installer is run, build a package from the components and missing stuff through receipts. Then run that installer from the current one. Ridiculously that should work.......... For now, I'm going to add /var/db/receipts in that preinstall script, so next time when you run the installer, only the packages, selected on the previous install, will be removed before the deployment of the new files. That's only a workaround until I figure out what to do next. 1 Link to comment https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page/658/#findComment-2587262 Share on other sites More sharing options...
Recommended Posts