Upgrade to 0089, it's stable, with no know bugs until now and required to install Mojave Public Beta 3. Read the first post.
Last edited:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP5,1: Return of the microcodes (MP51.0089.B00) **OBSOLETE**
- Thread starter tsialex
- Start date
-
- Tags
- mp51.0089.b00
- Sort by reaction score
- Status
Upgrade to 0089, it's stable, with no know bugs until now and required to install Mojave Public Beta 3. Read the first post.
I also got version 31 with 0087.B00 in PB2. So, I expect 0087.B00 can also enjoy the version 31 in PB3, but I haven't test it. So, not 100% sure.
Take a look on the first post on the thread, my X5677 received microcode 31 too, on 10.13.6beta something. Microcodes can be updated on-the-fly, if Apple decides for it, like XProtect or Gatekeeper.
Screenshot from July 10:
Last edited:
Weird. In Mojave Developer Beta 4 mine is most definitely microcode 30, running 0089 firmware on an X5690.
I understand they can be updated by an OS inject, but it's not happening in my case.
I suspect that Apple is doing a limited/controlled test with the new microcodes, on my office Mac Pro, with dual X5677, the microcode still on the 30 release - both my home and my office Mac Pros updated to 10.13.6 on the same day.
Very strange.
I'm running the same CPU's with 89 firmware and my microcode is still on 30
Attachments
The tool, plus a daemon, that updates microcodes on-the-fly on macOS is ucupdate:
Code:
/usr/libexec/ucupdateI'm at the office, release 30 here, and the microcode.dat version is:
Code:
x5677:~ alexandretorres$ /usr/libexec/ucupdate -q
signature: 0x206c2
microcode_version: 0x1e
processor_flag: 0x0The microcode.dat file is stored on:
Code:
x5677:~ alexandretorres$ ls -la /usr/share/ucupdate/
total 8264
drwxr-xr-x 3 root wheel 96 Jul 10 00:59 .
drwxr-xr-x 47 root wheel 1504 Jul 8 04:48 ..
-rw-r--r-- 1 root wheel 5036937 Jun 23 01:11 microcode.datMaybe @h9826790 could check his version, if not I'll check tonight on my home Mac Pro.
Code:
Emiles-Mac-Pro:~ emilekukkuk$ ls -la /usr/share/ucupdate/
total 6264
drwxr-xr-x 3 root wheel 96 Jul 10 09:37 .
drwxr-xr-x 47 root wheel 1504 Mar 30 09:08 ..
-rw-r--r-- 1 root wheel 5036937 Jul 4 15:01 microcode.dat
Emiles-Mac-Pro:~ emilekukkuk$ /usr/libexec/ucupdate -q
signature: 0x206c2
microcode_version: 0x1e
processor_flag: 0x0Yours is newer than mine, July 4 versus June 23. I can be wrong but I think that the dates are for creation date, not install date - June 23 on my rMBP too.
Edit: Checking shasum of microcode.dat on various Macs,
e4a3e90cbb0bcf6462297d29bd92058b62bd10e0, it's the same on all, even if the creation date is different. Need to check the shasum on my Mac that have 31 release.
Last edited:
I wonder if the difference is due to me never going to 87, but only directly from 85 to 89?
Nope, I had 31 microcode on 0085.
I've checked the shasum on my rMBP, mini, work MP and some VMs, it's the same on all:
e4a3e90cbb0bcf6462297d29bd92058b62bd10e0
So, I was wrong about the dates since on DP4 it's newer than all, but same shasum.
Code:
Emiles-Mac-Pro:ucupdate emilekukkuk$ shasum microcode.dat
e4a3e90cbb0bcf6462297d29bd92058b62bd10e0 microcode.datIt gets stranger and stranger. The sums seems exactly the same
If someone else on the 31 could check the shasum and if it's different from e4a3e90cbb0bcf6462297d29bd92058b62bd10e0, we could have the confirmation that Apple is doing a controlled test with the new microcode.
I have upgraded my (dual) 12-core cMP 4,1>5,1 to 10.13.6 (full installer) and FW 0089.B00 almost without incident. I damn forgot to install 10.13.6 via the command line with the --nointeraction operand, so my Boot drive (Accelsior S SATA III PCIe) has now been converted to APFS. I was holding off on APFS for something of a more polished version as my User data is a Fusion Drive consisting of a Samsung 960 EVO M.2 NVMe blade paired with a WD Black 2TB spinner.
Luckily everything is working and playing fine. BUT should I be reformatting it back to JHFS+ and copying my boot data back? What issues am I likely to encounter being on AFPS with my setup?
Luckily everything is working and playing fine. BUT should I be reformatting it back to JHFS+ and copying my boot data back? What issues am I likely to encounter being on AFPS with my setup?
Last edited:
If it's working, I think you can leave it at APFS. Just make sure you has proper bootable backup, and able to recover (or revert to HFS+) when required.
I also let 10.13.6 convert my SSD on my Hackintosh for testing purpose. I've done that just for a week. So far so good.
Goodness knows why my Time Machine (dating back 3 months) has been completely hosed AGAIN, and is currently making it's first backup (2.2TB). Grrr! No going back to HS now via TM. Luckily I have a fairly recent complete backup for the boot/apps SSD, and the FD User data, but it's a pita why TM completely resets itself every time I upgrade for both major macOS upgrades (like Sierra to HS) and for each incremental upgrade (like 10.13.5 to 10.13.6). Double Grrr!!
Everything else appears to be running fine. I can still see all my PCI adapters (both GPUs, SATA III SSD, NVMe) - this was all missing from El Capitan to Sierra - it would just show a 'no information is available' message.
Will see if the upgrade to 10.13.6 and FW 0089.B00, and from JHFS+ to APFS make any difference in boot times and app launches etc. Usually took 14 secs from cold startup to get to the boot up chime, and roughly another 15 secs to get to the logon user accounts screen.
Everything else appears to be running fine. I can still see all my PCI adapters (both GPUs, SATA III SSD, NVMe) - this was all missing from El Capitan to Sierra - it would just show a 'no information is available' message.
Will see if the upgrade to 10.13.6 and FW 0089.B00, and from JHFS+ to APFS make any difference in boot times and app launches etc. Usually took 14 secs from cold startup to get to the boot up chime, and roughly another 15 secs to get to the logon user accounts screen.
Not sure if it’s conincident. My TM just warm me no backup successful in the last 10 days. And end up the only solution is also start everything again. Exactly the same size as yours, 2.2TB.
It worked perfectly on my nTB 2016. I also upgraded BootCamp services and software.
Thank you so much ! You're a boss !
I always has CCC bootable backup. But that's more for whole drive / system backup. For single file, TM has better UI for easy recovery. So, I use it to make 2nd backup of some very important files.
Exactly the same - I use TM for incremental backups, and CCC for monumental ones. Took around 4.5 hours to do the full TM backup.
Update: it was actually closer to 6 hours when I look at the iStats info.
Last edited:
4.5hr is quick.
My TM backup is on the Apple 3TB Time Capsule. The backup speed is below 25MB/s. And it cost 25hr to finish the initial backup.
Actually, not true.
I just installed Mojave on my 5,1 and it told me it had to do a firmware update first.
I've now got MP51.0085.B00.
- Status