Cloning only installed files VS entire drive?
-
@TTellez let see where you are at.
You captured the image from a larger disk as single disk resizable. Then you deployed it to a smaller disk. When the target computer rebooted it didn’t boot into windows it just sat at a black screen with a cursor. Do I understand that right?
If I do then I have these questions.
- If you change the firmware so the hard drive is first in the boot order does it still do this?
- Is the image on the disk gpt or mbr?
- Is the image on the source disk UEFI or legacy (bios) based?
- The system you are deploying this reference image to, does it match the uefi/legacy settings of the source system?
-
- Boots to the black screen with the flashing white cursor
- Uh…unsure? Im an idiot apparently.
- Legacy
- legacy as well on the deployed system
-
@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.
-
@george1421 Win 7 is the deployed image.
No, bootpart commands do not fix the issue.
-
@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 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.
-
@TTellez Sorry I was not clear.
At this point we don’t know
- Is the fact that we are going from 500GB->Smaller the issue
- Something is damaged in the master image on the 500GB drive
- 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 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.
