Posts Tagged ‘troubleshooting’

Minisforum MS-A2 HOW TO: Fix the Failed to Update CPU#0 Microcode PSOD with ESXi 8.0.3i ESXi 8.0u3i

Wednesday, March 11th, 2026

Minisforum MS-A2 HOW TO: Fix the Failed to Update CPU#0 Microcode PSOD with ESXi 8.0.3i ESXi 8.0u3i

 

HOW TO: Fix “Failed to update CPU#0 microcode” PSOD on ESXi 8.0.3i (Minisforum MS-A2)

In this guide from Hancock’s VMware Half Hour, I demonstrate how to fix the
Purple Screen of Death (PSOD) error:

“Failed to update CPU#0 microcode”

This issue occurs when installing or booting VMware ESXi 8.0 Update 3i (ESXi 8.0.3i)
on the Minisforum MS-A2 mini workstation.

ESXi 8.0.3i, released on 2 March 2026, includes security fixes for
CVE-2025-15467, an OpenSSL vulnerability. If you are running ESXi and have not
patched yet, you should update as soon as possible.

However, this update also includes new AMD CPU microcode updates, which currently
appear to trigger a PSOD during boot on the Minisforum MS-A2 platform.


The Problem

When booting the ESXi 8.0.3i installer (for example from Ventoy) on the
Minisforum MS-A2, the system may fail during boot with the following PSOD message:

The system has found a problem on your machine and cannot continue.

Failed to update CPU#0 microcode

This prevents ESXi from completing the boot process or installer launch.


Why This Happens

The ESXi 8.0.3i update includes newer AMD microcode updates intended to improve
security and stability. Unfortunately, these updates currently appear to be
incompatible with the MS-A2 platform, which results in the microcode update failing
during boot.

When the microcode update fails, ESXi halts the boot process and displays the PSOD.


The Workaround

Until VMware releases a permanent fix, the issue can be worked around by using a
kernel boot option during ESXi startup.

Steps to Fix

  1. Boot the ESXi 8.0.3i installer.
  2. When the ESXi boot screen appears, press Shift + O.
  3. This opens the ESXi boot options.
  4. Add the required kernel option shown in the video.
  5. Press Enter to continue booting.

With the boot option applied, ESXi should boot successfully on the Minisforum MS-A2.


Video Walkthrough

Watch the full walkthrough below where I demonstrate the issue and apply the workaround.


What You Will Learn

  • What changed in ESXi 8.0.3i
  • Why AMD microcode updates trigger a PSOD
  • How to reproduce the issue during boot
  • The Shift + O ESXi boot workaround
  • How to confirm the fix works successfully

Credits

Huge thanks to members of the VMware community who investigated and documented this issue:

  • Stephen Wagner
  • Patrick Kernstock
  • vAndu
  • Martin Gustafsson

Their research and testing helped identify the workaround shown in this video.

Resources:


Support My Work

? Enjoying the content? Support the channel with an espresso!

Buy Me an Espresso Coffee

Donate via PayPal


Follow Hancock’s VMware Half Hour


Support British Beekeeping ?

If you’d like to support British beekeeping, you can purchase
raw pure honey from my apiaries.

Meltonby Honey – Raw Pure Honey

UK shipping currently only.

HOW TO: Synchronize Changes in a Linux P2V with VMware vCenter Converter Standalone 9.0 (Part 101)

Thursday, November 27th, 2025

If you’ve ever attempted a P2V migration using VMware vCenter Converter Standalone 9.0, you’ll know that the product can be as unpredictable as a British summer. One minute everything looks fine, the next minute you’re stuck at 91%, the Helper VM has thrown a wobbly, and the Estimated Time Remaining has declared itself fictional.

And yet… when it works, it really works.

This post is the follow-up to Part 100: HOW TO: P2V a Linux Ubuntu PC, where I walked through the seed conversion. In Part 101, I push things further and demonstrate how to synchronize changes — a feature newly introduced for Linux sources in Converter 9.0.

I won’t sugar-coat it: recording this episode took over 60 hours, spread across five days, with 22 hours of raw footage just to create a 32-minute usable video. Multiple conversion attempts failed, sequences broke, the change tracker stalled, and several recordings had to be completely redone. But I was determined to prove that the feature does work — and with enough perseverance, patience, and the power of video editing, the final demonstration shows a successful, validated P2V Sync Changes workflow.


Why Sync Changes Matters

Traditionally, a P2V conversion requires a maintenance window or downtime. After the initial seed conversion, any new data written to the source must be copied over manually, or the source must be frozen until cutover.

Converter 9.0 introduces a long-requested feature for Linux environments:

Synchronize Changes

This allows you to:

  • Perform an initial seed P2V conversion

  • Keep the source machine running

  • Replicate only the delta changes

  • Validate the final migration before cutover

It’s not quite Continuous Replication, but it’s closer than we’ve ever had from VMware’s free tooling.


Behind the Scenes: The Reality of Converter 9.0

Converter 9.0 is still fairly new, and “quirky” is an understatement.

Some observations from extensive hands-on testing:

  • The Helper VM can misbehave, especially around networking

  • At 91%, the Linux change tracker often stalls

  • The job status can report errors even though the sync completes

  • Estimated Time Remaining is not to be trusted

  • Each sync job creates a snapshot on the destination VM

  • Converter uses rsync under the hood for Linux sync

Despite all this, syncing does work — it’s just not a single-click process.


Step-by-Step Overview

Here’s the condensed version of the procedure shown in the video:

  1. Start a seed conversion (see Part 100).

  2. Once complete, use SSH on the source to prepare a 10GB test file for replication testing.

  3. Run an MD5 checksum on the source file.

  4. Select Synchronize Changes in Converter.

  5. Let the sync job run — and don’t panic at the 91% pause.

  6. Review any warnings or errors.

  7. Perform a final synchronization before cutover.

  8. Power off the source, power on the destination VM.

  9. Verify the replicated file using MD5 checksum on the destination.

  10. Celebrate when the checksums match — Q.E.D!


Proof of Success

In the final verification during filming:

  • A 10GB file was replicated

  • Both source and destination MD5 checksums matched

  • The Linux VM booted cleanly

  • Snapshot consolidation completed properly

Despite five days of interruptions, failed jobs, and recording challenges, the outcome was a successful, consistent P2V migration using Sync Changes.


Watch the Full Video (Part 101)

If you want to see the whole process — the setup, the problems, the explanations, the rsync behaviour, and the final success — the full video is now live on my YouTube channel:

Part 101: HOW TO: Synchronize Changes using VMware vCenter Converter Standalone 9.0

If you missed the previous part, you can catch up here:
Part 100: HOW TO: P2V a Linux Ubuntu PC Using VMware vCenter Converter Standalone 9.0


Final Thoughts

This video was one of the most challenging pieces of content I’ve created. But the end result is something I’m genuinely proud of — a real-world demonstration of a feature that many administrators will rely on during migrations, especially in environments where downtime is limited.

Converter 9.0 may still have rough edges, but with patience, persistence, and a bit of luck, it delivers.

Thanks for reading — and as always, thank you for supporting Andysworld!
Don’t forget to like, share, or comment if you found this useful.