viboot - is there a workaround to successfully virtually boot os partition without other partitions


Author
Message
smithcferg
smithcferg
New Member
New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)
Group: Forum Members
Posts: 4, Visits: 9
First, I like Macrium Reflect a lot, and  I am grateful for it.  

I am rebuilding a win10 computer system, and have the os and some programs installed.  Just before the rebuild, I  made a reflect backup of the main parttition​​, which has the os. on it.   A while ago I made a macrium full disk backup of this whole computer.  Both backups had the same partition scheme, and os, and os partition was the same.    

​​I have read that normally I can't use viboot to get just the system partition booted, but that the partitions that are part of the boot sequence need to be part of the image file.  Is there a way to use the boot/reserved partition information from older backup with the newer partition backup to get a working vm?  Or some other workaround?  ​​I want to load a virtualized machine to extract some data that can't just be copied from a mounted macrium backup image. 

I know I could backup what I have done so far, then recover older full disk backup over my rebuild-in-progress, then recover the newer main partition backup onto the older main partition, then extract the data to an external hard drive, then recover the backup of my new partially built system, but this does sound like an onerous chore.  Booting the partition sounds a whole lot sweeter if I can so it, if there were some way to do it. 

​​The new rebuild-in-progress does have different partition structure before the older full system backup, because I got rid of the recovery partition.  

Thanks again for your ​service to PC using community!

Take care,

Craig​​​​

PS ​​If it hasn't been added as a feature request yet, it would be awesome if Macrium Viboot could facilitate booting a system partition image


smithcferg
smithcferg
New Member
New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)
Group: Forum Members
Posts: 4, Visits: 9
I forgot to mention this is a UEFI boot structure, Win10Pro, Macrium 6 used for backup and using 7 for recovery
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)
Group: Forum Members
Posts: 3.8K, Visits: 28K
I've read your post very slowly 5 times now, and I still don't quite understand what partitions you have in each of your backups, what end result you're trying to achieve here, or why you need to pull partitions out of multiple backups rather than being able to just use either one of these backups as-is to get a bootable VM.  For any image that includes all of the partitions necessary to boot Windows, viBoot absolutely does support just selecting that image and clicking "Boot", and then up it comes.  If one or both of your images don't include all of those necessary partitions, I'm not even sure which one is incomplete at this point.  Early in your first post you said that the older image includes the "main partition", which I assume is your OS partition, but then later you said you wanted to use the boot/reserved partition from the "older backup" with the "newer partition backup".  The boot and reserved partitions in a UEFI system are separate from the "main partition", hence my confusion as to what the older image actually contains.  In order for a hard drive to boot in a UEFI environment, it must contain at least an EFI, MSR, and OS partition, and it usually also includes a Windows Recovery partition, though that isn't always absolutely required. However, there isn't much sense in deleting it because it's small anyway and it will be recreated with every Windows 10 upgrade, and those will be arriving every 6 months from now on. So with respect to your P.S. feature request that "it would be awesome if Macrium Viboot could facilitate booting a system partition image", it already does support that as long as the image contains all required partitions.  And if the image doesn't contain all required partitions, then not being able to boot it isn't viBoot's fault, because no UEFI-based PC environment, virtual or physical, would be able to boot from a drive that has an incomplete partition set.  Additionally, viBoot relies on Hyper-V on the backend to actually boot and run the VM, so it wouldn't even control this capability.

Anyhow, the first step here is to gain some clarity as to what you're working with at the moment, and then we can figure out how to get where you need to go.  So first, it would help to clearly show what partitions are included in each of your backups, ideally with screenshots.  Go to the Restore tab within Reflect, select one of your images, and then the partition map it contains will be shown at the top of the application window.  Capture a screenshot of that using something like the Snipping Tool built into Windows, then do the same for your other image.  That will hopefully make it clear why you seem to be in a bind here, and then we can figure out what can be done to fix it.  There are some options to get an "incomplete" system image into a bootable state, even if it requires combining partitions from multiple images.  They wouldn't be as difficult as the sequence you suggested, but they're not exactly straightforward either.

Lastly for now, if what you're trying to say here is that at some point you were capturing images that included only your OS partition and did not include the other system partitions (EFI, MSR, and Recovery), that's a mistake, and going forward you should really take advantage of Reflect's function that I've circled in the screenshot below to ensure that any images you capture will allow you to restore your system to a bootable state, and therefore also boot in a viBoot environment, thereby avoiding this entire quandary.



