Error when writing first partition on raw access hd
Posted: 22. Mar 2016, 02:28
Fist, I'm glad to use this nice product by Oracle.
This is a report on raw disk access by virtualbox under linux guest (arch linux)/windows host (win10-64bit). My setup is an external usb disk with two linux partition (gpt), the first is formatted fat (boostrap), the second is xfs, the root partition. The problem arises when modifying the first partition, like when updating the kernel on arch, this manifests as if virtualbox is denying access to write on the first partition somehow, giving hard disk errors, note this is not ownership or write permission problem.
I have noticed this error only occurs when using the virtual SATA controller to access the raw hard disk. If I use the virtual IDE controller, the problem does not occur and the write accesses works as intended. It works fine when using the competing VMWare player to access the same disk too. Also works fine when using the same usb hd disk on naked hardware without a virtual machine.
This is not specific to a particular vbox version, I'm using 5.0.16 r105871, but noticed this behavior on previous version also.
Again, thanks very much.
This is a report on raw disk access by virtualbox under linux guest (arch linux)/windows host (win10-64bit). My setup is an external usb disk with two linux partition (gpt), the first is formatted fat (boostrap), the second is xfs, the root partition. The problem arises when modifying the first partition, like when updating the kernel on arch, this manifests as if virtualbox is denying access to write on the first partition somehow, giving hard disk errors, note this is not ownership or write permission problem.
I have noticed this error only occurs when using the virtual SATA controller to access the raw hard disk. If I use the virtual IDE controller, the problem does not occur and the write accesses works as intended. It works fine when using the competing VMWare player to access the same disk too. Also works fine when using the same usb hd disk on naked hardware without a virtual machine.
This is not specific to a particular vbox version, I'm using 5.0.16 r105871, but noticed this behavior on previous version also.
Again, thanks very much.