Cloning only installed files VS entire drive?
-
@george1421 Yeah and I think its that threefold possiblity that is making it very hard for us to determine exactly what the issue is.
-
@george1421 what I am doing now as a test is configuring the same exact machine from scratch. Then I will clone it, and deploy it, and see if that makes the difference. If it works, then I have the right image for future machines.
In my past experience with FOG we already had the images created, and we did have one that was a “generic” install. I wish I knew how we created that one as well…but alas, I don’t have that resource any longer.
-
@george1421 UPDATE: I created a new image on the same exact laptop we are trying to image. Still boots to a black screen. ARGH.
-
I think the hardest part for me is that a majority of the documentation I can find is based on an older version, and this version has many options that older versions didn’t.
-
@TTellez We need to collect some information about your image before capture - and after deployment. This won’t be too tough but we need to dig into your issue.
Don’t spent a lot of time making a fancy image - just install windows, nothing else. no updates.
Do a debug capture. This is created like a normal capture but you select the debug checkbox, pictured below.
When the target system boots for capture, you’ll be presented with some information - press enter to go through this. Eventually you’ll land at a linux shell. Here, we need you to do some commands and take well-focused readable photos of the output.
sfdisk -d /dev/sda lsblkThen after you have pictures taken, issue the
fogcommand and proceed with capture. At every single step, the capture process will ask you to press enter to continue - just do this and get it completely through capture.Then, we’re going to do similar with deploy. Schedule a debug deployment using this new image. But this time, we’re going to allow FOG to deploy the image - and then were going to run the same information gathering commands after the image deployment is done. So when the target boots, it’ll again be in debug mode. Press enter through the informational parts. When you’re at a shell, issue the
fogcommand. Press enter through each phase of deployment until everything is done. Then at the end, do not power off, do not restart - issue these commands and take photos of the output.sfdisk -d /dev/sda lsblkAnd also, please, when you’re posting the photos here, go ahead and give us the high resolution copies. It’s OK to crop, but we need to be able to read this stuff otherwise it’s of no use. And please label the photos so we know which are what.
-
@Wayne-Workman currently capturing a new image. Once complete I will recapture a "debug"image from the same computer and upload. Thanks.
-
@TTellez All the steps matter - if you do half we have nothing to compare. Please follow all the steps when you do this.
-
@TTellez Just so we are clear on this, you created a new reference image, captured it and deployed it back to the same device and it became broken?
I assume you used single disk resizeable?
I wonder if you get the same results from single disk non-resizeable?
I’m going to spin up a new Win7 reference image to ensure 1.3.5 isn’t doing something strange with image deployment. This is really strange.
-
@george1421 Correct
I am currently capturing an image with single disk non resizable, and the first was resizable. So I will be able to compare “reactions”
-
@Wayne-Workman Debugging Clone(pre-deploy)
-
@Wayne-Workman POST deploy on new machine
-
@Wayne-Workman Ironically the debug deploy boots into the OS just fine. LOL
Non resizable must be the way to go.
-
@TTellez We need to see what’s wrong with resizable, please run the test again but as resizable.
-
@Wayne-Workman Wayne, I will be back in the office tomorrow, and can do so then.
