"FATAL: No bootable medium found! System halted." after modifyhd --resize command
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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).
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
Yeap, you're right. I missed it, since it wasn't in the "to consider" section...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.
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.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.mpack wrote:Either way, this needs to be reported to BugTracker.
This is what I call a critical bug (loss of data) and I wouldn't trust it to anyone else.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.
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.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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?
@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?
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
Nice! Thanks Don...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.
-
- Posts: 83
- Joined: 7. Mar 2016, 13:28
- Primary OS: Linux other
- VBox Version: OSE other
- Guest OSses: ArchLinux; Fedora; Ubuntu; Win7pro64; WinXP
- Contact:
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
Isn't the command "modifymedium"? or does that only apply to Linux Host? I couldn't find "modifyhd" in VBoxManage --help. I ran 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 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.
Code: Select all
$ VBoxManage modifymedium /path/to/VirtualBox\ VMs/Win7/Windows7.vdi --resize 86016
Code: Select all
$ du
612K ./Logs
4.0K ./Snapshots
62G .
Running VBox 5.1.10.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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...WFV wrote:Isn't the command "modifymedium"? or does that only apply to Linux Host?
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:WFV wrote: 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
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.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: "FATAL: No bootable medium found! System halted." after modifyhd --resize command
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.