Capture Image partclone fail.
-
@george1421 - Its seems that it has been successful in writing some files. Not sure what the issue is. I did the debug prior to the message / post and no errors that I could see outside the one that is in the screenshot.
Seems the capturing process is running and writing the files as root.
I tried to change as fogproject.root before image is complete, but curious why its now doing this.
-
Here is the debug mode.
Exports file again:
-
@sourceminer OK the exports file is correct. I wanted to make sure the /imagesX/dev directories were rw and the /images were ro.
So what I found strange is that the /ntfs directory is empty. It should not be empty (I think). Hopefully you are still at that command prompt. Key in
df -hto see if you have mounted the fog server. I think we are at the point of the error, we just need to find out why with this computer the capture isn’t working.Also confirm that you can ping the fog server.
Wait, I think I have a capture mixed with a deployment. Try /images on the target computer instead of /ntfs. See if that directory has stuff.
-
@george1421
So yes if I go into /images I can see the test file. I can also see the mac directory
-
@sourceminer OK then. That bit is working fine. So I think we are chasing a ghost here. We chase the most likely first then we have to dig a bit deeper. While the info is broken we can see the server has 366GB of space available.
From your initial message I see partclone existing with code 1 (basically something happened it didn’t like). Not much help there.
So…
- How big is that partition 4 on that disk?
- While its just an observation that I never noticed before, PIGZ_COMP = -6. I would expected that to be a positive integer. Looking at the manual the -X is the compression ratio switch. so that’s not it.
- Are you using single disk resizable mode?
-
@george1421 I have 400GB free Space (600GB size) (I initially thought it might be a space issue as well, however, this is not the case.
Yes using Single Resizable disk mode. Trying Single Disk not resizable - Did the same error… The suspect seems to be this unclean shutdown issue… I booted and verified prior to the capture that the chkdsk was clean and without error. -
@sourceminer So this gives us about 200GB of real data to move…
This is an interesting (hint: annoying) issue. So I take it there wasn’t any error on the blue partclone screen before it threw this error?
I can’t remember if I asked this, in this thread, but when you were at the command prompt where you check the partclone log file in /var/logs to see if it gives and clues??
With 200GB of data, that is typically larger than fog normally handles. So I wonder if we are running out memory to clone this big disk.
Under FOG WebUI -> FOG Configuration ->FOG Settings hit the expand all button.
Now search for CAPTURERESIZEPCT increase the value from 5 to 10.
Search for KERNEL RAMDISK SIZE set it to 275000 from 256000 (if its less than 256000, let me know). Lets see if this makes any difference.
-
@george1421
Thanks for the update, so the partclone error only specified the issue of the OS having dirty shutdown flags.- I have since while waiting for your reply, booted back into windows and again verified the disks are clean by running a check disk on boot. Waited for everything to be good. Re-ran sysprep and shut down and was about to capture again. I will also add the items you suggest. The Image is only 120 GB or so…
-
@sourceminer Ah, ok this now explains what is happening.
How are you powering off this computer prior to capture?
-
@george1421 I am having it shut down.
-
@sourceminer sysprep is shutting it down or you are picking start button -> shutdown?
-
@george1421 Sysprep is set to shutdown. Also the settings for Ram Disk were already at 275000, and the capture resize was changed from 7 to 10.
-
@sourceminer Well… all of the probable issues seem to be a miss with this problem.
Ok lets do what partclone is telling us.
Schedule a debug capture if its still not in that state. Get to the FOS Linux command prompt on the target computer.
at the command prompt key in
fsck -t ntfs /dev/sda4Lets check the file system in linux. This is a command guess. If the fsck program completes without issue then issuefogto single step through the image capture.I’m thinking there is something with that partition its not liking.
-
@george1421 I am waiting for this next iteration of capture finishes. Its at 80%
-
@george1421
Ok so when I attempted to run fsck -t ntfs /dev/sda4 I got not found…
So I ran it as fsck -t ntfs dev/sda4 and it worked but didn’t seem to do anything or there were no errors Tried to run fog still an error. Very puzzling. -
@george1421 Attempted to run through this article: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
- rerunning fog capture in debug to test.
-
@george1421 ok ran ntfsfix /dev/sda4 came back as good.
Re-ran FOG and it still complained with same error… Not sure what else it could be.
-
@sourceminer ref: https://medium.com/@mikeycpham/using-clonezilla-to-image-and-getting-the-error-ntfclone-ng-c-ntfs-volume-dev-sd-is-7a467b617c4d
Clonezilla also sees this error.
In your case you will want to pxe boot into fog instead of usb booting clonezilla.
ntfsfix -d /dev/sdb1Clears the dirty flag.
-
@george1421 So yes I just ran that again… says it was processed successfully. Same as before. I will see if that -d did anything else
-
@george1421 OK, finally, was able to capture the image successfully. This partition /dev/sda4 apparently was the recovery partition so all efforts prior to this (IE hibernation settings, and running chkdsk on the os volume were not the issue). What fixed the issue was running:
ntfsfix -d /dev/sda4
Suggestion: would it be a good idea to test these dirty flags prior to running the lengthy imaging process so that perhaps we don’t have to do so much guesswork.
