"FATAL: No bootable medium found! System halted." after modifyhd --resize command

[mpack]

I did also mention CloneVDI, which can run happily on a Mac if one of the Wine packages are installed (WineBottler used to be common, I think it's something else now).

[socratis]

Yeap, you're right. I missed it, since it wasn't in the "to consider" section...

[mpack]

Ok, I think I see what happened now.

A VDI is arranged <header><blockmap><image blocks>. In a modern VDI all three are aligned on 1MB boundaries. In the past 4K alignment was used. In the very distant past 512bytes was used. The OPs VDI used 4K alignment.

When I inspect this VDI header in a debugger, I find that the block map begins on a 4K boundary, but the image begins on a 1MB boundary. It's the first time I've seen this mix of alignments in a VDI - a new feature? This image alignment is not coincidental: each 4K segment of the block map is enough to store the offset of 1024 blocks, i.e. you need 4K of block map for each 1GB of logical disk size. So, a 60GB VDI should have required a block map of 240K, not 1MB. The block map should have been aligned on 4K (it is), then the image should have started at 244K (it doesn't).

I've never liked that VBoxManage does in place edits of the VDI structure, instead of the inherently safer option used by CloneVDI of cloning, and modifying the clone only. One of the downsides of in-place edits is that you must support all past variants of the data structure, which complicates the code: and you don't want code this dangerous to be complex, you want it to be as simple and clear as possible.

My first guess was that they tried to modernise the VDI by changing the image alignment (evidence: the block map says that block0, which should contain the boot sector, has been moved to the end of the VDI file). However I don't know how you could do that without moving every single block in the file: but that's major surgery, it would be insanely dangerous. So now I'm thinking straight up bug: code was called which assumes a 1MB alignment.

Either way, this needs to be reported to BugTracker.

I also don't know of any way to recover this VDI: I suspect the blocks have been shuffled. You will probably need to revert to your backup. I would suggest that you also consider switching to CloneVDI for all future disk resizing - it's a far safer option.

[socratis]

Either way, this needs to be reported to BugTracker.

I don't know the level of in-depth knowledge that the OP has, but maybe you should be doing the honors? I honestly cannot think of a more qualified person to file such a bug, especially given the explanation of the bug.

This is what I call a critical bug (loss of data) and I wouldn't trust it to anyone else.

[mpack]

Ok, I'll raise the ticket, but I'll also say that I have not personally verified the problem. I've seen a VDI with a header field I can't explain, but I have no idea how it got that way. For all I know the OP wrote his own CloneVDI fork!

It would help if the OP had any details of the VDI prior to the enlargement step: i.e. what size it was, exactly. It would be good to provide the exact steps needed to replicate.

[socratis]

My understanding so far is that a backup exists, prior to the enlargement (three weeks old).

@Brian Kush
Isn't that right? You mentioned a backup, no? If you could make it available (whole or a portion, I don't know what mpack needs/wants to reproduce the bug), it would be great, no?

[mpack]

Incidentally, we still don't know that the error was in VirtualBox. It might have been bug free code that hit a host hdd glitch of some kind.

[mpack]

Ok, see ticket 16099.

[socratis]

Nice! Thanks Don...

[Martin]

Is this similar to viewtopic.php?f=6&t=79282 ?

[mpack]

It could be, but only if my observations about the internal alignments are irrelevant to the actual bug. In that previous example both the blockmap and the image ended up on 1MB alignments - perfectly normal for a new VDI - rather than the mix of alignments seen in the OPs case.

[mpack]

I see that the 5.1.10 version that was released today contains a fix for what is probably this bug. Unfortunately the fix can only prevent future reoccurrence, it can't repair corruption that already happened. And the moral is: make backups before doing something as drastic as an in-place edit to your only copy of data you care about.

[WFV]

Isn't the command "modifymedium"? or does that only apply to Linux Host? I couldn't find "modifyhd" in VBoxManage --help. I ran

Code: Select all

$ VBoxManage modifymedium /path/to/VirtualBox\ VMs/Win7/Windows7.vdi --resize 86016

to grow a 64GB Windows 7 Pro 64bit guest +20GB without issue. Launched the Win7 guest, and opened diskmgmt.msc and ran "Extend Volume" on the C partition to expand it into the 20GB empty space and then rebooted the guest. The vdi is fixed, not dynamic and is now 84GB, was 64GB, everything is working so far. I do notice in the Linux host in terminal in the Win7 directory

Code: Select all

$ du
612K	./Logs
4.0K	./Snapshots
62G	.

still shows the vdi file as 64GB but VirtualBox gui and Windows both definitely show it as 84GB and there appears to be >20GB free space in C.
Running VBox 5.1.10.

[socratis]

Isn't the command "modifymedium"? or does that only apply to Linux Host?

No, it's the same. "modifymedium" supports the older version of "modifyhd". One great thing in the PDF version of the manual is that it is searchable...

I do notice in the Linux host in terminal in the Win7 directory still shows the vdi file as 64GB but VirtualBox gui and Windows both definitely show it as 84GB

Yes, because the 20GB was just allocated in the partition table and have not actually been used yet which would require an allocation on the actual VDI. I would suggest to read a bit about the dynamic disk format and how it's allocation is happening. From the manual:

VirtualBox supports two types of image files:

• A dynamically allocated file will only grow in size when the guest actually stores data on its virtual hard disk. It will therefore initially be small on the host hard drive and only later grow to the size specified as it is filled with data.
• A fixed-size file will immediately occupy the file specified, even if only a fraction of the virtual hard disk space is actually in use. While occupying much more space, a fixed-size file incurs less overhead and is therefore slightly faster than a dynamically allocated file.

[mpack]

Where in the manual did that quote come from, Socratis? The statement about fixed size disks is wrong - they do not reduce overhead even slightly, and I thought we had purged all such misleading statements from the manual.