No virtual system boot with grub2 on mbr for raw disk access to specific partitions

[Leo Pilachowski]

Recent Linux systems, such as Fedora 16, use the newer grub2 boot loader. The usual grub2 setup places the boot code on the mbr and on the unpartitioned sectors immediately follow the mbr partition. If a virtual guest Linux system is made using raw parition access to Linux code on a partition(s) separate from the host system partition(s), the grub2 boot code is not accessible unless the whole disk is attached rather than just the partitions containing the guest system.

For example, with a Windows 7 64bit host on partition 3 of disk 0 and Fedora 16 on partitions 5 and 6, and with grub2 installed on the mbr of disk0, VirtualBox will not boot a Fedora 16 x86_64 guest unless the vmdk is created with whole disk access to disk0. If the vmdk is created with access to only partitions 5 and 6, Fedora does not boot and hangs after the boot code in the mbr is executed. The code in the sectors following the mbr sector is not reached. Given that it is dangerous for the virtual system to have direct access to the host operating system code, the grub2 boot code should be accessible when only individual partitions are attached. For Windows hosts, the -relative option is not available for createrawvmdk so this option cannot be tested as a solution with Windows hosts.

[Klaus Espenlaub]

Raw partition support copies the partitioning areas (and this includes usually the first 63 sectors) to the partial image associated with such a VMDK file.

Sounds to me like grub2 needs more than this, and this means it isn't copied completely. Can anyone confirm this from a raw partition VMDK image created as described above?

Honestly I thought grub2 was cleaner than the original grub - but if it's hijacking "unused" disk areas I have to revise this opinion...

[Matir]

(Yes, this is old, but comes up in many searches, hopefully this will help others.)

If your first partition starts after partition 63, Grub2 will "feel free" to use all the space up to that first partition for its core.img, even though it's not mapped to real storage by VirtualBox. In my case, I had my partition 1MB aligned, so needed to map 2048 sectors for Grub to use. To do this, I had to expand the -pt.vmdk file created by VirtualBox and edit the main .vmdk mappings.

Details of what I did posted here: ​Fixing the Grub2 Bootloader in VirtualBox Using Raw Partitions. Basically need some work with dd and editing the .vmdk. It's a shame there's no flag (that I could find) to VBoxManage to make it use >63 sectors at the beginning. (Maybe it could look at the partition table and give that many sectors?)