Opened 9 years ago
Last modified 8 years ago
#14613 new defect
raw disk access to bootcamp partition fails with 5.0.2 & 5.0.4
Reported by: | aschmitz | Owned by: | |
---|---|---|---|
Component: | virtual disk | Version: | VirtualBox 5.0.4 |
Keywords: | raw disk bootcamp | Cc: | |
Guest type: | Windows | Host type: | Mac OS X |
Description
I've had a Windows 7 guest configured for raw disk access to my bootcamp partition for a long time. The guest works in VirtualBox 5.0.0, but it fails to start in the version 5.0.2, and 5.0.4. I've attached the VBox.log file and contents of the pop-up error from version 5.0.4.
Reverting to 5.0.0 fixes the problem.
Attachments (7)
Change History (23)
by , 9 years ago
Attachment: | vbox-504-error.txt added |
---|
comment:1 by , 9 years ago
Same issue occurs for me with the latest build (102780) reverting to 5.0.0 fixes it. I upgraded from the latest 4.3 to 5.0.4 when I hit this; downgrading as suggested was the only way to solve it. I've attached log files. Also involves accessing bootcamp partition, now with Windows 10 (filename still says Windows8 since I upgraded 8 to 10 recently).
comment:2 by , 9 years ago
Also added a log file of a successful load of 5.0.0, the funny thing is that it does give a similar error:
00:00:01.806422 VMSetError: /Users/vbox/tinderbox/mac-rel/src/VBox/Storage/VD.cpp(6403) int VDOpen(VBOXHDD*, const char*, const char*, unsigned int, VDINTERFACE*); rc=VERR_NOT_SUPPORTED 00:00:01.806450 VMSetError: VD: error VERR_NOT_SUPPORTED opening image file '/Users/username/VMs/Windows8.vmdk' 00:00:01.806939 AIOMgr: Endpoint for file '/Users/username/VMs/Windows8.vmdk' (flags 00040723) created successfully 00:00:01.808224 AIOMgr: Endpoint for file '/Users/username/VMs/Windows8-pt.vmdk' (flags 000c0723) created successfully 00:00:01.809728 AIOMgr: Endpoint for file '/dev/disk0s1' (flags 000c0723) created successfully
But then still succeeds, whereas the 5.0.4 and latest build error out after that line.
comment:3 by , 9 years ago
I thought I should add that I get the same errors, and the guest fails to start with version 5.0.6.
comment:4 by , 9 years ago
I've noticed the same error, cane open existing raw partition. Everything works on almost any latest 4.x version (at least for more than a year).
follow-up: 7 comment:6 by , 9 years ago
Please could you try the latest test build from here. It will most likely not change anything but it will be more verbose when code (which was introduced with 5.0.2) fails. Please provide also the corresponding VBox.log file when such a VM is started with the test build. Thank you!
by , 9 years ago
Attachment: | VBox.log.5.0.11 added |
---|
VBox log of a failed start with Virtual Box 5.0.11
comment:7 by , 9 years ago
Replying to frank:
Please could you try the latest test build from here. It will most likely not change anything but it will be more verbose when code (which was introduced with 5.0.2) fails. Please provide also the corresponding VBox.log file when such a VM is started with the test build. Thank you!
I have uploaded a VBox log of a failed start with the newest testing version of Virtual Box. The error message is the same as above. That is:
VD: error VERR_NOT_SUPPORTED opening image file '/Users/alex/VirtualBox VMs/Debian/CryptHome.vmdk' (VERR_NOT_SUPPORTED). VD: error VERR_ACCESS_DENIED opening image file '/Users/alex/VirtualBox VMs/Debian/CryptHome.vmdk' (VERR_ACCESS_DENIED). Failed to open image '/Users/alex/VirtualBox VMs/Debian/CryptHome.vmdk' in read-write mode (VERR_ACCESS_DENIED). Failed to attach driver below us! Access denied. (VERR_ACCESS_DENIED). AHCI: Failed to attach drive to Port1 (VERR_ACCESS_DENIED). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
comment:8 by , 9 years ago
Also replying to frank
Here is a VBox log of failed start with version 5.0.11 r104622
VD: error VERR_NOT_SUPPORTED opening image file '/Users/monospaced/VirtualBox VMs/BOOTCAMP/BOOTCAMP.vmdk' (VERR_NOT_SUPPORTED). VD: error VERR_NOT_SUPPORTED opening image file '/Users/monospaced/VirtualBox VMs/BOOTCAMP/BOOTCAMP.vmdk' (VERR_NOT_SUPPORTED). Failed to open image '/Users/monospaced/VirtualBox VMs/BOOTCAMP/BOOTCAMP.vmdk' in read-write mode (VERR_NOT_SUPPORTED). Failed to attach driver below us! Not supported. (VERR_NOT_SUPPORTED). AHCI: Failed to attach drive to Port0 (VERR_NOT_SUPPORTED). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
comment:9 by , 9 years ago
Thanks to both of you for the additional log file. alexpk and monospaced, could you provide the output of /bin/df? The interesting line is HBDMgrClaimBlockDevice: DADiskUnmount("/dev/disk0s4") failed with VERR_NOT_SUPPORTED (<no detail>) although there is no detailed error information logged. Is /dev/disk0s4 (/dev/disk0s7" for alexpk) some special kind of hard disk?
comment:10 by , 9 years ago
/dev/disk0s4 is an physical partition on my Mac, where Windows 7 is installed via Bootcamp.
By following the tutorial below, I was previously able to access this Bootcamp partition through VirtualBox (so no need to reboot the Mac), and everything stayed in sync (this works in VB 4 but not in recent 5. versions)
Instead of creating a virtual hard disk file like normal virtual machine, it uses a small special file that essential let the VM access the real physical disk.
https://kindlevsmac.wordpress.com/2011/10/14/how-to-run-windows-7-bootcamp-in-virtualbox/
Here is the output of df (note disk0s4 is not mounted, in preparation for being used by VirtualBox):
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/disk0s2 346Gi 174Gi 172Gi 51% 45546744 45131485 50% / devfs 183Ki 183Ki 0Bi 100% 634 0 100% /dev map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home /dev/disk1s1 95Mi 93Mi 1.7Mi 99% 23793 441 98% /Volumes/VirtualBox
comment:11 by , 9 years ago
Same here /dev/disk0s7 is a physical partition. I created it by hand for a linux installation.
Here is the output of df
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on /dev/disk1 311787296 112876192 198399104 37% 14173522 24799888 36% / devfs 371 371 0 100% 642 0 100% /dev /dev/disk0s4 409600 36640 372960 9% 4578 46620 9% /Volumes/ArchLinux /dev/disk0s8 418722328 202396664 216325664 49% 25299581 27040708 48% /Volumes/Shared Data map -hosts 0 0 0 100% 0 0 100% /net map auto_home 0 0 0 100% 0 0 100% /home
This is the output of "diskutil list". (Maybe it is more informative.)
/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.3 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_CoreStorage Macintosh HD 160.0 GB disk0s2 3: Apple_Boot Recovery HD 650.1 MB disk0s3 4: Apple_HFS ArchLinux 209.7 MB disk0s4 5: Linux Filesystem 37.6 GB disk0s5 6: Linux Swap 17.2 GB disk0s6 7: Linux Filesystem 69.8 GB disk0s7 8: Apple_HFS Shared Data 214.4 GB disk0s8
comment:12 by , 9 years ago
Would it help with debugging to know that this problem manifests when "Use Host I/O Cache" is disabled (for the SATA controller) and does not manifest when it is enabled, or is that likely to be a red-herring?
comment:13 by , 9 years ago
Can confirm I no longer experience the issue after enabling "Use Host I/O Cache" for the SATA controller.
comment:14 by , 9 years ago
Enabling "Use Host I/O Cache" also solves the problem for me. (In detail, I checked that this works with last official release 5.0.10.)
follow-up: 16 comment:15 by , 8 years ago
Enabling "Use Host I/O Cache" solves (still present) problem in 5.0.20. CARs #7251 & 7811 both previously highlighted this behavior. Interestingly, they're both marked as fixed/duplicate, even though I don't believe this issue has ever actually been fixed.
comment:16 by , 8 years ago
Replying to mudbox:
CARs #7251 & 7811 both previously highlighted this behavior. Interestingly, they're both marked as fixed/duplicate, even though I don't believe this issue has ever actually been fixed.
The problem reported in this ticket is new as of VirtualBox 5.0.2. Raw partition access was working correctly in 4.x.x and 5.0.0 (regardless of "Use Host I/O Cache") but broke with 5.0.2 and (as you say) is still broken.
What appeared to be the same problem was reported for Windows hosts in #14425 also around the 5.0.2 timeframe. There are a couple reports in that thread pertaining to Mac OS X, however, apparently that bug was specific to Windows host and its fix did not help Mac, so Mac users were instructed to open a separate ticket (this one).
pop-up error