The operation on file \\.\PhysicalDrive1 failed

[pderocco]

I'm running VMware Workstation Player 15 on a Win7 host. I'm trying to use an Ubuntu 16.04LTS client to do partitioning, cloning, and other related things on disks. I was able to create a bunch of partitions on a blank SSD, and they're visible both in Windows Disk Management, and under Linux in the /dev tree. When I try to use the dd command to try to copy an existing partition on an old drive over the empty partition on the new drive, which has the same size, I can't write to it at all, because I get popups from the VM with the message mentioned in the title. Neither drive is mounted in Linux. I've tried it with the drives online and offline in Windows, and it makes no difference.

I can do this stuff by just booting direct to Linux (meaning there's nothing wrong with the disks), but I need to go back and forth between Linux and Windows tools, and repeatedly rebooting makes my work really difficult.

So what does this error message mean, what causes it, and what do I do about it?

[scott28tt]

A continuation of this thread? How do I create a VM that boots from an existing physical disk?

[pderocco]

These are both about the same error message, I suppose, but I managed to solve the other thread's problem, which was an inability to boot a VM from a physical disk. I sort of have to stand on my head to do it, going to the grub console and issuing a couple of commands, and I still get a few of the PhysicalDrive1 errors which I just "Continue" until they stop. But now I can get into Linux and do useful work.

But now I'm coming up against a complete inability to do some specific thing in Linux, which is raw writes to unmounted partitions. It wouldn't surprise me in the least if the ultimate cause of this problem is the same as the ultimate cause of my previous problem, but I don't know that for sure. And while my previous problem involved complaints about an inability to write to a few sectors that I never explicitly asked it to write to, and don't know what was trying to write to them, and now find I can ignore anyway, I now have a situation where I can't write anything at all to a partition, when I'm trying to copy an entire image of a partition from one disk to another. So this is a much better-defined problem. How can I copy, say, /dev/sdc1 to /dev/sdb1 with the dd command, if I get this particular VMWare popup on sector 0? Is it Windows that is refusing to let me do this? Is it some Windows admin policy? I'm running as admin. Or is it VMWare? I would think the folks that built this virtualization system would have encountered this, and know what it means and what to do about it.

[scott28tt]

Without knowing exactly what data you’re trying to make available across both OSes, you might find using a regular file share (NFS or SMB) and doing a network file copy is much much easier.

[pderocco]

I'm not copying files, I'm cloning partitions.

[scott28tt]

And there is no other way to get the content of the partition copied across to the new one?

[continuum]

Which physical disk type do you use ?

- partitionedDevice

- fullDevice

If you use the first one this is expected behaviour.

[pderocco]

Yes, there probably is some other way. I could purchase a Windows-based partitioning program, and maybe it would do what I want. I actually own EaseUS, but it has a bug that makes the specific thing I'm trying to do impossible. But for years I've used Linux and the dd command to do simple partition cloning. It's comprehensible, it's reliable, and it's free. And it works fine when I'm running Linux directly on the hardware. But now I'm trying to run it in a VM, and it's not working. I'm hoping someone here knows why it doesn't work, and what I can do to make it work.

[pderocco]

I'm using the full device. Originally, I had a separate computer running Linux, but one day the mobo failed, so I moved the disk into my Windows machine. I can boot directly from that disk, and it works fine, but then I don't have Windows. I originally configured VirtualBox to boot from it, and it worked fine until after some Windows update, I was no longer able to boot it, and no one at their forum seemed able to help. So I decided to try VMWare. It kinda sorta works, except for the need to go through the grub console to boot it, and then its refusal to allow certain direct disk operations. Someone around here ought to know what this is about, and what to do about it. There are lots of threads on Google about similar errors going back years, but no solution for my specific case.

[dariusd]

Can you post (as an attachment) a vmware.log showing the error message?  There may well be clues in the logfile which suggest a possible cause and corrective action.

Thanks,

--

Darius

[continuum]

Also send a screenshot from diskmanagement of your host for drive1

You will have best chances if

- you start Workstation as admin

- you can set the complete drive1 to state "offline" in diskmanagement

[pderocco]

If I put the drive offline, I get tons of these popups, and eventually it fails to boot. If I put the drive online, I get six of these popups, and it boots. If I then go into gparted, I get another six of these popups. I've attached the relevant config files, as well as the log, which shows the process of booting with the drive online in Windows, then going into gparted, then shutting down. And yes, I'm using "Run as administrator".

I've also attached a screencap of the Disk Management window for this disk, which shows four partitions, which are the EFI System, Linux, the swap, and an unrelated NTFS partition that I'm using for some extra temporary storage having nothing to do with Linux (and which I only created a few days ago, so it has nothing to do with this problem).

Thanks to everyone for helping me with this. I hope someone knows how to read that log file.

[continuum]

This smells like trouble ...

Do you plan to ckeck your skills by creating an extra-tricky challenge ?

Looks like this ....

I am in a hurry - I list the issues - and will explain in a later post ...

- EFI-system partition inside "fullDevice" raw-disk gives Windows perfect arguments to deny access to that partition and allow you full control of a disk - preceoved as an "essential" one

- option: copy partition 1 used by EFI into an image-file that allows modifications - needs "partitionedDevice" and additional 512 MB in VM-homedir

-sata port for the rawdisk - use a single SCSI-port attached to a separate SCSI-controller instead

- thinprint - get rid of it - needs serial port with eventually elevated rights

- a present vmpl file ?  - why

- EFI-firmware - if your Linux can boot without EFI it will be easier ....

I expect that a Windows protected partition is inside your fullDevice and that is why you are not allowed to get exclusive access from the VM.

Todo: Do NOT request access to the EFI partition by creating an MBR-block plus EFI-partition block as files inside the VM-dir.

Then use partitionedDevice and allow access for the 2 Linux partitions + plus the MBR-image and the EFI-image ...

Looks possible to me - I doubt you will be able to work around with easier "hacks"

Advantage: Windows does not need to give you access to the EFI-partition.

[dariusd]

Your operating system is refusing to allow the virtual machine to write to a part of the disk:

2020-07-07T22:36:46.388-07:00| vmx| I005: VMXAIOMGR: Retry on write "\\.\PhysicalDrive1" : Access is denied.

2020-07-07T22:36:46.388-07:00| vmx| I005: VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615

2020-07-07T22:36:46.388-07:00| vmx| I005: VMXAIOMGR: "\\.\PhysicalDrive1" : write s=1048576 n=4096 ne=1, fai=0

2020-07-07T22:36:46.388-07:00| vmx| I005: VMXAIOMGR:             v[0]=233C91000:4096

It's noteworthy that the write is to a location very near to the start of the disk.  My guess is that either Windows or an antivirus/antimalware program is prohibiting a write to the EFI System Partition.  If you have any antivirus/antimalware program running, you might need to specifically configure it to permit VMware Workstation to access the raw device and its partitions.  If it's caused by some protection built in to Windows (and it may well be), then your safest option might be to configure the VM so that it does not need write access to the EFI System Partition.  What your VM is doing here is exactly the sort of access that system-level malware might perform if it wanted to bypass Windows' protections and gain a persistent foothold on a system, so it is reasonable for Windows to block it.  (And I am assuming here that you don't actually have some malware running inside your VM trying to write to the EFI System Partition...)

