Out of memory allocating the partition descriptor

[tytus]

I am using Ubuntu 8.10. I would like to use my existing window partition with vbox so after installing version 2.1.2 I executed the following command:

Code: Select all

$ VBoxManage internalcommands createrawvmdk -filename /home/promanus/vmware/WinXPpartition -rawdisk /dev/sda -partitions 1 -relative
VirtualBox Command Line Management Interface Version 2.1.2
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Out of memory allocating the partition descriptor for '/dev/sda'
The raw disk vmdk file was not created

Does anybody know why am I getting this error?

Any help greatly appreciated.

[TerryE]

Does anybody know why am I getting this error?

Yes, according to svn - VBoxInternalManage.cpp, the relevant code is:

Code: Select all

RawDescriptor.pPartitions[i].uPartitionDataStart = partitions.aPartitions[i].uPartDataStart * 512;
RawDescriptor.pPartitions[i].cbPartitionData = partitions.aPartitions[i].cPartDataSectors * 512;
if (RawDescriptor.pPartitions[i].cbPartitionData)
{
    Assert (RawDescriptor.pPartitions[i].cbPartitionData -
            (size_t)RawDescriptor.pPartitions[i].cbPartitionData == 0);
    void *pPartData = RTMemAlloc((size_t)RawDescriptor.pPartitions[i].cbPartitionData);
    if (!pPartData)
    {
        RTPrintf("Out of memory allocating the partition descriptor for '%s'\n", rawdisk.raw());
        vrc = VERR_NO_MEMORY;
        goto out;
    }
    vrc = RTFileReadAt(RawFile, partitions.aPartitions[i].uPartDataStart * 512, pPartData, 
            (size_t)RawDescriptor.pPartitions[i].cbPartitionData, NULL);

and I am lost as to why the routine would want to attempt to allocate memory for the entire partition. Needless to say it barfs at this. Could you post your VBoxManage internalcommands listpartitions?

[tytus]

Code: Select all

# VBoxManage internalcommands listpartitions -rawdisk /dev/sda
VirtualBox Command Line Management Interface Version 2.1.2
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x07  0   /1  /1   1023/254/63         20975           63
6       0x83  1023/254/63  1023/254/63         72488     42957936
5       0x82  1023/254/63  1023/254/63          1929    191414538

The first partition is my Windows partition.

I also forgot to mentioned that I have vmware running on this box - all vmware modules loaded and daemons running (not sure if this has any significance). vmware though does not have any Virtual Machine configured that would using the Windows partition though.

My box has 2G of RAM and and 1G of swap. Are you suggesting that this code tries to allocate 20G?!!

Let me know if there is need for any more info.

[TerryE]

You can have VMware and VBox installed on the same OS as long as you don't try to start both at the same time.

[Jirka]

Hi,
I am getting same problem. Is there any solution? I have no vmware installed. My partition table:

Code: Select all

VirtualBox Command Line Management Interface Version 2.1.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x27  0   /32 /33  1023/254/63         10240         2048
2       0x07  1023/254/63  1023/254/63        147501     20973568
6       0x83  1023/254/63  1023/254/63        143047    323067276
5       0x82  1023/254/63  1023/254/63          4447    616028490

My command to create image:

Code: Select all

jirka@jirka-laptop:~$ sudo VBoxManage internalcommands createrawvmdk -filename /home/jirka/.VirtualBox/HardDisks/vista.mdk -rawdisk /dev/sda -partitions 2 -relative -register
VirtualBox Command Line Management Interface Version 2.1.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Out of memory allocating the partition descriptor for '/dev/sda'
The raw disk vmdk file was not created

[tytus]

I have not found any solution to this problem.

[TerryE]

The issue is to do with mapping extended partitions. See ticket #3510.

[TerryE]

I now understand this bug. The DOS partition table comprises 4 primary partition records (PPR) in the first sector of the disk, the so-called MBR. These define 4 physical partitions(PP). If one of these is flagged as an extended partition, there is a linked list of extended partition records (EPR) threaded through the extended partition. Usually (but not always) the actual logical partition (LP) data immediately (actually track aligned) follows its EPR. Hence if the third partition is an extended one, you might have the scenario:

• MBR: PPR1, PPR2, PPR3, PPR4, PP1 ,PP2, PP3 (Extended partition), PP4
  Extended Partition: EPR5, LP5, EPR6, LP6, ...

However this is a typical case and not mandatory. Where this can "go wrong" is if you delete LP5, then the old LP6 now becomes LP5

• Extended Partition: EPR5, <big gap>LP5 (was called LP6), ...

and insert a new partition:

• Extended Partition: EPR5, EPR6, LP6, LP5, ...

and this is the case in these two examples: LP5 follows LP6. Unfortunately this createrawvmdk routine assumes that the EPR and LP are consecutive and reads this dead space into memory. I don't know but I suspect this is because some encryption and protection schemes hide key data in these nominally unused sectors. Anyway, the utility can happily allocate a 63 sector block, but a 70Gb one is a slightly different matter.

Until the VBox developers fix this bug, the work around is to use the Linux fdisk advanced feature of renumbering the partitions which recreates the EPR records in LP order.

[tytus]

I am not sure if the above description enough for all cases. My partitioning scheme does not seem to have the problem you were describing but I still get the error. Here is my partition table:

Code: Select all

# fdisk /dev/sda

The number of cylinders for this disk is set to 12161.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p  

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x41ab2316

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2674    21478873+   7  HPFS/NTFS
/dev/sda3            2675       12161    76204327+   5  Extended
/dev/sda5            2675       11915    74228269+  83  Linux
/dev/sda6           11916       12161     1975963+  82  Linux swap / Solaris

[TerryE]

Your VBoxManage internalcommands listpartitions above shows:

Code: Select all

6       0x83  1023/254/63  1023/254/63         72488     42957936
5       0x82  1023/254/63  1023/254/63          1929    191414538

yet your fdisk -l shows

Code: Select all

/dev/sda5            2675       11915    74228269+  83  Linux
/dev/sda6           11916       12161     1975963+  82  Linux swap / Solaris

(note the swap in 5 and 6) which implies that either the kernel partition discovery resorts logical partitions in to ascending disk order for numbering or you have done an fdisk / x / f in the meantime. What does the fdisk / x / p (the expert partition print) show? The current algo tries to malloc space for the sectors in the "Start" column in the case of Logical Partitions.

[tytus]

Yes. You are right. I did fdisk /x /f. Here is my fdisk /x / p:

Code: Select all

# fdisk /dev/sda

The number of cylinders for this disk is set to 12161.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): x

