Contributor
Contributor

Fusion 12 can't use Boot Camp volume

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)

ScreenShotBCVMerror.png

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:

  • Completely removing and recreating Boot Camp partition
  • Granting Full Disk Access to VMware Fusion 12
  • Deleting the VM are starting anew with VMware Fusion 12
  • Disabling SIP
  • Reset NVRAM
  • Running First Aid on all disks/volumes from Recovery Mode
  • Launching VMware Fusion as root (sudo)
  • Booted MacBook directly into boot camp partition and:
    • verified free space
    • verified no file system problems/errors
    • installed updates

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

53 Replies
Contributor
Contributor

that's good news and hopefully it gets fixed. I am running out of storage space because I have to create a temporary additional VM of the bootcamp partition just to run my windows app

Contributor
Contributor

To solve this problem pending a fix you may disable the Hard Disk Cache option under the VM's advanced option dialog. For me, this allows the direct disk access mode boot camp image to run under Big Sur. Does it work for you?

Tags (2)
Contributor
Contributor

Thank you very much!! It works for me. But Windows runs much slower due to HDD access takes time by the setting.

By the way, the setting takes effect and the problem goes away, then how the problem goes to Big Sur bug? It seems for me that the problem might come from Fusion's code related to the HDD cache.

 

Enthusiast
Enthusiast

It works, thanks for the suggestion (so easy to apply) 🙂

 

Windows seems to run slower and my Mac's fans went crazy, though.

 

But it should be enough for my job's needs, until we get a better solution.

Contributor
Contributor

Cool. It works also for me.

Anyway, I don't think it's a Big Sur problem.

I was on Catalina and with Fusion 11.5.6 there was no problem. After updated to Fusion 11.5.7 (still in Catalina) it started to complain.

The upgrade to Big Sur and Fusion 12 changed nothing.

 

Contributor
Contributor

Thanks, @david_lee_smith.

Like the other comments, this allows the Boot Camp VM to boot, but for my purposes it is unusably slow without disk caching. I've recently installed Parallels, to get this working and that has worked great and is significantly faster than Fusion 12 without disk caching, so I will be using that for the time being.

Like an earlier comment, I'm also skeptical about this being an Apple bug in Big Sur, since other VM software doesn't have this problem.

Whatever the cause, I hope this gets fixed before I reopen my business, because I don't want to have migrate my whole business to parallels. Here's hoping 🍻

Contributor
Contributor

Outstanding.  Great find!!!

 

Still work to be done by Apple or VMWare to sort this properly, and resolve any sluggishness, but at least we can get into our BC VMs finally.

 

Thank you and give yourself a pat on the back!

0 Kudos
Contributor
Contributor

Screenshot 2020-11-29 at 19.15.14.png

A workaround has been found by david_lee_smith who has shown how to allow to login.  See page 3 of this thread Nancy and please forward onto developers.  

Turning off the hard-disk cache results in a very slow VM, but at least it's access.

 

0 Kudos
Contributor
Contributor

Hi

that is no Solution when I do that my Daily Work looks 3 hours longer for same things that's only a workaround

and VMware don't fix that since more than 4 weeks that's a shame I have deleted now my 15 years used VMware

product and installed Parallels for now that works fast and smooth maybe I try VMware at a other Time but that here

is a Joke a real Joke nothing more Support is something different !!!!!!

Andre

Contributor
Contributor

To be fair to VMWare, Big Sur did introduce significant changes to the way VMs run on macOS. Kernel extensions are now deprecated in favour of system extensions and so some not insignificant engineering work was required to get it running, I'm guessing. I was actually surprised they were so fast out of the gate.

That's not to say they should have crowed about VMWare12 being 'ready' for Big Sur when it clearly wasn't. But fixing bugs does take time and can be a matter of working out between the host OS and the app just where the difficulty lies. 

That said, it's been a while now.

0 Kudos
Contributor
Contributor

I just upgraded to Big Sur and then discovered there was an issue with accessing bootcamp volume. Any updates on this?

0 Kudos
Contributor
Contributor

I gave up waiting and bought Parallels instead. No regrets. 

0 Kudos
Contributor
Contributor

I switched from Parallels to Fusion based on the pricing. I'm still using Fusion with a non-bootcamp Windows 10 VM while VMWare figures this out. I also tried to import my Bootcamp partition into a Fusion VM thinking that it was an issue accessing the partition vs. a regular file but I can't get Fusion to even read the data from my Bootcamp partition. I would like to make a DD image and then convert that into a Fusion hard drive but I haven't figured that out for now.

0 Kudos
Contributor
Contributor

I started playing around with this some more as the 4th partition on my SDD is Ubuntu. I was able to use Fusion 12 on Big Sur (version 11.1) and open my VM that uses the native partition directly. This led me to suspect that there is a problem with accessing my SSD's EFI partition (partition 1) as my Ubuntu VM boots from a virtual IDE drive that just contains a FAT grub install.

I added another small virtual IDE drive to my Ubuntu installation, created a Type EF partition it, formatted it as MSDOS, and then copied my SSD EFI partitions files onto it (I use Refind). I shut down the Ubuntu VM and moved the files for this new HD over to my Bootcamp VM folder. I added a new IDE to Bootcamp using the copied vmdk files. I changed the Startup option to start from this new virtual HD. Windows craps out when trying to start, but now gives me the option of hitting "esc" to get to the EFI menus. From there I can boot into the physical Windows 10 partition. 

I have to hit escape and go through this at each Bootcamp VM startup, but I am virtualizing my Windows 10 partition. Hope this helps. If anyone figures out how to tell the VM Windows 10 to boot from the virtual IDE, let me know. I am looking up bcdedit.exe usage now.

0 Kudos