--

Darius

[continuum]

You mean something like this?

....

createType="partitionedDevice"

# Extent description

RW * FLAT "pdisk-pt.vmdk" 0

RW * FLAT "cloned-efi-part.img" *

RW * ZERO

RW * FLAT "\\.\PhysicalDrive1" * >> point to first Linux partition

RW * ZERO

RW * FLAT "\\.\PhysicalDrive1" * >> point to second Linux partition

RW * ZERO

RW * FLAT "\\.\PhysicalDrive1" * >> point to third unmounted NTFS partition

RW * FLAT "pdisk-pt.vmdk"

with appropriate values of course ...

[pderocco]

This is all very interesting, and I'll try it out. But I'm still puzzled. The logs I sent were from bootup, but the specific problem this post was originally about was an inability to clone a drive. At the moment, I don't have a drive to clone, so I can't provide logs of those failures.

So originally, I had successfully booted into Linux (modulo those few popups), and was trying to copy from a physical hard disk to a physical SSD, one partition at a time, after having created a partition table referencing unformatted partitions of the sizes I needed. I did it this way, rather than just copying the entire disk, because the main Windows partition on that disk was to be resized afterwards. None of the partitions were mounted in Linux, and none were mounted in Windows. And I even tried it with the disk offline in Windows. I was being prevented from writing to what had been marked in the partition table as an EFI partition, but had nothing in it but a bunch of zeroes.

I can understand why Windows might prevent certain accesses to the partition that contains the boot loader used to boot the machine, but does it really try to prevent writing to any partition marked as EFI, even if it's just an otherwise blank data disk? That seems like a bad design choice. Maybe I could unmark it as EFI while booted directly into Linux, go back into the VM, clone it, and then change the type back to EFI.

Anyway, this doesn't sound like a VMWare issue, so thanks for all your help. When I get another drive to clone, which may be this weekend, I'll post an update.