Contribute
Register

macOS High Sierra Public Beta 6 is Now Available

Status
Not open for further replies.
My bad. Didn't realise that but how do I get back my CPU speed. The CPU speed is 2300 MHz however in the "about the Mac" it shows as 3.54GHz. I did changed the CPU frequency in config.plist but to no avail.

config.plist/CPU/FrequencyMHz=2300
 
Least painful upgrade yet between betas. I have heard that you no longer need to boot from an EFI without EmuVariables64 kext but I did anyway:
- use App Store update, click restart when prompted
- boot from USB stick Clover with no EmuVariables64 kext, select "installer" partition (seemingly a temporary partition the installer creates and destroys when done)
- arrive at secondary installer, let installer run, reboot
- boot as normal to working new beta

Again I've heard that EmuVariables64 no longer causes the osinstall.mpkg error during secondary install with this latest beta but haven't tested.

As far as apfs.efi, since I am on an APFS drive, I believe that you need at least the minus 1 generation of apfs.efi in your Clover. I always make a habit of deleting and redownloading the full "install macOS high Sierra beta" app and pulling apfs.efi out and replacing in my Clover install right away.

As far as ethernet, graphics and sound, I'm on a Pascal card and followed another thread to get partial Pascal support which involves using several custom installers (an patched installer that skips the OS version check, a utility that modifies the NvidiaWeb kext for OS version, and overwriting /S/L/E/AppleGraphicsControl.kext with the 10.12.6 version; after all that, while dual monitors work and "About this Mac" displays correctly, it's almost as glitchy as VESA mode). Ethernet works with the 10.12.x kext for my system, and I haven't bothered with sound as I get USB sound through my Apple display OOB.

Can confirm that having EmuVariableUEFI64.efi on the installer's boot EFI causes the OSInstall.mpkg error. Removing it fixes the error. I wonder what it is about Clover's NVRAM emulation that is conflicting with OSInstall.mpkg?

Also another troubling error is the infamous "Unable to Update Firmware" when a drive formatted by Windows is present during the installation (this true as of Clover v4179, I haven't tried newly released Clover v4184). What I've uncovered is that the Windows installer creates an EFI partition, but it is not the first partition of the drive, unlike drives formatted by OSX's DiskUtility. Instead windows creates the recovery partition as the first partition of the drive, and I'm wondering if the placement of the EFI partition on the windows drive is causing the firmware update error? If this isn't fixed in the Final Release, I wonder how the next version of Unibeast will deal with this issue.

Any thoughts @RehabMan ?
 
Can confirm that having EmuVariableUEFI64.efi on the installer's boot EFI causes the OSInstall.mpkg error. Removing it fixes the error. I wonder what it is about Clover's NVRAM emulation that is conflicting with OSInstall.mpkg?

Also another troubling error is the infamous "Unable to Update Firmware" when a drive formatted by Windows is present during the installation (this true as of Clover v4179, I haven't tried newly released Clover v4184). What I've uncovered is that the Windows installer creates an EFI partition, but it is not the first partition of the drive, unlike drives formatted by OSX's DiskUtility. Instead windows creates the recovery partition as the first partition of the drive, and I'm wondering if the placement of the EFI partition on the windows drive is causing the firmware update error? If this isn't fixed in the Final Release, I wonder how the next version of Unibeast will deal with this issue.

Any thoughts @RehabMan ?

EmuVariableUefi-64.efi doesn't really work without RC scripts executing at shutdown.
The scripts don't exist on the installer, so NVRAM really not working in this scenario.

Removing EmuVariableUefi-64.efi changes the nature of NVRAM failure.
 
What I've uncovered is that the Windows installer creates an EFI partition, but it is not the first partition of the drive, unlike drives formatted by OSX's DiskUtility. Instead windows creates the recovery partition as the first partition of the drive, and I'm wondering if the placement of the EFI partition on the windows drive is causing the firmware update error? If this isn't fixed in the Final Release, I wonder how the next version of Unibeast will deal with this issue.
There shouldn't be a requirement for the EFI partition to be the first on the disk, nor for there to be an EFI partition on every single disk, Apple thing. The next version of Unibeast will probably use a more recent version of Clover. Latest firmware version in SMBIOS = no need to attempt Mac firmware update = no more error. You can enter it in manually in your config plist or update Clover.
 
Last edited:
There shouldn't be a requirement for the EFI partition to be the first on the disk, nor for there to be an EFI partition on every single disk, Apple thing. The next version of Unibeast will probably use a more recent version of Clover. Latest firmware version in SMBIOS = no need to attempt Mac firmware update = no more error. You can enter it in manually in your config plist or update Clover.

Thanks bro. I completely agree with you, and for el capitan, sierra, and the first 3 betas of High Sierra, the presence of the windows drive did not interrupt the MacOS installer. However, ever since High Sierra beta4 or so, I've been getting the "unable to Update Firmware" Error if my Windows drive (initialized/formatted by the windows installer) is attached during installation. In fact, just clean installed Beta 6 using Clover 4179 (not 4184), using the latest firmware versions in Clover Configurator 4.49 and I get the same error if my windows drive is attached. Removing the drive that was initialized/formatted by the Windows installer allows the Beta6 installation to proceed without the firmware update error.

For testing purposes, I attached another windows drive during the installation process - but unlike the first drive, this one was initialized and formatted first by MacOS Yosemite's Disk Utility, and the installer for Beta 6 proceeds just fine without the "unable to update firmware" error.

I should note that the target disk for the Beta6 installation is an external USB drive, and that I only get the error when doing a clean install. Merely updating an already existing High Sierra installation from the App Store does not result in the error when the "offending" windows drive is attached.


Several users here on tonymac and elsewhere are reporting the same problem... it is a widespread issue.
 
Last edited:
EmuVariableUefi-64.efi doesn't really work without RC scripts executing at shutdown.
The scripts don't exist on the installer, so NVRAM really not working in this scenario.

Removing EmuVariableUefi-64.efi changes the nature of NVRAM failure.
Thanks Rehabman. What about the "unable to update firmware" error that several users are reporting if their windows drive (initialized/formatted by the Windows installer) is attached during the initial High Sierra Beta installer boot?
 
Last edited:
Thanks Rehabman. What about the "unable to update firmware" error that several users are reporting if their windows drive (initialized/formatted by the Windows installer) is attached during the initial High Sierra Beta installer boot?

Just Apple weirdness(see #16). I haven't experienced it personally.
 
Status
Not open for further replies.
Back
Top