Edited 1 May 2018 5:12 AM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)
Group: Forum Members
Posts: 3.8K, Visits: 28K
Ok, the 6th reading may have been the charm here.  Are the below statements correct?

- A long time ago you captured an image of your entire disk.  Call it Image #1.
- More recently than that, you captured an image containing only your OS partition.  (Don't do that anymore, if you haven't already figured that out....)  Call that one Image #2.
- After capturing Image #2, you wiped your system.  Now you want to boot into the Windows environment contained in Image #2, but that image is missing partitions required for that disk to be bootable.  Those partitions exist in Image #1, but that's an entirely separate image.

If that is an accurate summary of your current state, then if you are reasonably comfortable working with VMs directly in Hyper-V, I've provided some steps below that should work.  If you aren't, then the onerous task sequence you suggested earlier may ultimately be faster than trying to learn Hyper-V just to accomplish this.  But if you want to try the VM route:
- Create a new virtual disk as a VHDX file.  Follow the steps only in the first "How to create" section on this page, set the total disk size to match the total capacity of the hard drive you captured the images from, and select "Dynamically expanding".  The file itself won't grow to the specified capacity, but it will grow as large as the amount of data stored in the Reflect image file in uncompressed form.  So for example if your image file itself is 50GB but it contains 100GB worth of original data, you'll need to store your VHDX file somewhere that it can grow to 100GB.
- Launch Reflect.  It should show the virtual hard disk you created above.  If not, go back to Disk Management, make sure the VHDX file you created is mounted, and then close and relaunch Reflect.
- Restore the EFI and MSR partitions from Image #1 onto the virtual hard disk.
- Restore the OS partition from Image #2 onto the virtual hard disk, making sure not to overwrite the EFI and MSR partitions you just restored.
- Create a Rescue Media ISO by stepping through the Create Rescue Media wizard. For convenience, uncheck the "Prompt for key press" option.
- Go back to the Disk Management tool and detach the VHDX file.
- Create a Generation 2 VM in Hyper-V.  Give it at least 2048 MB of RAM, then choose the VHDX file you created as its virtual disk.  After the VM is created but before you power it on, go into the VM settings, give it 2 CPUs for performance, then add a DVD drive and select the Rescue Media ISO as the virtual disc.  Apply your settings, then go to the boot order and move the DVD drive to the top.
- Start your VM.  It should boot into the Reflect Rescue Media environment.  If so, run Fix Boot Problems, then run ReDeploy, then restart the VM.  It should boot properly.
- When you're done, delete the VM from Hyper-V first, then delete the VHDX file, then make sure all of your future Reflect backups include the partitions that get selected when you click the option I circled in the screenshot from my previous post above. Smile

Edited 1 May 2018 5:38 AM by jphughan
smithcferg
smithcferg
New Member
New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)
Group: Forum Members
Posts: 4, Visits: 9
jphughan - 1 May 2018 5:35 AM
Ok, the 6th reading may have been the charm here.  Are the below statements correct?

- A long time ago you captured an image of your entire disk.  Call it Image #1.
- More recently than that, you captured an image containing only your OS partition.  (Don't do that anymore, if you haven't already figured that out....)  Call that one Image #2.
- After capturing Image #2, you wiped your system.  Now you want to boot into the Windows environment contained in Image #2, but that image is missing partitions required for that disk to be bootable.  Those partitions exist in Image #1, but that's an entirely separate image.
....

This is the basic scenario, and I am mortified, and awestruck.  Mortified that my explanation was so murky that it took six reads to be understood, and awestruck that there is a way to do this.   ​  It is too bad that it isn't simpler.  I definitely agree I should make bootable system partitions from now on, I only just learned about viboot.  I will try the steps you outlined, it looks like it will be a good learning process for me.  Thanks for spending the time to outline this.  ​​
smithcferg
smithcferg
New Member
New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)
Group: Forum Members
Posts: 4, Visits: 9
And as to my feature request, you mentioned: "if the image doesn't contain all required partitions, then not being able to boot it isn't viBoot's fault, because no UEFI-based PC environment, virtual or physical, would be able to boot from a drive that has an incomplete partition set."  That's correct, and why the feature request would involve correcting a broken boot environment.  
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)
Group: Forum Members
Posts: 3.8K, Visits: 28K
No need to feel mortified!  In fairness, it was late where I was at the time I was reading that.  Another complication is the terminology around "system partition" and "boot partition".  Those are terms are not used consistently between different people or even defined consistently.  Microsoft rather annoyingly formally defines those terms backwards, for example.  In their world, the "system partition" is the one that contains the boot files, and the "boot partition" is the one that contains the Windows system files.  That's why I suggested screenshots of what you actually had in each image, because sometimes a picture is worth a thousand words.  Anyhow, hopefully the steps above get you what you need.  Good luck! Smile

