virtualbox.org

Hi,

I was trying to expand a disk to a larger size and used the command

vboxmanage modifyhd "diskname" --resize 60000000

completely miss typed the size (yes stupid). however, now My MacBook Air thinks I have a 5.2 TB drive, which clearly does not exist. Is there anyway to restore, tell the system to undo the command, shrink the drive? Is there anything I can do to recover. Please help, this is a VERY critical machine contains lots of information for which I (my wife) has no backup.

Any help appreciated.

Mark

You can not shrink the drive. If the guest still boots you can rest easy. The container will be huge but the partition is what you need to be concerned with. If you have only done the resizing you still need to increase the primary partition. Just be careful to *NOT extend it more than you have available on the drive. You can even extend the primary partition to the size you wanted to begin with. Just be careful.

Note: When doing something as drastic that could be devastating should you make a mistake, you should always make a backup first.

This is the 'Guest' the primary boot. I issues the resize command, they tried to start the machine and then it failed with a disk error on the OS startup.

We need to know exact error messages please. If the error messages are not in English, then please give the exact error message, followed by your best attempt at a translation.

Basically, I need to know whether VirtualBox is refusing to use the disk, or you are getting an error from the guest OS: the latter is what your last message implies, however it only makes sense to me if it's the former.

The error message I receive when trying to boot the machine is
"A disk read error occurred
Press Ctrl+Alt+Del to restart"

I have installed a new Guest OS, added the 'issue disk' as an additional drive and the guest OS does sees the disk (Device Manager) but does not mount as a drive. Don't want to corrupt further so left it at that.

Thank you for suggestions.

Mark

Attached/Below is the view from Windows if I mount this as a second drive.

Well, this is puzzling. It was my understanding - though I've never needed to test it - that VirtualBox does not support VDI images with a virtual size larger than 2TB. I would've expected VirtualBox to refuse to mount such a drive - with a matching error message, which is what I expected you to report. I would not expect the drive to be accepted, only with "drive failure" (BIOS incompatibility) on boot.

On the other hand, now that you have a second VM and the drive contents are visible the solution is quite simple though it requires lots of time and disk space. Just create a third (empty) drive of the size you originally wanted, attach it to the same VM, and use CloneZilla or other disk imaging software to copy the MBR + first partition from the "issue drive" to the third drive. This should work provided the "issue drive" partition map has not been messed with. If CloneZilla is on a live CD then you don't actually need the first hdd in this VM (which may be important, since supporting a third hdd can sometimes cause problems if using IDE).

The good news is that, even if you can't get the vm to boot, the fact that you can mount it as a second drive should mean that you can recover all of the data that is stored on it.

C: and D: are NOT the bad disk, they are the new disks I created. The other partitions (no disk labels) are the partitions from the 'bad' disk, so are you saying in this form I will be able to use clonezilla to rebuild?

I don't see a drive D. I do see a drive E (40.03GB), which I took to be the boot partition of the "issue drive" - otherwise I don't know why this partition needed to be present in a new VM created expressly for the purpose of mounting your "issue drive". I don't know what the empty partitions are all about - nothing mentioned so far should have created extra partitions.

Sorry, I made a mistake on the disk label.

C: (disk 0) is the is the newly created guest OS
E: (disk 2) is a second data disk (no issues with this disk)
disk 1 ~ is the problem disk, all it's partitions just show up as large partitions un-formatted and not mapped to the OS

I have tried mounting and copying using clonezilla and it just sees one large 6TB disk.

thx,
Mark

Well, it's clear that even if VirtualBox is allowing you to mount the drive, in fact the drive doesn't really work. Btw, here's hoping you made a backup copy of this drive, since mounting it in a VM may have done further damage.

Ok, if we abandon your excursion into "second VM" territory, then the only solutions I know of - arising out of past mistakes of the same sort - involve using a hex editor to patch the file header.

As in here:
viewtopic.php?f=1&t=47354

and here:
viewtopic.php?f=6&t=46711

mpack, thank you for your help so far. I have tried Frhed and modified the hex locations as noted (my original disk was 20GB also). However, I am now getting this error from the guest os "disk structure is corrupted and unreadable", on booting the guest os it enters a checkdisk and to quickly exits for me to read what happens, but once loaded I can see the disk as a drive (F:) but when I try to look at the contents I get the "disk structure is corrupted and unreadable" error message.

Any suggestions on how I can get at the files? I've attached the first 10K bytes dumped using frhed.exe (I've uploaded it as file ext .txt, seemed like no other file types were accepted).

Any help appreciated, Best,

Mark

I hope you made a backup of the VDI before you started hacking it?

If the disk was originally 20GB then you don't want to patch it back to 20GB - if your numbers are slightly out then you could snip the end off the drive data. I would suggest 60GB, in which case edit as before, except use the digit 'F' everywhere you previously used '5'. Otherwise you seem to have patched the header correctly.

If it doesn't work as a patched 60GB drive then I'm afraid that's game over.

not good. Tried that and I get the same error.

will any disk utilities be able to rebuild this in any way. This has royally messed up my wife, need anyway to somehow recover the data.

Mark