vboxmanage fails for gpt disks (windows)

[jburke]

I have drives of msdosmbr and gpt styled partition tables. The following fails for only gpt tables, but passes for any msdos styled table i have.

What i'm attempting to list partitions of a rawdisk image..

VBoxManage internalcommands listpartitions -rawdisk
.\PhysicalDrive0

passes and so do the rest of my msdosmbr partition styled drives..

However when i use
.\PhysicalDrive3 (which is currently a gpt drive), there's a long printout of something as the following..

" VBoxManage.exe: error: Two partitions start at the same place Number Type StartCHS EndCHS Size (MiB) Start (Sect) 1 0x00 0 /0 /0 0 /0 /0 9 2032808 2 0x00 0 /0 /0 0 /0 /0 9 2032808 3 0x00 0 /0 /0 0 /0 /0 9 2032808 4 0x00 0 /0 /0 0 /0 /0 9 2032808 5 0x00 0 /0 /0 0 /0 /0 9 2032808 6 0x00 0 /0 /0 0 /0 /0 9 2032808 7 0x00 0 /0 /0 0 /0 /0 9 2032808 8 0x00 0 /0 /0 0 /0 /0 9 2032808 9 0x00 0 /0 /0 0 /0 /0 9 2032808 "

^{I guess if this fails, then I shouldn't try to attempt to make a rawdisk .vmdk rule file for it..}

(System is Win7x64) (Virtualbox ver 4.2.0 r80737)

[dterrahe]

I am succeeding, under Win8 x64 with Virtualbox 4.2.12 (and previous versions), to create a rawdisk for the whole drive which is formatted using GPT, but when I try to access individual partitions, using either "listpartitions" or "-partitions x,y,z -mbr mbrfile", vboxmanage crashes. Windows shows the following problem details:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	VBoxManage.exe
  Application Version:	0.0.0.0
  Application Timestamp:	5167d6bb
  Fault Module Name:	VBoxManage.exe
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	5167d6bb
  Exception Code:	c0000005
  Exception Offset:	00000000000076e4
  OS Version:	6.2.9200.2.0.0.768.101
  Locale ID:	2057
  Additional Information 1:	f943
  Additional Information 2:	f9435c023c48b305040d12a9eb51efa4
  Additional Information 3:	77b0
  Additional Information 4:	77b00af845d8e090c3c69181aafa27c9

Maybe the problem is in the partitioning scheme, since the partition numbers are not consecutive. Under linux, parted shows this:

Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 500118192s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start       End         Size        File system     Name                          Flags
 1      2048s       1026047s    1024000s    fat32           EFI system partition          boot
 2      1026048s    1107967s    81920s      fat32           Basic data partition
 3      1107968s    1370111s    262144s                     Microsoft reserved partition  msftres
 4      1370112s    2394111s    1024000s    ntfs            Microsoft recovery partition  hidden, diag
 7      2394112s    251224063s  248829952s  ntfs            Basic data partition
 5      251224064s  475246591s  224022528s  ext4            Debian
 6      475246592s  500117503s  24870912s   linux-swap(v1)

It is important for me to be able to use a custom mbr, because virtualbox does not store uefi settings and therefore would by default always boot windows from that drive.

[Александр]

A similar error https://www.virtualbox.org/ticket/12983

[Jessica Hamilton]

I am also experiencing this problem with GPT formatted disks. Creating a VMDK for the whole disk works without issue, but specifying a partition causes it to crash. Note that I'm not running a hybrid GPT/MBR scheme on my Windows 8.1 install either. Happening for me with version 4.3.12.

[Mihai Hanor]

VBoxManage fails because partRead() doesn't check if every RTFileReadAt() call succeeds. And ReadFile() fails with ERROR_INVALID_PARAMETER, because the requested number of bytes must be multiple of sector size. I'm attaching a patch, MIT licensed, if you can use it. I've already tested it, it seems to work fine.

[Mihai Hanor]

a small modification to the original patch

[Mihai Hanor]

another modification, it replaces the original patch

[Doener87]

It would be nice to have this fixed, currently its not possible to use rawdisk with Windows 7/8 (64 bit) because the they can only be installed on GPT disks.

[Francesco Pretto]

I am also in need of this to be fixed.

[Francesco Pretto]

mhanor attached patch worked for me. I was also able to boot a native EFI ubuntu installation, creating first a legacy mbr installed (arbitrarily) on the root partition boot sector and using it to create a rawdisk with VBoxManage.

# NOTE: /dev/sdb3 is the root of the ubuntu installation
$ sudo apt-get install grub-pc-bin
$ sudo grub-install --target="i386-pc" --force /dev/sdb3
$ dd if=/dev/sdb3 of=~/virtualbox-native.mbr bs=512 count=1

I finally created the vmdk with:

VBoxManage internalcommands createrawvmdk -filename C:\Temp\ubuntu.vmdk -rawdisk \\.\PhysicalDrive1 -partitions 1,2,3 -mbr C:\Temp\virtualbox-native.mbr

The interesting thing is I didn't have to make the rawdisk be able access to the EFI system partition and the VM guest doesn't need to be EFI enabled at all. The native system still continue to boot in EFI way.

I hope to see the bug in VBoxManage fixed soon.

[jdevora]

I'm been hit by that bug as well

[f3flight]

+1, trying to access a partition on GPT disk, Host OS is Windows 8.1 x32. listpartitions returns nothing. Can you please incorporate the patch into the VirtualBox release? I'm not sure how to apply it myself.

[Davidu]

+1, I'm experiencing same issue with the latest Virtual Box (4.3.26 and 5.0.beta2) on Windows 8.1 (x64) with GPT only formatted disk:

vboxmanage internalcommands listpartitions -rawdisk \\.\PhysicalDrive0

vboxmanage internalcommands listpartitions -rawdisk \\.\GLOBALROOT\ArcName\multi(0)disk(0)rdisk(0)

vboxmanage internalcommands createrawvmdk -filename acerLucji.vmdk -rawdisk \\.\PhysicalDrive0 -partitions 6

vboxmanage internalcommands createrawvmdk -filename acerLucji.vmdk -rawdisk \\.\GLOBALROOT\ArcName\multi(0)disk(0)rdisk(0) -partitions 6

Any of the above commands causes vboxmanage APPCRASH and no results or error messages are displayed in the command line.

Is there a chance to include vboxmanage_gpt.patch, added by mhanor 12 months ago, to the upcoming Virtual Box 5.0 or the next 4.3.x bugfix release?

[Klaus Espenlaub]

Should be fixed in 5.0.0_BETA4 (not using the patch which apparently wasn't only hard for me to understand what it really does, but with a hopefully working, independent change). If I don't forget I will dig out the changeset with the fix once it has reached the public source repo.

[Mihai Hanor]

It's fixed in Beta4 :)