MinusZwei

Btw, I am currently preparing a patch for Enoch that will also accept hex values in plist files... I don't think I am the only one annoyed by having to convert all int values to decimal first However, I first wants to quickly test it before submitting the patch to ErmaC

One of the most complicated one that exists called a calculator The firmware features and mask values are mentioned in hexadecimal (base 16) in clover source code, and Enoch is not able to read 0xXXX values. Therefore you have to convert the hexadecimal value like 0xE00FE137 to its decimal (base 10) value and place this number in your plist file. For example 0xE00FE137 in hex is 3759137079 in decimal.

Ok, let me make this point clear: Enoch will not work OOB for installing macOS 10.13: You will have to add the 2 new keys that I have added to inject the firmware features and mask into the smbios. Your smbios.plist must contain the following 2 keys, with proper values: - SMfirmwarefeatures - SMfirmwarefeaturesmask (keep in mind that Enoch does not support -yet- hex input, so convert hex values to decimal first) Enoch is now generating an Apple specific block (type 128) in the emulated SMBIOS that it sends to macOS. Inside this block, the 2 values passed over smbios.plist will be injected. (If not present, default values will be used, that will most probably not work with 10.13 checks). The values you pass can be grabbed from Clover source code directly, or from a real mac SMBios (I took mine from a real MacPro5,1 SMBIOS dump). The values that Clover is using should be inside 'Clover/rEFIt_UEFI/Platform/platformdata.c' is I am not mistaken... Once this is done, the "famous firmware verification error" at stage 2 will be gone (yeah!). Regarding the OSInstall.mpkg is damaged error, this has usually 2 different origins: - either you are booting with your own generated kernelcache and it is missing several kexts (From my experience, the /S/L/E in BaseSystem is NOT complete, and is missing several kexts), but this is pretty rare, since normally it is crashing before starting the installer (several kexts dependancies are missing) - or you exceeded the time limit set in the plist of the 'macOS Install Data' folder (I think Pike blogged about this some month ago) And last but not least: Don't forget to manually patch the plist files in 'macOS Install Data' folder BEFORE stage 2, otherwise there is a damn high chance that macOS installer will automatically convert the destination partition to APFS, making it invisible for Enoch. Please check my post above... I would strongly suggest adding the SMfirmwarefeatures and SMfirmwarefeaturesmask keys. In your case, the correct values should be SMfirmwarefeatures = 0xE00FE137 SMfirmwarefeaturesmask = 0xFF1FFF3F (again convert it to decimal before putting it in smbios.plist )

As mentioned, I did a bit of back-porting from Clover in order to have a working High Sierra installation. I will prepare a small tutorial describing how I installed it, but just to give a brief overview, using this method, I was able to make a fresh clean 10.13 install on a blank SSD. Basically, macOS 10.13 installer works differently from previous ones: It is now working in 2 passes to install macOS instead of one previously. 1. The first pass will copy the installer data in a 'macOS Install Data' folder on your target partition (more or less the content of the 'SharedSupport' folder) 2. The seconds pass will actually install macOS using this data folder (Please note that nothing really fancy was done to create the install stick: 'createinstallmedia' and installed Enoch. That's all.) For the first pass, you will have to use the 'prelinkedkernel': I have tried to re-create a new pre-linked kernel based on the S/L/E that is present in BaseSystem.dmg, adding FakeSMC and my network card driver, but I was never able to properly boot the install stick afterwards (from what I see, launchd process could not be started...). I think that BaseSystem.dmg does not contain all needed kexts that have been used to create the pre-linked kernel, but that is just a rough guess. Anyway, since Enoch contains its own FakeSMC and since you don't need a network connection while installing, use the pre-linked kernel, and make sure that the Enoch FakeSMC is used (you can confirm this with the verbose logs of Enoch), and the installer will start. The first pass will not read any firmware, and so, you will be able to get the install files copied on your target partition (just make sure to format it in HFS+). However, when you then boot on your target partition to continue the installation, you will be greeted by a nice message: "An error occurred while verifying firmware."... This is coming from the fact that the SMBIOS that Enoch is showing does not contain the Apple-specific firmware volume, which contains the firmware features and its corresponding mask Since Clover has implemented this since DP6, I have basically copy-pasted the code inside Enoch to get this working. The correct values can be passed inside the smbios.plist, using the following keys: 'SMfirmwarefeatures' and 'SMfirmwarefeaturesmask' (keep in mind that Enoch is not able to read hex formatted numbers, so convert the values to decimal first . Also, I did not tried the default values. I directly injected the proper ones for my machine type...) Patching Enoch with the proper firmware volume block inside the SMBIOS fixed the firmware verification error that I was getting (this is what has been merged in 2902). However, since the target partition was located on an SSD, it was still converted to APFS during the seconds pass... In order to fix this, what I did was the following: - I booted the install stick again after first pass was done - I opened the terminal application (from Utilities menu) and modified 2 files that were created during the first pass: OSInstallAttr.plist and minstallconfig.xml. (Basically, grep for 'convertToAPFS' tag and change its value from '<true/>' to '<false/>') By doing this, the 2nd pass won't convert my target partition to APFS, keeping a good-old-HFS format. Finally, after 2nd pass, reboot to the install stick, open a terminal, and install Enoch on the target partition, copy the additional kexts you need to /L/E and reboot. (The new pre-linked kernel should be created automatically before the first boot since /L/E has been modified, so you're good). And voila. 10.13 is running, using Enoch

