[vbox-dev] [VBoxManage internalcommands createrawvmdk] doesn't handle -mbr option appropriately

[Erik Leunissen]

On 01/14/2014 08:17 PM, Erik Leunissen wrote:
> L.S.
>
> When instructing VBoxManage to boot into a specific partition, using the
> -mbr option with an appropriate mbr file, that appears not to work as
> expected.
>
> My host is a linux system and the raw VM has Windows7. When launching
> the VM I get a black screen that displays the static text "GRUB _" in
> the upper left corner. This indicates that somehow GRUB is accessed
> where it ought be bypassed. Maybe the physical mbr is still used instead
> of the replacement mbr.


I've inspected this behaviour a little further, and found the following:


Using the option -mbr, only the boot code part of the mbr is replaced 
with that of a replacement MBR. In regular cases of MBR's that I know 
of, replacement of the boot code does not affect the partition to which 
the MBR boot code jumps in order to continue execute the system specific 
boot loader in that specific partition (i.o.w. it doesn't affect the 
active partition). That's what the boot flags in the partition table are 
for.

            I need a check here: am I right?

If so, then the following phrase in the docs is misleading (section 
9.9.1.2.):

----
In some configurations it may be necessary to change the MBR code of the 
created image, e.g. to replace the Linux boot loader that is used
on the host by another boot loader. This allows e.g. the guest to boot
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
directly to Windows, while the host boots Linux from the "same" disk.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  For this purpose the -mbr parameter is provided.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It specifies a file name from which to take the MBR code. The partition 
table is not modified at all, so a MBR file from a system with totally 
different partitioning can be used.
----

What's really needed to boot into a specific system partition is to 
overwrite the boot flags in the partition table (of the vmdk-pt file). 
It is exactly that which the -mbr option leaves unaffected.

I would suggest the introduction of another option -bootpartition 
separate from the functionality of the -mbr option to
[VBoxManage internalcommands createrawvmdk]



Note aside: in my previous post, I mention that 4.2.18 is not affected 
by the observed behaviour (see below). I withdraw that; I'm unsure of it 
now.



Regards,

Erik Leunissen.



>
> When manually overwriting the first 512 bytes of the resulting *-pt.vmdk
> file with the contents of the replacement mbr file, the vmdk file does
> do what's expected.
>
> My system:
>
> VirtualBox 4.3.6 r91406
> Host: openSuSE Linux 13.1 (kernel 3.11.6-4-desktop) 64bit
> Guest: Windows7 64bit
>
> (Before using Virtualbox 4.3.6, I was using 4.2.18 on openSuSE 11.4,
> with which I didn't experience this problem.)
>
>
> Note aside:
> The observed behaviour occurred regardless whether GRUB2 or the legacy
> GRUB boot loader was used for the physical host machine. I write this
> because several discussion threads, that can be found on internet,
> mention the same symptom in the converse combination: launching a raw
> linux VM from a Windows host. In these discussion threads, GRUB2 is
> indicated as the culprit.
>
>
>
> Best regards,
>
> Erik Leunissen
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>