WIndows 10 Capture/Deploy Woes
-
I have been trying to get some Dell 5450 laptops to image with Windows 10 but FOG seems completely broken at the moment (SVN 6090)
Last week when attempting the capture the image, it would capture OK (WIndows 10/Single disk resizable) but then the machine the image was taken from had it’s C:\ drive reduced from the total disk size of 256GB to just above the amount of data consumed by the OS (~12GB)? The image would deploy OK but disk in the same shrunken state
![0_1453719198408_upload-83e975a3-1e11-4adb-a33d-75fbf3d0c20b](Uploading 100%)I have been updating the install every day, hoping that this is fixed but things are now worse?
I updated to SVN6090 this morning and re-captured a freshly installed Windows 10 image and now the source machine wont even boot!
I then attempted to deploy the gathered image to another device and get this error on the destination ![0_1453719102916_upload-fce4c49c-1933-42fe-8563-a8b326d0bce0](Uploading 100%)Any advice of feedback would be appreciated?
Thanks
-
I’m not understanding at all.
What is ![0_1453719198408_upload-83e975a3-1e11-4adb-a33d-75fbf3d0c20b](Uploading 100%) I’m guessing these are supposed to be pictures.
How are they worse? What are the messages you’re seeing?
-
Thanks for responding so quickly.
Currently running v6090 but struggling to get Windows 10 to capture and/or deploy?
Tried capturing (single-disk-resizable) but when capturing I see this, which clearly shows the destination C:\ much smaller than it should be (465GB)
After capture the source device no longer boots with this error
Image folder contents on the server
Deploying resizable image results in this error on the destination machine?
-
Tried capturing a fresh Windows 10 image, this time using (non-resizable Windows 10) option and at least the source machine is able to boot back into Windows after the capture task completes.
However, restoring this image failed with the following error “No disk passed (runPartprobe)” ?
-
@Andrew-Aitken said:
Tried capturing (single-disk-resizable) but when capturing I see this, which clearly shows the destination C:\ much smaller than it should be (465GB)
That’s how resizable images work. The partitions are shrunk down to just 2GB larger than the amount of data on the partition.
As for the issue with the source host being bootable after a resizable image is taken, I believe you’re experiencing the same issues as described here: https://forums.fogproject.org/topic/6536/windows-10-after-upload-partition-erased So for that specific issue, could you post to that thread?
-
@Wayne-Workman said:
As for the issue with the source host being bootable after a resizable image is taken, I believe you’re experiencing the same issues as described here: https://forums.fogproject.org/topic/6536/windows-10-after-upload-partition-erased So for that specific issue, could you post to that thread?You are absolutely right. Will post any further comments to that thread
-
So I’m noticing a couple things.
- The first boot error relates to efi - perhaps you have an efi partition separate from the install and would need to do multiple partition image
- At the same time there are .mbr files and also gpt messages. GPT is typically associated with efi style images and mbr with bios/legacy style images.
So are you using uefi on the image you are uploading from?
Are you uploading from legacy and then downloading to a computer set to uefi mode?
Personally I find mbr and bios/legacy mode to work just fine and to be just much simpler. So if it’s not too much effort you could redo the image making sure that your computer is booting to legacy/bios mode. In some bios’s you have to disable secure boot before it lets you enable the legacy boot mode. GPT and uefi do work with fog, don’t get me wrong, but I just find gpt easier. Also, a side note, to ensure you make only one partition when you install windows (this works on at least windows 7 and up) when you have the install disc in and you’re at the partition selection, hit shift+f10 to bring up a command prompt. Then run the following commands to clear out all existing partitions and make only one new one. As far as I have found this only works with mbr style partitions. There is probably a way to do it for gpt, I just haven’t found it yet, which is another reason I stick with mbr.diskpart list disk (It will list the disks with details, most likely you'll want disk 0, but list and check to be sure) select disk 0 clean create partition primary exit exit
Then hit refresh on the windows gui partition editor and select the newly created partition
If you put a lot of work into this image and don’t want to start over on it, no worries, we can still try some other stuff.
Go into fog and queue a download of the image ticking the “schedule as a debug task” box.
Now you will be able to step through the image process and run some other commands on the computer you are imagingI would try running fixparts on /dev/sda in a debug session. This may fix any mbr/gpt confusion within the drive or image your using and that alone could make it work.
If that doesn’t do the trick. Then we’ll come back to the drawing board.So, that was a lot of information, let me summarize a little.
- Is your image source a gpt/efi setup or a mbr/bios setup?
- Do you want it to be resizable or do you not care because they’re all the same size hard drive?
- Have you tried running fixparts (I would recommend trying this before uploading the source image as well as before download)
- Consider making a new mbr style image in bios/legacy mode using the instructions I gave above, as I know it works for windows 10
-
@Arrowhead-IT
I followed your advice RE: using diskpart and managed to get both my Dell 5450 latptop and HP 800-G1 desktops to boot legacy/MBR, install Windows 10 and can now successfully capture/deploy using single-disk resizable FOG image.I’m pretty sure I had default GPT/UEFI Windows 10 multi-partition image capturing and deploying previously but maybe I imagined it?
Thanks for your help.