Boot record loss on exporting a DragonflyBSD virtual machine in open virtualization format 1.0 file

[JasonBond]

Steps to repeat the problem:

1. Create a DragonflyBSD 5.6.2 virtual machine and select Hammer2 as file system.
2. Export this virtual machine as a open virtualization format 1.0 file, say it named 'dflybsd.ova'.
3. Import 'dflybsd.ova' to another virtualbox host.
4. Start the imported virtual machine in the new host, DragonflyBSD will report boot record loss.

Remark: If I copy all files of the virtual machine to another host, it can run normally. It seems that virtual machine exporting function mess up something for DragonflyBSD Unix.

[Socratis]

Would that be the ISO used to create the VM? ​http://mirror-master.dragonflybsd.org/iso-images/dfly-x86_64-5.6.2_REL.iso? Trying that one until I hear back from you...

If I copy all files of the virtual machine to another host, it can run normally.

Can you explain that statement? Which "all files" are you referring to?

[Socratis]

I was able to reproduce the behavior that you're describing, I'm just not sure who's at fault here. Here's what I think is happening:

1. You're booting the Guest from a hard disk that has a specific UUID/SerNo. The OS uses that UUID/SerNo to boot from. GRUB2 does that as well.

2. When you export the VM, the attached hard disk gets a new UUID/SerNo. If I'm not mistaken that's what the export specification calls for.

3. The Guest now can't boot, because the attached hard disk has a different UUID/SerNo:

   Mounting root from hammer2:serno/VBc8461d9e-3cb7efa7.s1d
   hammer2_mount: root ’serno/VBc8461d9e-3cb7efa7.s1d’
   hammer2_mount: dev="serno/VBc8461d9e-3cb7efa7.s1d” label="ROOT” rdonly=1
   no disk named ’ serno/VBc8461d9e-3cb7efa7.s1d’
   hammer2: cannot find ’serno/VBc8461d9e-3cb7efa7.s1d’
   Root mount failed: 6
   
   Manual root filesystem specification:
     <fstype>:<device>  Specify root (e.g. ufs:da0s1a)
     ?                  List valid disk boot devices
     panic              Just panic
     abort              Abort manual input
   
   mountroot>
   

I'm pretty sure that if DragonFlyBSD was set to boot from the primary hard disk, instead of a specific hard disk, there would be no problem at all. I simply don't know enough about DragonFlyBSD to tell it to do so. Can you? Can the DragonFlyBSD people help and show us the way?

[Klaus Espenlaub]

OVA export/import simply doesn't preserve the hard disk serial number (which is derived from the base disk image UUID by default). It can be overridden, see https://www.virtualbox.org/manual/ch09.html#changevpd

However, any OS which bolts itself to the serial number of a hard disk is going to blow up after transplanting onto a new disk, i.e. this annoying behavior will show up even on real hardware if one would replace a dying hard disk with a new one, copying over all content.

[Socratis]

Using the example from comment 2, I issued the command:

VBoxManage setextradata "DragonFly BSD" "VBoxInternal/Devices/piix3ide/0/Config/PrimaryMaster/SerialNumber" "VBc8461d9e-3cb7efa7"

That allowed the VM to boot successfully.

Closing the ticket as [Invalid]. Just as 'klaus' mentioned, this is a buggy implementation of the DragonFlyBSD bootloader that ties the serial number to the boot device.

[JasonBond]

Thanks all of you to figure out the issue and provide the solution. Thanks again. I will report this problem to Dragonfly BSD development team, hope them could fix it later.