...and still no support for Pascal. (I mean, no GP100.kext inside)

I had a quick look to the PKG contents, and I don't think it is gonna work. There are 3 kexts: - GF100 - GK100 - GM100

I have updated a 10.11.5 VM this morning, and installed VMware tools from Fusion 8.1.1 I have noticed that my VM crashes (KP) as soon as I try to shut down. Did you also noticed this behavior ?

Do they have an updated version of the NVIDIA driver (the osx one, not the web one!) ? Also, is .3 or .4 supporting skylake GPUs ?

I am reading more and more that new rMBP will have (again) NVidia chips... Is there already any update in the stock OS X drivers in 10.11.2 ?

Could anyone running a Maxwell GPU on El Capitan do a quick test for me ? I was having some troubles rendering very specific images in Safari and/or Preview with Yosemite... ...and I don't have a Maxwell GPU available to re-do the test right now. If you could do this on your machine (simply opening a PDF and share the screenshot), it would be highly appreciated

Sounds very low indeed, but I might have an explanation for that. While monitoring the frequencies, I have seen that the GPU is not stepping up in Cinebench. It is doing so however in Valley for example, where I get decent results (Extreme HD is ~15-20% lower as Windows equivalent). Could you tell me what settings you injected for SMBIOS? At least the As I have a 6-core i7 980, I am running as "MacPro5,1" currently. Are you using something more recent like iMac14,2 ? Also, for Cinebench at least, the CPU frequency makes quite a difference (don't ask me why...). What frequency is your CPU running? Are you doing overclocking ?

Hi all, I am currently running on an "old" 6 core i7 980 at stock speed (3.33 -> 3.46 turbo) I usually use the "MacPro5,1" as scheme in my smbios, but I am getting quite a poor score in cinebench compared to yours... Using this smbios, I see the 'AGPM' loaded (of course with 'Unknown platform' when unpatched). I have tried to apply this method, but it seems that on my system, as soon as I inject an iMac14,2 in the smbios, the AGPM does not get loaded _at all_

Nice results! But I am wondering why with my system (also using a GTX 780) I am not getting the same results... more close to 45-50 than 70 on 10.10.3 (I am suspecting the fact that my GPU does not run at full speed and frequencies when Cinebench is running, but I am not sure...) Can I ask you if you could share your smbios.plist ? Also, have you patched the AGPM kernel extension ?

Yes, there is definitely an issue with the current webdrivers and how Yosemite uses them. What I suspect is that Yosemite rendering engine (I would suspect a high-level one, common to both Preview and Safari... maybe PDFKit directly) is using the hardware decoder for decoding JPEG images. -> With very special images, this brings scrambled images comparable to the ones shown in my first post. This makes me think that the Webdriver from NVIDIA is buggy... ... but I doubt that they will help, as no Maxwell is officially certified with these drivers. I am just wondering if macvidcards owners with real MacPros are also facing this issue...