Expert command (m for help): p

Disk /dev/sda: 255 heads, 63 sectors, 12161 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   1   1    0 254  63 1023         63   42957747 07
 2 00   0   0    0   0   0    0          0          0 00
 3 00 254  63 1023 254  63 1023   42957810  152408655 05
 4 00   0   0    0   0   0    0          0          0 00
 5 00 254  63 1023 254  63 1023        126  148456539 83
 6 00 254  63 1023 254  63 1023  148456727    3951927 82

[tytus]

In addition:

Code: Select all

# VBoxManage internalcommands listpartitions -rawdisk /dev/sda
VirtualBox Command Line Management Interface Version 2.1.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x07  0   /1  /1   1023/254/63         20975           63
5       0x83  1023/254/63  1023/254/63         72488     42957936
6       0x82  1023/254/63  1023/254/63          1929    191414538

[TerryE]

What you have here is a case of:

• Extended Partition: EPR5, EPR6, LP5, LP6, ...

which is just a shuffle of my earlier case, but its that start offset of 148456727 sectors -- unless of course you are running a 64bit OS and happen to have a spare 70Gb of allocatable memory

[tytus]

Unfortunately this createrawvmdk routine assumes that the EPR and LP are consecutive and reads this dead space into memory.

I have to admit that I am not 100% sure I understand your explanation Are you saying that I can not have LP following another LP? If this is the case, is there any chance to fix my partitioning scheme?

[TerryE]

No, I am saying that normally you have EPR5, LP5, EPR6, LP6, ... rather than EPR5, EPR6, LP5, LP6, ... The latter isn't actually illegal, but rather an unusual case that the VBoxManage command doesn't allow for.