The source VMware installation reached a specific failure state: after the installer appeared to complete, GRUB displayed Slot A (ok = 0, Try = 0), then the VM fell to a black screen with a blinking cursor. Selecting Slot B produced an unknown-filesystem error.
The thread never reached a confirmed VMware root cause. Community members suspected the system slots had not been created correctly, but IceWhale continued asking for reproduction details rather than endorsing that theory. Current ZimaOS documentation now provides a dedicated Proxmox VM installation guide; it does not currently publish an equivalent VMware Workstation guide.
The User Followed the Published VMware Settings
- ZimaOS 1.5.1 installer ISO
- Other Linux 6.x 64-bit
- UEFI
- SATA controller
- 32 GB virtual disk
- 4 CPU cores
- initially 2 GB RAM
Increasing RAM to 8 GB Did Not Fix the Source Case
A community user suggested 4-8 GB RAM. Mr.E increased the VM to 8 GB and explicitly reported that the black-screen behavior remained.
Booting Slot B Also Failed
The user selected Slot B from GRUB and received an Unknown file system error. That reinforced the idea that the installed system slots were unhealthy, but it still did not reveal why VMware created that state.
The ok=0 Interpretation Came from the Community
gelbuilding observed that both system slots showed ok = 0 and proposed that VMware's hardware abstraction prevented the installer from creating valid slots. This is a plausible community interpretation, not an IceWhale-confirmed limitation.
IceWhale Did Not Publish a Final VMware Fix in the Thread
Zima-Giorgio asked for video and host hardware details. The source ends while the user is considering a VMDK conversion path; no staff reply confirms a specific controller, firmware, or image-conversion solution.
Current Official VM Documentation Focuses on Proxmox
IceWhale's current Proxmox guide uses a ZimaOS ISO and recommends UEFI, no added EFI disk, 4 CPU cores or more, and 8 GB RAM or more.
Use the current official ZimaOS VM installation path when you need a documented hypervisor workflow.
No Current VMware Guide Is Not the Same as “VMware Can Never Work”
Some users may run ZimaOS on VMware with another virtual disk format, controller, or firmware setup. The public source simply does not establish a reliable recipe.
If Testing VMware Today, Capture the Install State Precisely
- current ZimaOS image/version
- VMware version
- UEFI/Secure Boot state
- virtual disk controller and format
- GRUB Slot A/Slot B status
- full installer/boot console output
Slot A and Slot B Are Part of ZimaOS's Dual-System Recovery Design
ZimaOS maintains two system slots so updates/recovery can boot an alternate system partition. Seeing both slots as invalid is therefore more significant than a single graphical-console failure: the bootloader did not regard either installed slot as a healthy boot target.
That observation still does not identify whether the installer, virtual disk controller, filesystem, firmware, or VMware-specific device model caused the invalid state.
Separate Installer Success from Installed-System Success
The source installer appeared to complete, but the first boot failed. A successful installer UI/automatic sequence is not enough; always remove/detach the installer media as instructed and verify the installed virtual disk boots independently.
UEFI Details Matter in Virtual Machines
Current IceWhale Proxmox instructions are specific about UEFI and even say not to add an EFI disk in that workflow. Hypervisors expose firmware and boot storage differently, so copying a Proxmox setting into VMware—or an old VMware setting into a newer Workstation release—can produce a different boot layout.
The Virtual Disk Controller Is Part of the Compatibility Surface
SATA, SCSI, NVMe, and virtio-style virtual controllers present storage differently to the guest. The source used SATA because the historical tutorial told it to. If testing another controller, change one variable at a time and preserve the failed VM for comparison.
The Source's VMDK Conversion Idea Was Never Verified
At the end of the thread, Mr.E said they would try converting a ZimaOS image to VMDK. There is no follow-up confirming that approach worked, so it should not be presented as the solution.
Use Proxmox When You Want the Current Documented VM Path
If the goal is evaluating ZimaOS in a VM rather than validating VMware compatibility specifically, the current Proxmox method has the strongest IceWhale documentation and removes several unknowns from the test.
VMware Installation FAQ
Did increasing memory solve the source case?
No. The user tested 8 GB and the failure remained.
Did the thread confirm VMware hardware abstraction was the root cause?
No. That explanation came from a community reply and was not confirmed by IceWhale.
Which VM platform does current IceWhale documentation explicitly cover?
Current ZimaOS documentation includes a dedicated Proxmox VE installation guide.