Edited 1 May 2018 7:00 PM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)
Group: Forum Members
Posts: 3.8K, Visits: 28K
smithcferg - 1 May 2018 6:57 PM
And as to my feature request, you mentioned: "if the image doesn't contain all required partitions, then not being able to boot it isn't viBoot's fault, because no UEFI-based PC environment, virtual or physical, would be able to boot from a drive that has an incomplete partition set."  That's correct, and why the feature request would involve correcting a broken boot environment.  

I understand, but wouldn't be easy for viBoot to fix.  First, viBoot basically just preps the image file, then has Hyper-V create a VM that uses that disk and counts on Hyper-V to run it -- in fact the Virtual Machine Connection window that launches from viBoot is just a Hyper-V application -- so I'm not sure viBoot could even detect an unbootable VM and recognize the need for a fix like this.  Additionally, the way image files work would very likely make it exceedingly difficult to "inject" missing partitions into a disk -- and that's before considering scenarios like images that came from systems that were using custom bootloaders to facilitate things like dual booting OSes, in which case just adding a "standard" boot partition may not even resolve the boot issue.  But at the end of the day, it most certainly wouldn't be worth the development effort to do any of this given that the far easier and more reliable solution is to simply capture the correct set of partitions in the first place, which Macrium helps users do by offering that button I included in my earlier screenshot.  They're very small, so there's no good reason not to include them, and the benefit of doing so is not limited to just viBoot.  If you have a hardware failure on a physical hard drive and had to restore onto a brand new empty drive, then just having an image of your OS partition will typically not be enough to make that system boot again without some extra work.  Of course in your case since you had an older image, you would be able to restore that and then restore the newer OS partition backup from the newer image, but now your restores will take longer and their success depends on having two backup files in order to get the required partitions back.  Again, given how small the extra partitions are, it's worth capturing them and enjoying the benefits both inside and outside of viBoot scenarios.

Edited 1 May 2018 7:21 PM by jphughan
backuper
backuper
Junior Member
Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)Junior Member (77 reputation)
Group: Awaiting Activation
Posts: 37, Visits: 109
I still miss it a lot that I can't save a macrium image in a way to open it with virtualbox or vmWare like others can do it. But I'm wondering if hyper-V brings any real advantage that I don't see?

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)Macrium Evangelist (5.6K reputation)
Group: Forum Members
Posts: 3.8K, Visits: 28K
backuper - 4 June 2018 7:52 PM
I still miss it a lot that I can't save a macrium image in a way to open it with virtualbox or vmWare like others can do it. But I'm wondering if hyper-V brings any real advantage that I don't see?

This post is pretty off-topic relative to this particular thread, but although this idea wouldn't be practical as a frequent solution, if you just wanted an option for the occasional "conversion" need, if Virtualbox/VMware support using Microsoft's VHD/VHDX files, then you could create a new VHD/VHDX file and restore your Reflect image into that file.

As for Hyper-V itself, it's the only "Type 1" hypervisor that runs within Windows, which means that it can actually run underneath the host OS.  All other Windows hypervisors are necessarily "Type 2", which means they run on top of the host OS, which typically imposes a performance penalty.  Beyond that, I haven't looked into Virtualbox or VMware very recently since Hyper-V does what I need it to do, so I can't provide a detailed comparison.  I do know that Virtualbox and VMware (Workstation, not ESX) were both originally designed to be more desktop-oriented virtualization solutions and therefore focused far more host-to-guest integration capabilities, whereas Hyper-V was originally designed as an enterprise-focused solution (like VMware ESX) and was only later ported to non-Server versions of Windows.  This difference in focus meant that Hyper-V lagged way behind other solutions in some key areas from an end user perspective, but it's improved quite a bit on that front sine then, at least if your guest VMs are running Windows 8 or later and can therefore take advantage of "Enhanced Session Mode", which is essentially RDP without the need to set up formal networking.  Hyper-V on Win10 1709 finally gained an easy to use NAT networking mode thanks to the "Default Switch", for example.

Edited 4 June 2018 8:15 PM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search