Ok, so I kept my installation media for macOS 10.15 (Catalina) handy, booted in Recovery mode and completely wiped out the entire internal disk (not just the Machintosh HD APFS Volume) to make sure there was nothing there when I installed it fresh.
Had exactly the same problem. So I dug a little bit deeper, as going to Disk Utility and running the First Aid on the Machintosh HD and Machintosh HD - Data APFS Volumes didn't find anything wrong:
- Using First Aid on the APFS Container Container disk1 it did show some "Mismatch between extentref entry reference count (1) and calculated fsroot entry reference count (0) for extent" errors on a hidden APFS Volume called VM (remember this is was a "virgin" installation, so these errors where created by the installation process itself)
- Since Disk Utility didn't allow me to fix anything, I resorted to the Terminal and the equivalent command-line tool diskutil. A word of caution, typically command-line tools are case-sensitive, so be careful to use the commands exactly as I typed them (apart from the identifiers that may be different in your cases.
- First I decided to verify again (my main APFS Container has disk1 as its identifier)
diskutil verifyVolume disk1
- It showed me the same errors as before in the APFS Volume VM. I noted the specific volume's identifier (in my case disk1s4)
- I tried to fix it using a different command to repair it but it didn't fix anything
diskutil repairVolume disk1s4
Since from within macOS it wasn't working I decided to reboot into Recovery mode and try to verify and repair the volume from there (you can open the Terminal from the Utilities menu). I felt really smart... but ended up giving me the same results
Searching online a bit, I figured out the VM volume is used as "swap" (VM stands for Virtual Memory) which means it doesn't hold any meaningful data after macOS shuts down!
Armed with this information I decided to try and reset it following the instructions here:
1 - First I listed the volumes (to guarantee I worked on the right one) using
diskutil list
2 - I noted the VM volume's identifier was now disk2s4
3 - Then I erased it using
diskutil apfs eraseVolume disk2s4 -name VM
4 - After that I listed the volumes again to check what was the identifier of the new VM Volume (for me it was the same disk2s4 identifier as before)
diskutil list
5 - Then I changed the type of the Volume to the correct one (this volume is meant to be used for Virtual Memory)
diskutil apfs chrole disk2s4 V
6 - To make sure the volume was now correctly set, I listed the APFS Volumes, I noted that the VM APFS Volume now had a (VM) next to its identifier... it had worked
diskutil apfs list
7 - Once this final step was done, I verified the entire Container (because I was in Recovery mode, its identifier was now disk2) to see if it had fixed the errors
diskutil verifyVolume disk2
8 - Lo and behold, none of the volumes showed any errors (including the reset VM volume)
Happy with myself, and finally with some hope I restarted my computer, ran Boot Camp Assistant and this time there were no problems partitioning the drive (nor later installing Windows).
Hope this detailed account of the steps I took to solve it may help others facing the same issue!
