Running: VMware Fusion Player Version 12.0.0 (16880131)
on software: macOS Big Sur Version 11.0 beta (beta 6, beta 7, beta 8, beta 9, beta 10)
macOS Big Sur Version 11.0.1 beta
on hardware: MacBook Pro (15-inch, 2016)
Boot Camp VM from Fusion 11 encountered error: The operation on file "/dev/disk0s1" failed.
This error occurs when "Attempting to start up from: -> EFI VMware Virtual SATA Hard Drive (0.0) ..."
The problem persists when starting fresh and creating a new Boot Camp VM.
All non-BootCamp VMs seem to work fine so far (with the exception of sound).
What I've tried:
Notable/relevant errors in vmware.log:
vmx| I005: DEVCREAT: Found a device: /dev/disk0s1
vmx| I005: HOSTDISK-MACOS:Whole disk device path for /dev/disk0s1 is /dev/disk0.
vmx| I005: FILE:open error on /dev/disk0: Operation not permitted
vmx| I005: AIOGNRC: Failed to open '/dev/disk0' : Operation not permitted (10002) (0x101).
vmx| I005: OBJLIB-FILEBE : FileBEOpen: can't open '/dev/disk0' : Operation not permitted (65540).
vmx| I005: FILE:open error on /dev/disk0: Operation not permitted
vmx| I005: OBJLIB-FILEBE : FileBEOpen: can't open '/dev/disk0' : Operation not permitted (65540).
Notable/relevant errors in Console App:
client error 19:20:26.109292-1000 vmware-vmx unable to normalize volume: "<private>", tmp_result: <private>
client error 19:20:26.109386-1000 vmware-vmx Failed to get available space for volume <private>: Error Domain=CacheDeleteErrorDomain Code=10 UserInfo={Volume=<private>}
client error 19:20:26.109509-1000 vmware-vmx unable to normalize volume: "<private>", tmp_result: <private>
client error 19:20:26.109654-1000 vmware-vmx validatedCachedResults: unable to create keyName from: {
"CACHE_DELETE_AVAILABLE_SPACE_CLASS" = 3;
"CACHE_DELETE_VOLUME" = "/dev";
}
(See attachment for more from Console.)
I assume this is due to some new security feature in macOS 11 preventing programs from taking control of partitions/volumes.
Is this a known issue? Is there a fix or workaround?
Message was edited by: Jason_MC Attached vmware.log
Message was edited by: Jason_MC. Updated OS versions. Problem still exists.
Message was edited by: Jason_MC. Updates OS versions. Added apparently relevant lines from vmware.log.
Message was edited by: Jason_MC to include having tried recreating Boot Camp partition.
Message was edited by: Jason_MC. Updated OS Versions. Now tested on Big Sur betas 6 through 10. Problem remains the same.
Message was edited by: Jason_MC. Updated OS Versions tested. Same problem and symptoms on macOS 11.0.1 beta
Hi Jason_MC ,
Could you help to upload vmware.log of your BootCamp VM? Thanks.
Attached vmware.log to original post.
For reference, from diskutil:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 314.6 MB disk0s1
2: Apple_APFS Container disk1 880.0 GB disk0s2
3: Microsoft Basic Data BOOTCAMP 120.2 GB disk0s3
Having the same problem here.
Bump.
Having the exact same issue.
Just upgraded to Big Sur beta 8.
Fusion still can't boot VM from Boot Camp Partition.
Is there seriously not a fix for this yet?!?!? It's basically the entire purpose of the software.
Have you tried creating a new boot camp partition with the big sur boot camp wizard on the internal drive and then virtualizing that?
Is there seriously not a fix for this yet?!?!? It's basically the entire purpose of the software.
Are you seriously running a BETA version of an OS on your host computer and then complaining when things don't work?
dlhotka
I have not deleted and re-created my Bootcamp partition, because (1) I am temporarily limited on backup space to fully backup my current Bootcamp partition and (2) because this problem seems to be related to VMWare Fusion 12 trying to mount the full disk (disk0) rather than only the EFI (disk0s1) and Bootcamp (disk0s3) partitions. If that is the case, then recreating the partition won't change anything.
I have, however, completely deleted/removed my Bootcamp VM and created a new one with Fusion 12, but no change.
If I get my extra drive back soon, I will try backing up my Bootcamp partition, deleting it, and creating a new one with Big Sur's boot camp wizard.
Upgraded to Big Sur Beta 9; deleted and re-created Bootcamp VM. Same issue remains.
This problem seems to entirely come from being unable to access the EFI partition (/dev/disk0s1).
I don't know if Big Sur is somehow preventing access to this partition (although I've enabled/disabled everything I can think of that would do this) or if there's a problem with the way Fusion 12 is requesting to mount/access it.
Either way, could Fusion 12 be configured boot the Bootcamp partition without needing to access the EFI partition?
My newest "vmware.log" and "Boot Camp.vmdk" are attached.
tacomeat82 Relax. As far as I can tell, this issue only affects Bootcamp VMs on Big Sur, which is still in beta. Bugs are expected.
RDPetruska Yes. Some of us are developers working on iOS and macOS software and consequently running/testing beta OSes so that our products can be released when the OSes graduates from Beta. Aside from tacomeat82's complaining, reporting problems and pushing for solutions is part of the process.
nancyz You asked for my vmware.log a few weeks ago. Do you have any progress/suggestions/workarounds to share with us?
Jason,
I completely understand the need for developers to run their systems on Beta software, and provide feedback. Most of us developers choose to run the beta OS inside of a guest, however, so as not to totally bork our hosts. In any case, my comment was certainly not aimed at you and your bug report/feedback, but to the other user's complaining that "there seriously isn't a fix for this yet?". I was merely trying to point out that he/she was being completely ridiculous. It's all good.
Hmmm, I was wondering if the boot camp wizard in Big Sur did some new juju that didn't come across with upgrades. Sounds like something broke between the Fusion 12 go live freeze and one of the later big sur betas. Apple's gotten really bad the past few years about doing major plumbing changes late in the beta process.
I tried dlhotka's idea today but still no luck.
I restarted into windows and did a full backup to an external drive.
Then, I restarted into Big Sur and ran the Boot Camp Assistant to remove the Boot Camp Partition.
I restarted, then ran the Boot Camp Assistant again to create a shiny, new Boot Camp Setup.
After Windows 10 was installed and fully updated, I restarted back into macOS.
I opened Fusion 12 and created a new Boot Camp virtual machine with the default settings.
After that, the problem is exactly as described before.
I have attached the vmware.log from this attempt, just in case there's something different in there that I didn't notice.
Ugh...well, it was worth a shot. I'm out of ideas....
Bump.
Is anyone successfully running a Bootcamp VM (direct from Bootcamp Volume, not imported) on any version of macOS Big Sur?
If so, I'd like to compare files/settings to hopefully find a workaround.
Here is what I do
1. Create a bootcamp vm, keep the other settings remaining default.
2. Add a hard drive with 200mb capacity.
3. Boot the VM using Win10 install CD
4. Repair Computer->Command Line
5. Convert the 200mb hd into GPT and create a EFI partition using diskpart command.
6. Mount EFI partition
7. Use bcdboot command to install boot loader onto the newly created EFI partition.
8. Reboot the computer
9. You will need to ignore the disk0s1 error and choose the boot device every time you start the bootcamp vm.
Is VMware acknowledging this issue and working on it? Not sure whether the upgrade to Big Sur altered the EFI Boot Loader on Bootcamp partition or whether it is a problem with VMware. I can boot to the Bootcamp partition without problem. Just can't open it from VMware.