Well, I'd say you'd better export your VM (to the .ova
container) before wiping off the host system and then import it later — VirtualBox can do that from its GUI.
But OK, back to your question... I recall that VirtualBox has separate "registry" for all the media your VMs use. IIRC, it's stored in an XML file somewhere under the current user's profile.
So, I'd start from opening that media-management window from the VBox GUI and made sure the Debian's disk actually exists and is known to the VBox media manager.
The next thing to check after that would be going to the VM's properties and making sure that media representing the VM's hard disk is available and has "OK" status.
If booting the VM after that fails, please do this: when presented with the GRUB (the Debian's boot loader) window during the early boot (post-BIOS), press e
(or whatever it suggests — I never remember it) to edit the boot entry for your system — you'll be presented with the command-line passed by the boot loader to the kernel, and it contains the parameter named "root" (meaninig the root filesystem). These days, the argument to root contains some UUID-encoded device name, and so the whole thing looks something like
/boot/vmlinuz-3.2.0-4-amd64 root=UUID=2cb5a97c-75ab-4c8b-afd9-19297e3553bd ro single
You should replace that UUID=blah...
part with /dev/sda1
to make it read something like
/boot/vmlinuz-3.2.0-4-amd64 root=/dev/sda1 ro single
and it will most probably boot just OK.
(Notice that the path to the kernel file, /boot/vmlinuz-3.2.0-4-amd64
is from mine system; on yours it might be different — don't mess with it, you should only touch the root=
parameter).
Note that /dev/sda1
means the first primary partition on the first (SATA/SCSI) hard disk. If you have your root partition somewhere else, you has to figure this out. If you have no idea what's this all about, try 2
, 3
etc until it works.
Once the system boots, run
# dpkg-reconfigure grub-pc
to reconfigure GRUB so it uses the correct device name for the root filesystem.
You might also need to fix the /etc/fstab
file if the device's UUID has indeed changed. To do this, run
# blkid /dev/sda1
and replace the value of UUID in the appropriate fstab's entry by the one reported by blkid
in the UUID
value.
The number in that /dev/sdN
should obviously match what worked for you as the root=
parameter of the kernel.