Cloning only installed files VS entire drive?

  • The image our client gave us is larger than the drive in the new model laptop thy are using. While we could build a fresh image, I was wondering if there was a way to just clone the installed files VS the entire drive image???

    Thanks in advance.

  • @Wayne-Workman Wayne, I will be back in the office tomorrow, and can do so then.

  • @TTellez We need to see what’s wrong with resizable, please run the test again but as resizable.

  • @Wayne-Workman Ironically the debug deploy boots into the OS just fine. LOL

    Non resizable must be the way to go.

  • @Wayne-Workman POST deploy on new machine

    0_1490807623219_IMG_0260.JPG 0_1490807645493_IMG_0261.JPG

  • @Wayne-Workman Debugging Clone(pre-deploy)
    0_1490798870987_image1.JPG 0_1490798883876_IMG_0258.JPG

  • @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”

  • Moderator

    @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.

  • @TTellez All the steps matter - if you do half we have nothing to compare. Please follow all the steps when you do this.

  • @Wayne-Workman currently capturing a new image. Once complete I will recapture a "debug"image from the same computer and upload. Thanks.

  • @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.

    0_1490793028311_Debug Capture.png

    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

    Then after you have pictures taken, issue the fog command 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 fog command. 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

    And 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.

  • 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.

  • @george1421 UPDATE: I created a new image on the same exact laptop we are trying to image. Still boots to a black screen. ARGH.

  • @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 Yeah and I think its that threefold possiblity that is making it very hard for us to determine exactly what the issue is.

  • Moderator

    @TTellez Sorry I was not clear.

    At this point we don’t know

    1. Is the fact that we are going from 500GB->Smaller the issue
    2. Something is damaged in the master image on the 500GB drive
    3. FOG is doing something unexpected with the reimage.

    My question is around #2 if we went from 500GB to 500GB would it work?

    Then for question #3 how can we determine the image on the 500GB is good.

  • @george1421 they are not one for one. The source is a 500GB SSD SATA drive. The client we are deploying to is a 250 GB FlashSSD. All other hardware remains the same.

  • Moderator

    @TTellez OK then. If you have the same size disk can you deploy it one for one? The question that is running through my mind is the source image defective? Because you should not have this issue. The capture resize, and deploy does work. At this point I’m just trying to rule out where the problem isn’t. The source image is suspect if you can’t recover the target system. But again I’m only saying that so we can eliminate it from the problem.

  • @george1421 Win 7 is the deployed image.

    No, bootpart commands do not fix the issue.

  • Moderator

    @TTellez So the only thing in question right now is gpt vs mbr. What OS is deployed on the source disk?

    If you boot into a rescue can you repair the disk with the fixpart and bootpart (not sure if those are the right commands. But need to rebuild mbr and then ensure that the proper partition is configured to boot). I’m only interested in seeing if the image can be salvaged. Then we can work on why.